The MPLS WG Archive

[Huub van Helvoort <hhelvoort@chello.nl>]

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...

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