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

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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di
> Benjamin Niven-Jenkins
> Inviato: giovedì 30 settembre 2010 2.19
> A: RFC Errata System
> Cc: BUSI, ITALO (ITALO); mpls@ietf.org; danfrost@cisco.com;
> adrian.farrel@huawei.com; stbryant@cisco.com
> 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 <italo.busi@alcatel-lucent.com>
> >
> > 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
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls