The MPLS WG Archive

[<neil.2.harrison@bt.com>]

Hi Stewart,

Well, there are certainly some issues when the semantic of a specific
field in a traffic unit is NOT consistent in any layer network.  For
example, the MPLS label field can currently take on at least 3 different
semantics, viz:
-	a proxy for destination identifier (ie the usual
label-swapping/forwarding paradigm)
-	a proxy for a source identifier (ie a necessary consequence of
(lower level) LSP merging)
-	a 'functional action', eg various labels in the reserved
code-space 0-15.

This is not good practice IMO....and one observation here would be that
under misconnectivity incorrect downstream decisions could arise (noting
that this may not simply be between LSPs at the same level but also
across LSPs at different levels).  Though to be strictly accurate, since
the 'functional action' labels (0-15) are partitioned from the rest of
the label space the consequence has some certainty of (incorrect)
action.

I am not familiar with the content of Y.1720, but from what you describe
below it seems we can add yet another semantic to the label field.....or
at least *its interpretation as a label field*, under misconnectivity,
by some LSR that unexpectedly receives it (but also see Note below).
Does not sound very good to me.

Note - If S=1 in the preceding MPLS header then there seems less of a
problem than if S=0.....which may appear an odd observation to make, but
I do so because of this specific text Stewart extracted from Y.1720
Appendix II (note the highlighted word 'any'):

"Note that packet 1+1 can be provided at *any* level of the hierarchy of
a nested LSP."

regards, Neil

> -----Original Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com] 
> Sent: 25 January 2007 15:43
> To: pwe3
> Cc: mpls@ietf.org
> Subject: [PWE3] Y.1720 liased text
> 
> 
> Please could some else from the PWE3 WG take a look at
> the following liaison statement.
> 
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=289
> 
> I think that we need to respond with the following, but
> I would like someone else to check my interpretation of
> their text and the IETF MPLS design.
> 
> An appropriate response would seem to be:
> 
> 
> The PWE3 WG is concerned about the consented text for Y.1720 
> that has been liaised to us.
> 
> In particular the following text in Y.1720 looks like a 
> violation of the IETF MPLS architecture.
> 
> Appendix II
> 
> Packet 1+1 example realization
> The packet 1+1 scheme can be implemented by using a sequence as an 
> identifier. The sequence number can be carried as the first 
> four bytes 
> inside the shim header of the LSP providing packet 1+1. Since the 
> ingress and egress nodes must be aware of each LSP 
> participating in the 
> packet 1+1, the egress node will recognize that there is a sequence 
> number inside the label. It will use the sequence number for 
> selection 
> purpose and then remove it before forwarding the accepted packet 
> further. Note that packet 1+1 can be provided at any level of the 
> hierarchy of a nested LSP. Figure II.1 illustrates the 
> sequence number 
> position behind the 4-bytes MPLS encapsulation header.
> 
> 
> This implies that the Y.1720 is proposing to place an item in 
> the label stack that does not conform to the design of an 
> RFC3032 label stack entry.
> 
> This breaks the MPLS invariant that any item that follows
> an LSE with the S bit set to zero MUST be another LSE.
> 
> It also breaks the guideline that any item that follows
> a MPLS LSE should either be an IP packet or should conform
> to the design described in RFC4385.
> 
> It is our view that all MPLS packet designs must adhere to
> the design invariants and guidelines produced by the IETF
> and the text in Appendix II, and any technical design that 
> conflicts with the IETF design needs amendment before Y.1720 
> is published in its final form.
> 
> Regards
> 
> Stewart
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls