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

From: Adrian Farrel <[email-masked]>
Date: Tue, 09 Nov 2010 02:42:22 +0000

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

---

From: [email-masked]
Date: Tue, 9 Nov 2010 02:06:27 -0500

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.

OLD

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.

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

OLD

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

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 09 Nov 2010 09:13:18 +0100

Hello Adrian,

I agree with the proposal from Malcolm.

Regards, Huub.

> 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]>*

-- 
**********************************************
                我爱外点一七三一

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 9 Nov 2010 15:50:39 +0200

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

08/11/2010 09:42 PM
Please respond to
[email-masked]

To

cc

[email-masked]

Subject

Hi,

OLD

OLD

Thanks,
Adrian

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Tue, 9 Nov 2010 18:27:05 +0100

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,

Regards,
     Sasha

Hi Adrian,

Regards,

Malcolm

08/11/2010 09:42 PM
Please respond to
[email-masked]

To

cc

[email-masked]

Subject

Hi,

OLD

OLD

Thanks,
Adrian

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 9 Nov 2010 20:05:41 +0200

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 therefore support Malcolm’s proposed text.

Italo

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

Hi Adrian,

Regards,

Malcolm

08/11/2010 09:42 PM
Please respond to
[email-masked]

To

cc

[email-masked]

Subject

Hi,

OLD

OLD

Thanks,
Adrian

---

From: [email-masked]
Date: Tue, 9 Nov 2010 17:52:05 -0500

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,
 
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:
 
?
?
 
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, 

Regards, 

Malcolm 

Please respond to
[email-masked]

To

Hi,

OLD

OLD

Thanks,
Adrian

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 10 Nov 2010 06:06:09 +0100

Resending - after trying to fit into the size limitations (by cutting
some of the thread)

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: Alexander Vainshtein <[email-masked]>
Date: Wed, 10 Nov 2010 07:07:29 +0200

Malcolm,

I must admit that I have presumably missed the liaison in question, and have only seen this text in the Erratum.

As has been mentioned in this thread, a combination of "MAY" and "required" (which in IETF is equivalent to MUST) is apt to create confusion. In addition, I do not understand the rationale for making multiplexing optional. Does ITU plan a new data link technology that would not support such multiplexing?

Regards,
     Sasha

________________________________
From: [email-masked] [[email-masked]]
Sent: Wednesday, November 10, 2010 12:52 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; BUSI, ITALO (ITALO); [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."

"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

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,

My 2c,

     Sasha

Sasha,

“

Italo

Malcolm, and all,

Regards,
     Sasha

Hi Adrian,

Regards,

Malcolm

08/11/2010 09:42 PM

Please respond to
[email-masked]

To

Hi,

OLD

OLD

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

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 10 Nov 2010 07:39:19 +0100

Hi,
I support the proposal. 
The proposed text provides useful information on the applicability. 
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Adrian Farrel
Sent: Tuesday, November 09, 2010 4:42 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [mpls-tp] Resolution of Erratum 2533 (RFC 5960)

Hi,

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.

OLD

Thanks,
Adrian

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 10 Nov 2010 07:07:40 +0000

[Trimmed to MPLS-TP & Ad-hoc lists only]

> "This change is intended to clarify that providing a multiplexing capability for a section layer is optional." 

<Responding to no-one in particular>

While strictly speaking true, is this not somewhat theoretical?

I am not aware of a data-link technology that exists today that doesn't support multiplexing of different payloads/protocols and that would in practice be used for MPLS-TP.

I would also posit that it would be extremely foolish for any new data-link technology that would want to be a section layer to not support multiplexing.

I'm OK with Adrian's text or Malcolm's text and I'm equally OK to keep the original text in RFC5960 (i.e. I think this such a minor point that I really don't care much what the text says).

Ben

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Nov 2010 07:47:58 +0000

Adrian,

As far as I can see the change is the addition of this sentence.

This mechanism may be used to facilitate multiplexing MPLS
with other protocols on the section where that function is needed.

I am OK with this change.

Stewart