Subject: [mpls] Y.1720 liased text

From: Stewart Bryant <[email-masked]>
Date: Thu, 25 Jan 2007 15:42:48 +0000

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

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

---

From: "Trowbridge, Stephen J \(Steve\)" <[email-masked]>
Date: Thu, 25 Jan 2007 12:27:59 -0600

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:[email-masked]] 
Sent: Thursday, January 25, 2007 8:43 AM
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.

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.

In particular the following text in Y.1720 looks like a violation of the
IETF MPLS architecture.

Appendix II

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

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 25 Jan 2007 22:49:44 +0100

Hello Steve,

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

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

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Jan 2007 11:35:22 +0000

> Regards, Huub (editor of Y.1720).

Not withstanding that, the issue of non-LSE data within
the stack is a valid concern.

What have stack design was implemented and deployed?

Stewart

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 26 Jan 2007 13:15:18 +0100

Hello Stewart,

> What have stack design was implemented and deployed?

Would you please be so kind to elaborate/expand the last
sentence, English is my second language, so I may misinterpret
what you want to express.

Kind regards, huub.