Subject: RE: [PWE3] Y.1720 liased text

From: <[email-masked]>
Date: Thu, 25 Jan 2007 16:45:14 -0000

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:[email-masked]] 
> Sent: 25 January 2007 15:43
> To: pwe3
> Cc: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: <[email-masked]>
Date: Fri, 26 Jan 2007 12:27:54 -0000

Thanks Stewart....this is precisely my issue too.

regards, Neil

> Sent: 26 January 2007 12:17
> To: Huub van Helvoort
> Cc: Harrison,N,Neil,JCGA1 R; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: [PWE3] Re: Y.1720 liased text
> 
> 
> 
> > I checked the appendix II twice (because my left eye is 
> still 10%), I 
> > could not find any text referring to setting the S bit. I only see 
> > that the 4 octet sequence number is placed right after the shim 
> > header.
> 
> The implication of the text is that you can have a packet of the
> form:
> 
> LSE (RFC3032)
> Sequence number
> LSE (RFC3032)
> Payload
> 
> Is that correct?
> 
> If so what is the setting of the S bit (See RFC3032) in each case?
> 
> - Stewart
> 
> 
>

---

From: <[email-masked]>
Date: Fri, 26 Jan 2007 12:39:10 -0000

Thanks Huub....back in 2002 when I wrote this I did flag up the issue of
misconnectivity even then......but reading my own words I was only
thinking about a bottom of stack problem, ie S=1 in preceding header.
The text Stewart picked out of Y.1720/Appendix II seems to imply that
this can also apply to an LSP in the *middle* of an arbitrary
stack....ergo the questions wrt:
-	what are the S bit settings in this stack?
-	what happens if misconnectivity occurs, ie could such an LSP
arriving unexpectedly at some LSR end-up parsing the sequence number
field assuming it had the 'normal' MPLS 4 octet header structure (ie
label/S/EXP/TTL)?.....though as I noted in a previous mail, there is an
even larger issue here that the fields in traffic units should have
consistent semantics network-wide (any mode/technology)

regards, Neil

> From: Huub van Helvoort [mailto:[email-masked]] 
> Sent: 26 January 2007 12:10
> To: Harrison,N,Neil,JCGA1 R
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Hello Neil,
> You responded:
> > Thanks Huub,
> > Can you clarify how the S bit is set when this 1+1 seq no. field is 
> > used?
> 
> I checked the appendix II twice (because my left eye is still 
> 10%), I could not find any text referring to setting the S 
> bit. I only see that the 4 octet sequence number is placed 
> right after the shim header.
> 
> > What is puzzling me is this sentence in the text Stewart extracted 
> > from Y.1720/Appendix 11:
> > 
> > "Note that packet 1+1 can be provided at any level of the 
> hierarchy of 
> > a nested LSP."
> > 
> > I sort-of read this as there can be a set of nested LSPs (hence 
> > concatenated MPLS headers) and that the protection mechanism can be 
> > applied to any one of these within such a stack.  Am I reading this 
> > right?
> 
> I agree with your reading.
> 
> > If I am, then please see my concerns of yesterday on this 
> > thread....which, in essence, is querying what happens if there is 
> > misconnectivity and the LSP carrying the 1+1 Seq No. stuff 
> arrives at 
> > some arbitrary LSR.....how will that LSR parse/interpret 
> the fields it 
> > sees?
> > 
> > I have no background on Y.1720, so my apologies if I am 
> asking a dumb 
> > question.
> 
> There are no dumb questions, only dumb answers. Maybe this is one:
> 
> This morning I did some further investigating where the text 
> originates and found it in the IETF archives: 
> http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-
packet-protection-00.txt

It was also discussed on the MPLS WG list and there I found the answer
to your concerns expressed above (provided by yourself ;-)

http://cell.onecall.net/mhonarc/mpls/2002-Apr/msg00211.html

Cheers, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...