The MPLS WG Archive

["Trowbridge, Stephen J \(Steve\)" <sjtrowbridge@alcatel-lucent.com>]

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?
Regards,
Steve

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

_______________________________________________
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