The MPLS WG Archive

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

Thanks Huub, 

Can you clarify how the S bit is set when this 1+1 seq no. field is
used?  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?

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.

regards, Neil

> -----Original Message-----
> From: Huub van Helvoort [mailto:hhelvoort@chello.nl] 
> Sent: 25 January 2007 21:50
> To: Trowbridge, Stephen J (Steve)
> Cc: mpls@ietf.org; Ghani Abbas (BE/ETL); pwe3; Stewart Bryant
> Subject: Re: [PWE3] Y.1720 liased text
> 
> 
> Hello Steve,
> 
> You wrote:
> 
> > Hi Stewart,
> > I am not really close enough to Y.1720 to respond regarding the 
> > technical content, but what was just approved is not a new 
> > Recommendation. It is a minor maintenance update to a 
> Recommendation 
> > originally developed in ITU-T Study Group 13 that has been in force 
> > since April 2003. All protection switching work was 
> collected together 
> > in ITU-T Study Group 15 with the reorganization of work at 
> the end of 
> > 2004, so it fell to us (WP3/15 chair hat on) to do the maintenance 
> > update.
> > 
> > If anyone on this list is more familiar with original 
> Y.1720 than me, 
> > I think it would be helpful to know whether you think that we broke 
> > something in the process of doing the maintenance update, 
> or if these 
> > are new concerns being raised in 2007 about a document that 
> has been 
> > approved and in force since 2003?
> 
> It was indeed a maintenance update. The previous version was 
> consented in the 07/2003 plenary and approved in 09/2003.
> 
> The Appendix mentioned was not altered after that revision,
> so this text is there for three years.
> 
> Regards, Huub (editor of Y.1720).
> 
> 
> > -----Original Message-----
> > From: Stewart Bryant [mailto:stbryant@cisco.com]
> > Sent: Thursday, January 25, 2007 8:43 AM
> > 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
> 
> -- 
> ================================================================
>                    http://www.van-helvoort.eu/ 
> ================================================================
> Always remember that you are unique...just like everyone else...
> 
> _______________________________________________
> 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