Subject: Re: Last Call: draft-ietf-mpls-tp-framework (A Framework forMPLS in Transport Networks) to Informational RFC

From: "Tom.Petch" <[email-masked]>
Date: Sat, 17 Apr 2010 20:02:47 +0200

I have reservations about the readiness of this I-D.

The technical content looks ok, but the process by which it has been arrived at
gives me pause.

It is a crucial document for MPLS-TP, perhaps the most important after the
requirements ones, like, say, RFC3411 for SNMP.

This Last Call is on -11 which shows substantial changes from -10 (eg in S3.4)
and, despite assiduously tracking the list, I am unsure where these changes have
come from.  I do not see them discussed, I do not see any consensus declared for
(or against) them nor is there any explanation in the I-D itself.

The topics covered include some that have provoked considerable debate, over the
past two years, involving hundreds of e-mails, including a sequence where
several exceeded one Megabyte in size each.  Yet, again, I have not seen any
consensus declared on the list on most of these topics.

The topics I have in mind include; what is MPLS-TP?  Is it a layer network, in
the G.805/G.800 sense, a set of such layers or what? (and saying it is a Profile
has no meaning until the word 'Profile' has been defined in this context). S3.1
of this I-D, like its predecessor, talks variously of 'MPLS-TP network', MPLS-TP
layer network' and 'MPLS-TP server' which I find less than clear.

How does MPLS-TP relate to MPLS?  My sense is that it is a subset of a superset,
a superset because MPLS lacks, eg, adequate OAM, a subset to make it as simple
as possible but not simpler. (Again, simply saying 'Profile' is really only
tautology.

Are features in or out?  ECMP, NNI, PHP, multiple QoS?  I think that some of
these are still being debated as the Working Group Last Call proceeds in
parallel with this Last Call.

S-bit; how many allowed in the stack; I think that the consensus is one, but
then what does it mean, and what happens to the meaning it would have had when
there were more than one?

MIP; where and how many?

It is not that a view could not be formed on some of these issues from reading
the I-D, but where does that view come from?  Not, as far as I can see, from any
IETF WG list.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 07, 2010 4:33 PM
Subject: [mpls] Last Call: draft-ietf-mpls-tp-framework (A Framework forMPLS in
Transport Networks) to Informational RFC

> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document:
>
> - 'A Framework for MPLS in Transport Networks '
>    <draft-ietf-mpls-tp-framework-11.txt> as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2010-04-21. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-framework-11.txt
>
> IESG discussion can be tracked via
>
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18027&rf
c_flag=0
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Tom.Petch" <[email-masked]>
Date: Tue, 20 Apr 2010 17:53:33 +0200

3.4.1 says

"The data plane behaviour of MPLS-TP is the same as the best current
   practise for MPLS.  This includes the setting of the S-Bit.  "

Without a reference, or any detail, I think this can only muddy the waters.  How
do I know that your best practice is my best practice, or his?

Tom Petch

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Mon, 26 Apr 2010 18:05:16 +0200

Tom,

Many thanks for your comments. I have copied Loa who may want to respond to the procedural comments. 

Please see responses below for responses to technical/document content issues.

Best regards

Matthew, Stewart and Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tom.Petch
> Sent: 17 April 2010 19:03
> To: ietf
> Subject: Re: Last Call: draft-ietf-mpls-tp-framework (A 
> Framework forMPLS in Transport Networks) to Informational RFC
> 
> The technical content looks ok, but the process by which it 
> has been arrived at gives me pause.
> 
> It is a crucial document for MPLS-TP, perhaps the most 
> important after the requirements ones, like, say, RFC3411 for SNMP.
> 
> This Last Call is on -11 which shows substantial changes from 
> -10 (eg in S3.4) and, despite assiduously tracking the list, 
> I am unsure where these changes have come from.  I do not see 
> them discussed, I do not see any consensus declared for (or 
> against) them nor is there any explanation in the I-D itself.
> 
> The topics covered include some that have provoked 
> considerable debate, over the past two years, involving 
> hundreds of e-mails, including a sequence where several 
> exceeded one Megabyte in size each.  Yet, again, I have not 
> seen any consensus declared on the list on most of these topics.
> 

The majority of these changes are a consequence of ITU-T review comments and were discussed on the open calls on tuesdays, as advertised on the MPLS-TP list. Note that in normal IETF procedure more of this discussion would indeed have taken place on the list. However, we needed to operate in a way that allowed the ITU-T to communicate with us in a way that they felt comfortable.

> The topics I have in mind include; what is MPLS-TP?  Is it a 
> layer network, in the G.805/G.800 sense, a set of such layers 
> or what? (and saying it is a Profile has no meaning until the 
> word 'Profile' has been defined in this context). S3.1 of 
> this I-D, like its predecessor, talks variously of 'MPLS-TP 
> network', MPLS-TP layer network' and 'MPLS-TP server' which I 
> find less than clear.

We have used the term 'Profile' in the context that it has been used in RFC5654 and RFC5317. That is, a set of functional building blocks to meet the requirements as set out in RFC5654.

> 
> How does MPLS-TP relate to MPLS?  My sense is that it is a 
> subset of a superset, a superset because MPLS lacks, eg, 
> adequate OAM, a subset to make it as simple as possible but 
> not simpler. (Again, simply saying 'Profile' is really only tautology.

This is addressed in section 3.2.

> 
> Are features in or out?  ECMP, NNI, PHP, multiple QoS?  I 
> think that some of these are still being debated as the 
> Working Group Last Call proceeds in parallel with this Last Call.

I believe that all of these are explicitly addressed in the document.

> 
> S-bit; how many allowed in the stack; I think that the 
> consensus is one, but then what does it mean, and what 
> happens to the meaning it would have had when there were more 
> than one?

We believe that the current draft reflects the consensus as dicussed in various open calls, WG sessions, and on the mailing list over the last two years. 
 
> MIP; where and how many?

That is dicussed as a part of the MPLS-TP OAM Framewokr draft rather than the overall framework.

> It is not that a view could not be formed on some of these 
> issues from reading the I-D, but where does that view come 
> from?  Not, as far as I can see, from any IETF WG list.

The majority of the discussion occurred on the MPLS-TP list rather than the MPLS WG list.

> Subject: [mpls] Last Call: draft-ietf-mpls-tp-framework (A 
> Framework forMPLS in Transport Networks) to Informational RFC
> 
> 
> > The IESG has received a request from the Multiprotocol 
> Label Switching 
> > WG
> > final comments on this action.  Please send substantive comments to 
> > the [email-masked] mailing lists by 2010-04-21. 
> Exceptionally, comments 
> > may be sent to [email-masked] instead. In either case, please retain 
> > the beginning of the Subject line to allow automated sorting.
> >
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Mon, 26 Apr 2010 18:18:22 +0200

Tom,

Thanks for your comment.
> Without a reference, or any detail, I think this can only 
> muddy the waters.  How do I know that your best practice is 
> my best practice, or his?

This is intended to reflect the interpretation of RFC3031 that is commonly deployed. While it is technically possible to have the S-bit set more than once, this is not how it is widely done. We have used the term Best Current Practice in the same sense that it is referred to in RFC2026. 

draft-ietf-mpls-tp-data-plane-02.txt provides a standards track reference for this behavior.

Best regards,

Matthew, Stewart and Dan