Subject: [mpls] R: [Technical Errata Reported] RFC5960 (2533)

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Tue, 5 Oct 2010 22:56:34 +0200

Ben,

I am copying the ITU-T ad-hoc mailing list because this discussion is very relevant also to the ITU-T work.

A bit of background information: the main intent of this Errata is to address one of the two ITU-T comments that have not been addressed before the publication of RFC5960.

The text proposed in the Errata is an exact copy of the text proposed in the ITU-T LS that reflects the discussion done during the last ITU-T SG15 plenary meeting (with the contribution of IETF experts).

I think we can resolve the comment with different text as long as it can be agreed by both ITU-T and IETF.

A possible alternative could be:

"
A section MAY be required to provide a mechanism for multiplexing MPLS with other protocols. In this case, a means of identifying the type of payload it carries MUST be provided.
"

Any other opinion/view?

Thanks, Italo

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per conto di
> Benjamin Niven-Jenkins
> Inviato: giovedì 30 settembre 2010 2.19
> A: RFC Errata System
> Cc: BUSI, ITALO (ITALO); [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Oggetto: Re: [mpls] [Technical Errata Reported] RFC5960 (2533)
> 
> While the intent of reported errata is technically correct I'm somewhat
> torn between whether I think it should be rejected, or whether I don't
> care.
> 
> My thinking is:
> 
> The errata is technically correct because a corner case does exist where a
> section layer that doesn't support higher layer protocol multiplexing can
> still be used to support MPLS-TP in some scenarios.
> 
> I don't like the proposed replacement text because the original text is
> placing a requirement on the section layer technology and I think it is
> reasonable to say "if you want your section layer to work with MPLS-TP it
> MUST do/support X", however I don't think it's reasonable to say "if you
> want your section layer to work with MPLS-TP it MAY have to do X" (which
> is essentially the change the proposed text makes) because it leaves it
> unclear as to what is actually required from the section layer which
> practically reduces to section layers having to support X anyway so it
> becomes a (implicit) MUST in any case.
> 
> Furthermore the original text only states that a section layer MUST have a
> means of identifying the type of payload. If a section layer does not
> support multiplexing then it has an implicit means of identifying the
> payload by the interface over which the payload arrived and therefore it
> meets the requirement as stated by the original text.
> 
> Ben
> 
> 
> On 29 Sep 2010, at 18:39, RFC Errata System wrote:
> 
> >
> > The following errata report has been submitted for RFC5960,
> > "MPLS Transport Profile Data Plane Architecture".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=5960&eid=2533
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Italo Busi <[email-masked]>
> >
> > Section: 3.2
> >
> > Original Text
> > -------------
> >   A section MUST provide a means of identifying the type of payload it
> >   carries.
> >
> > Corrected Text
> > --------------
> >   A section MAY be required to provide a mechanism for multiplexing MPLS
> >   with other protocols.
> >
> >
> > Notes
> > -----
> > This change is intended to clarify that providing a multiplexing
> capability for a section layer is optional.
> >
> > See https://datatracker.ietf.org/liaison/916/
> >
> > Instructions:
> > -------------
> > This errata is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party (IESG)
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC5960 (draft-ietf-mpls-tp-data-plane-04)
> > --------------------------------------
> > Title               : MPLS Transport Profile Data Plane Architecture
> > Publication Date    : August 2010
> > Author(s)           : D. Frost, Ed., S. Bryant, Ed., M. Bocci, Ed.
> > Category            : PROPOSED STANDARD
> > Source              : Multiprotocol Label Switching
> > Area                : Routing
> > Stream              : IETF
> > Verifying Party     : IESG
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 6 Oct 2010 13:06:45 +0100

Italo,

The fact the proposed text change originated from ITU-T doesn't change my opinion that the current text is sufficient.

However, if I'm the only one making any noise then I'm happy to concede that I don't care enough to make this into an issue as I don't believe changing the text will materially affect how folks implement section layers. So if I'm on my own feel free to use either the text in the original errata or your proposal below I don't mind which.

Ben

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 6 Oct 2010 08:58:54 -0400

I agree with your two points below Ben. Sorry I didn't respond last week. 

	--Tom

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 06 Oct 2010 15:56:46 +0200

Hello Italo,

I agree with your proposal.
This text was drafted in cooperation.

Regards, Huub.

=====
>>> Reported by: Italo Busi<[email-masked]>
>>>
>>> Section: 3.2
>>>
>>> Original Text
>>> -------------

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 07 Oct 2010 14:04:20 +0100

Speaking as an author, my view is that the original text is correct, 
and the correction is not needed.

It's a fundamental of the IP protocol suite (which includes MPLS) that 
the parser knows what protocol to expect from the previous header or if 
there is no previous header from an identifier in the lower layer.

Indeed the "correction" makes an additional statement, but I don't think 
that is needed because it's an implication of the existing text.

- Stewart

On 30/09/2010 01:18, Benjamin Niven-Jenkins wrote:
> While the intent of reported errata is technically correct I'm somewhat torn between whether I think it should be rejected, or whether I don't care.
>
> My thinking is:
>
> The errata is technically correct because a corner case does exist where a section layer that doesn't support higher layer protocol multiplexing can still be used to support MPLS-TP in some scenarios.
>
> I don't like the proposed replacement text because the original text is placing a requirement on the section layer technology and I think it is reasonable to say "if you want your section layer to work with MPLS-TP it MUST do/support X", however I don't think it's reasonable to say "if you want your section layer to work with MPLS-TP it MAY have to do X" (which is essentially the change the proposed text makes) because it leaves it unclear as to what is actually required from the section layer which practically reduces to section layers having to support X anyway so it becomes a (implicit) MUST in any case.
>
> Furthermore the original text only states that a section layer MUST have a means of identifying the type of payload. If a section layer does not support multiplexing then it has an implicit means of identifying the payload by the interface over which the payload arrived and therefore it meets the requirement as stated by the original text.
>
> Ben
>
>
>> This change is intended to clarify that providing a multiplexing capability for a section layer is optional.
>>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Ross Callon <[email-masked]>
Date: Thu, 7 Oct 2010 14:05:10 -0400

I agree with Stewart that the correction is not needed. 

I am neutral regarding whether the correction should be rejected, or should be set to "hold for document update" (the latter implying that if and when RFC5960 is updated, the authors and working group will deal with the comment at that time). 

Ross 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, October 07, 2010 9:04 AM
To: Benjamin Niven-Jenkins
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; RFC Errata System
Subject: Re: [mpls] [Technical Errata Reported] RFC5960 (2533)

- Stewart

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 08 Oct 2010 10:42:23 +0200

Hello Stweard,

You replied:

> Speaking as an author, my view is that the original text is correct, and
> the correction is not needed.

As an author you are are an expert in this topic.
However, for the less experienced you knowledge, i.e.:

> It's a fundamental of the IP protocol suite (which includes MPLS)
 > that the parser knows what protocol to expect from the previous
 > header or if there is no previous header from an identifier in
 > the lower layer.

may not be that obvious.

So adding this explanation or the text proposed by Ben:

 > If a section layer does not support multiplexing then it has
 > an implicit means of identifying the payload by the interface
 > over which the payload arrived.

would improve the readability of the document.

Regards, Huub.

>> While the intent of reported errata is technically correct I'm
>> somewhat torn between whether I think it should be rejected, or
>> whether I don't care.
>>
>> My thinking is:
>>
>> The errata is technically correct because a corner case does exist
>> where a section layer that doesn't support higher layer protocol
>> multiplexing can still be used to support MPLS-TP in some scenarios.
>>
>> I don't like the proposed replacement text because the original text
>> is placing a requirement on the section layer technology and I think
>> it is reasonable to say "if you want your section layer to work with
>> MPLS-TP it MUST do/support X", however I don't think it's reasonable
>> to say "if you want your section layer to work with MPLS-TP it MAY
>> have to do X" (which is essentially the change the proposed text
>> makes) because it leaves it unclear as to what is actually required
>> from the section layer which practically reduces to section layers
>> having to support X anyway so it becomes a (implicit) MUST in any case.
>>
>> Furthermore the original text only states that a section layer MUST
>> have a means of identifying the type of payload. If a section layer
>> does not support multiplexing then it has an implicit means of
>> identifying the payload by the interface over which the payload
>> arrived and therefore it meets the requirement as stated by the
>> original text.
>>
>> Ben
>>
>>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 08 Oct 2010 18:10:57 +0100

Hi Huub,

> However, for the less experienced you knowledge, i.e.:
The preamble was to alert the reader that I was speaking as an 
individual contributor, and not as an AD. I.e. this is a technical 
comment and not a management comment.

> > over which the payload arrived.

Well there are a couple of problems with this. Firstly, other than in 
some implementations, a tunnel (i.e. an LSP) is not really an interface. 
Secondly if the packet arrives on a data-link, we do require the the 
type indicator.

- Stewart

---

From: John E Drake <[email-masked]>
Date: Fri, 8 Oct 2010 10:40:57 -0700

+1

Sent from my iPhone

---

From: "Trowbridge, Stephen J (Steve)" <[email-masked]>
Date: Sat, 9 Oct 2010 12:01:47 -0500

Hi Stewart,
In your earlier email, you said "... but I don't think that is needed because it's an implication of the existing text".

I resonate with Huub's comment: perhaps these kinds of implications are evident to an expert, but for others an explicit statement is generally better than relying on the reader to fish out the implications.

Also, since the statement is implied by the existing text, the statement clearly does no harm.

Given that this was the subject of an ITU-T comment, incorporating it would be responsive to that comment, some readers see this as a helpful (explicit vs implicit), and the statement does no harm, I am not sure that I see the downside of accepting the statement.
Regards,
Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Friday, October 08, 2010 11:11 AM
To: [email-masked]
Cc: [email-masked]; BUSI, ITALO (ITALO); [email-masked]; [email-masked]; RFC Errata System
Subject: Re: [mpls] [Technical Errata Reported] RFC5960 (2533)

  Hi Huub,

> However, for the less experienced you knowledge, i.e.:
The preamble was to alert the reader that I was speaking as an individual contributor, and not as an AD. I.e. this is a technical comment and not a management comment.

- Stewart

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Fri, 29 Oct 2010 09:10:35 +0200

Stewart,

As you actively contributed to and agree with the ITU-T LS proposing the change during the last ITU-T meeting (with claims implying that these were very minor changes the editors could have easily made to the document even if it were in the RFC Editor Queue), could you please clarify what has changed from June 2010 to now to cause your view to change?

Thanks, Italo

> Da: Stewart Bryant [mailto:[email-masked]]
> Inviato: giovedì 7 ottobre 2010 15.04
> A: Benjamin Niven-Jenkins
> Cc: RFC Errata System; [email-masked]; Bocci, Matthew (Matthew);
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> BUSI, ITALO (ITALO)
> > The errata is technically correct because a corner case does exist where
> a section layer that doesn't support higher layer protocol multiplexing
> can still be used to support MPLS-TP in some scenarios.
> >
> > Furthermore the original text only states that a section layer MUST have
> a means of identifying the type of payload. If a section layer does not