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

<> Wed, 10 November 2010 09:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84B283A69F1; Wed, 10 Nov 2010 01:00:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hKHQLir4zU7n; Wed, 10 Nov 2010 01:00:16 -0800 (PST)
Received: from (smtp63.intersmtp.COM []) by (Postfix) with ESMTP id 4D4793A6947; Wed, 10 Nov 2010 01:00:15 -0800 (PST)
Received: from ( by RDW083A007ED63.smtp-e3.hygiene.service ( with Microsoft SMTP Server (TLS) id; Wed, 10 Nov 2010 09:00:41 +0000
Received: from ([]) by ([]) with mapi; Wed, 10 Nov 2010 09:00:40 +0000
Date: Wed, 10 Nov 2010 09:00:38 +0000
Thread-Topic: [mpls-tp] Progressing Resolution of Erratum 2533 (RFC 5960)
Thread-Index: AcuAqkGWWLljIycMSaaDutg2dx6+TwACnl8Q
Message-ID: <>
References: <0d0301cb80aa$4a9d75a0$dfd860e0$>
In-Reply-To: <0d0301cb80aa$4a9d75a0$dfd860e0$>
Accept-Language: en-US, en-GB
Content-Language: en-US
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 09:00:17 -0000

These are the same issue Adrian.  That is, if the server respects the single-source requirement of a connection (crucial for deterministic resource management anyway) then provided it carries only a single client over its (connection) lifetime one does not require a PID field...this information is carried as a semantic by the parent connection construct.  We can also omit a SA from the child traffic units of a connection for exactly the same (single source) reason.

Note that this is not true for a cl-ps server...such as native Ethernet say.  In a cl-ps layer network the traffic unit MUST carry 3 absolute labels:
-	full SA label
-	full (unswapped) DA label (for forwarding)
-	PID label 

However, since a cl-ps server cannot provide deterministic resource management it is not a good idea to use it as a transport network.

regards, Neil

> -----Original Message-----
> From: 
> [] On Behalf Of Adrian Farrel
> Sent: 10 November 2010 07:39
> To:;;
> Subject: [mpls-tp] Progressing Resolution of Erratum 2533 (RFC 5960)
> All,
> Thank you for your input and suggestions on this topic.
> To be clear, we are not attempting to reach consensus on what 
> change to make, but I am listening to your individual opinions.
> In deciding what Erratum to post, I will select a form of 
> words that clarifies 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 of this document.
> The Erratum process is intended to correct typographic or 
> rendition issues that 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 by 
> revising the work through the IETF consensus process. 
> draft-ietf-mpls-tp-uni-nni 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 a 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 be explicit 
> or implicit. The text also notes that the use of explicit 
> identification of payload is a facilitator for demultiplexing 
> multiplexed payloads.
> The second concern is whether there is a requirement to 
> support payload multiplexing. I do not believe there is any 
> statement about the support for 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 requirement 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.
> Thanks,
> Adrian
> _______________________________________________
> mpls-tp mailing list