Subject: Re: [mpls] [mpls-tp] Resolution of Erratum 2533 (RFC 5960)

From: [email-masked]
Date: Tue, 9 Nov 2010 22:47:40 -0500

Hi Yaacov,

I think we are converging, I have a problem with your proposal in that it 
does not make it clear that multiplexing is optional.  In the interests of 
keeping the change to a minimum how about modifying the start of the first 
sentence to read:

"A section layer MAY multiplex MPLS with other payloads, if multiplexing 
is used on a section it MUST....." continue the original text.

We could rewrite the complete paragraph to eliminate some of the 
redundancy, however that will cause further debate and delay and the AD 
(Adrian) indicated that he intends to reach a resolution by the end of 
this week. 

Regards,

Malcolm

"Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]> 
09/11/2010 10:12 PM

To
<[email-masked]>, "Alexander Vainshtein" 
<[email-masked]>
cc
<[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
Subject
RE: [mpls-tp] Resolution of Erratum 2533 (RFC 5960)

Malcolm, hi
 
I have a problem with your correction to Adrian's proposal ? in that it 
seems to be redundant to state that this identification applies only to 
sections that support multiplexing and then (in the next sentence) state 
that this facilitates the multiplexing!  
In addition, I cannot agree with Italo that your proposed text answers 
Adrian's issue with using the identification for other purposes.
 
On the other hand, I agree with Adrian's reservations concerning the text 
originally proposed by the ITU. 
 
I would therefore like to propose to switch the order of the two sentences 
in Adrian's proposal and correct the statements to say:
 
In order to facilitate multiplexing MPLS with other protocols on the 
section where that function is needed, a section MUST provide a means of 
identifying the type of payload it carries. 
 
Hope this helps,
yaacov

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of ext [email-masked]
Sent: Wednesday, November 10, 2010 00:52
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]
Subject: Re: [mpls-tp] Resolution of Erratum 2533 (RFC 5960)

Sasha, 

This comment was raised in a liaison from the ITU prior to approval, 
however it was not included in the published version. 

The original comment from the ITU was: 
"This change is intended to clarify that providing a multiplexing 
capability for a section layer is optional." 

The change proposed was to replace: 

"A section MUST provide a means of identifying the type of payload it 
carries."   
with: 

"A section MAY be required to provide a mechanism for multiplexing MPLS 
with other protocols." 
So if the text that I proposed is not clear we should revert to the text 
originally proposed by the ITU. 
Regards, 
Malcolm 

Alexander Vainshtein <[email-masked]> 
Sent by: [email-masked] 
09/11/2010 01:05 PM 

To
"BUSI, ITALO (ITALO)" <[email-masked]> 
cc
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]> 
Subject
Re: [mpls-tp] Resolution of Erratum 2533 (RFC 5960)

Italo, 
Lots of thanks for a prompt response. 
 
Based on your clarification I have three issues with the text proposed by 
Malcolm: 
1.        Technically, I think that MPLS-TP Sections MUST (unconditionally
) support multiplexing of MPLS with other payload types. 
AFAIK, this requirement is met for all currently known data link 
technologies  and it is also met for LSPs acting as Sections (as explained 
in 5960). 
Hence the requirement in 5960 is mainly a restriction on designers of 
future data link technologies 
This requirement is orthogonal to actually using - or not using - 
multiplexing of MPLS with other payload types.
2.        Editorially, the text proposed by Malcolm sounds vague enough 
(taking your example, I state that if I had to ask my question, it points 
to lack of clarity; of course, one could always argue that it only points 
to my stupidity, but I respectfully disagree with such an 
interpretation:-) 
Last but not least, from the point of view of the IETF process, objections 
to such a basic requirement should be raised before approval of 5690, and 
not after. 
 
My 2c, 
     Sasha 

From: BUSI, ITALO (ITALO) [[email-masked]]
Sent: Tuesday, November 09, 2010 7:27 PM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]
Subject: R: [mpls-tp] Resolution of Erratum 2533 (RFC 5960)

Sasha, 
  
That?s exactly the intent. 
  
The fact that you and Malcolm got a different interpretation of Adrian?s 
proposed text is, for me, a clear indication that that text is quite 
ambiguous. 
  
I think that the new text proposed by Malcolm is more clear and still 
resolves the concern raised by Adrian: 
  
