Re: [mpls] [mpls-tp] Progressing Resolution of Erratum 2533 (RFC 5960) Wed, 10 November 2010 12:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E00BF3A6862; Wed, 10 Nov 2010 04:09:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.238
X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kdbe-EaI44yh; Wed, 10 Nov 2010 04:08:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E45BF3A6AA7; Wed, 10 Nov 2010 04:08:56 -0800 (PST)
Received: from [] by with surfront esmtp id 205951911657480; Wed, 10 Nov 2010 20:06:16 +0800 (CST)
Received: from [] by [] with StormMail ESMTP id 55813.4491732783; Wed, 10 Nov 2010 20:09:14 +0800 (CST)
Received: from ([]) by with ESMTP id oAAC9Npo016704; Wed, 10 Nov 2010 20:09:28 +0800 (CST) (envelope-from
In-Reply-To: <0d0301cb80aa$4a9d75a0$dfd860e0$>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <>
Date: Wed, 10 Nov 2010 07:09:03 -0500
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-11-10 20:09:11, Serialize complete at 2010-11-10 20:09:11
Content-Type: multipart/alternative; boundary="=_alternative 0042ABF8852577D7_="
X-MAIL: oAAC9Npo016704
Subject: Re: [mpls] [mpls-tp] Progressing Resolution of Erratum 2533 (RFC 5960)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Nov 2010 12:09:09 -0000


Thank you for the clarification the process. I now understand that the 
erratum was the wrong  approach to address this comment from the ITU.

Unfortunately I don't think that the change you are proposing will address 
the comment raised in the liaison from the ITU. 
"This change is intended to clarify that providing a multiplexing 
capability for a section layer is optional." 

My understanding is that the only motivation for the erratum was to 
address this comment, if this is the case then I see little point in 
progressing the erratum.



Adrian Farrel <> 
Sent by:
10/11/2010 02:38 AM
Please respond to


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


Thank you for your input and suggestions on this topic.

To be clear, we are not attempting to reach consensus on what change to 
but I am listening to your individual opinions.

In deciding what Erratum to post, I will select a form of words that 
the published RFC text, but which does not make a technical change. I 
intend to
reflect the consensus of the IETF that was demonstrated by the publication 
this document.

The Erratum process is intended to correct typographic or rendition issues 
produce Editorial or Technical issues in the published text. The process 
is not
intended to make technical changes or fixes. Such issues should be handled 
revising the work through the IETF consensus process. 
is a good example of how that is done.

Now, with regard to this particular Erratum.

It seems to me that there are two separate concerns.

The first concern is about identification of payloads. This is needed for 
range of reasons, and is a firm requirement in the existing text (and, 
indeed in
the MPLS architecture). However, it is noted that the identification may 
explicit or implicit. The text also notes that the use of explicit
identification of payload is a facilitator for demultiplexing multiplexed

The second concern is whether there is a requirement to support payload
multiplexing. I do not believe there is any statement about the support 
multiplexing in RFC 5960. The only mention of the subject is in the filed
Erratum. It would be wrong to introduce any statement of requirement or
non-requirement through an Erratum.

So, I'm not hearing anything that persuades me that the Erratum should be
different from what I wrote. If folk want to establish a specific 
that multiplexing is not required, then they can go ahead and write  a 
draft. I
cannot speak for how the WG will greet such a draft.


mpls-tp mailing list