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

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: mpls-tp-bounces@ietf.org 
> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel
> Sent: 10 November 2010 07:39
> To: ahmpls-tp@lists.itu.int; mpls@ietf.org; mpls-tp@ietf.org
> 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
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 