? 
In particular, while payload identification (which may be
implicit) is a solution to the issue of protocol multiplexing on a link,
protocol multiplexing is not the only use to which payload identification 
can be
put. 
? 
  
I therefore support Malcolm?s proposed text. 
  
Italo 

Da: [email-masked] [mailto:[email-masked]] Per conto 
di Alexander Vainshtein
Inviato: martedì 9 novembre 2010 21.51
A: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]
Oggetto: Re: [mpls-tp] Resolution of Erratum 2533 (RFC 5960) 
  
Malcolm, and all, 
IMHO and FWIW, the text proposed by Adrian is reasonably unambiguous. 
The qualifier  you suggest to add (?when the section supports multiplexing 
of MPLS with other protocols?) looks problematic to me. 
Do you want to say that some sections may not support multiplexing of MPLS 
with other protocols? 
  
Regards, 
     Sasha 
  
From: [email-masked] [mailto:[email-masked]] On Behalf 
Of [email-masked]
Sent: Tuesday, November 09, 2010 9:06 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Subject: Re: [mpls-tp] Resolution of Erratum 2533 (RFC 5960) 

Hi Adrian, 

I agree that the proposed text is not clear, however I don't think that 
your proposal captures the key point i.e. the means of identification is 
only required if MPLS is to be multiplexed with other protocols so how 
about: 

A section MUST provide a means of identifying the type of payload it 
carries when the section supports multiplexing of MPLS with other 
protocols. This mechanism may be used to facilitate multiplexing MPLS with 
other protocols on the section where that function is needed. If the 
section is a data-link, link-specific mechanisms such as a protocol type 
indication in the data-link header MAY be used.  If the section is an LSP, 
this information MAY be implied by the LSP label or, if the LSP payload is 
MPLS-labeled, by the setting of the S bit.  Additional labels MAY also be 
used if necessary to distinguish different payload types; see [RFC5921] 
for examples and further discussion. 

Regards, 

Malcolm 

Adrian Farrel <[email-masked]> 
Sent by: [email-masked] 
08/11/2010 09:42 PM 

Please respond to
[email-masked]

To
[email-masked], [email-masked] 
cc
[email-masked] 
Subject
[mpls-tp] Resolution of Erratum 2533 (RFC 5960)

 

Hi,

I have listened to the discussion on the list about this Erratum, and I 
have
chatted with the chairs.

The Erratum suggests that in Section 3.2 we should change

OLD
 A section MUST provide a means of identifying the type of payload it
 carries.
NEW
 A section MAY be required to provide a mechanism for multiplexing MPLS
 with other protocols. 
END

In my view these two sentences cover distinct subject matter. That is,
*replacing* the existing text with the new text would change the meaning 
and
intention of the text. In particular, while payload identification (which 
may be
implicit) is a solution to the issue of protocol multiplexing on a link,
protocol multiplexing is not the only use to which payload identification 
can be
put.

I also think that the use of RFC 2119 "MAY" in conjunction with lowercase
"required" in the proposed text is not perfectly clear.

However, I also believe that the new text adds some value in explaining 
the
applicability.

Therefore, I intend to modify the Erratum as below, and verify it.

OLD
 A section MUST provide a means of identifying the type of payload it
 carries.  If the section is a data-link, link-specific mechanisms
 such as a protocol type indication in the data-link header MAY be
 used.  If the section is an LSP, this information MAY be implied by
 the LSP label or, if the LSP payload is MPLS-labeled, by the setting
 of the S bit.  Additional labels MAY also be used if necessary to
 distinguish different payload types; see [RFC5921] for examples and
 further discussion.
NEW
 A section MUST provide a means of identifying the type of payload it
 carries. This mechanism may be used to facilitate multiplexing MPLS
 with other protocols on the section where that function is needed.
 If the section is a data-link, link-specific mechanisms
 such as a protocol type indication in the data-link header MAY be
 used.  If the section is an LSP, this information MAY be implied by
 the LSP label or, if the LSP payload is MPLS-labeled, by the setting
 of the S bit.  Additional labels MAY also be used if necessary to
 distinguish different payload types; see [RFC5921] for examples and
 further discussion.
END

Usually the resolution of Errata sits entirely with the AD, but in this 
case, I
would like to give a couple of days for feedback, but I intend to reach
resolution by the end of the week.

Thanks,
Adrian

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp