The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2007-Jan> msg00139



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[mpls] Y.1720 liased text

  • From: Stewart Bryant <stbryant@cisco.com>
  • Date: Thu, 25 Jan 2007 15:42:48 +0000
  • Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass (sig from cisco.com/amsdkim2001 verified; );
  • Cc: mpls@ietf.org
  • DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2023; t=1169739770;x=1170603770; c=relaxed/simple; s=amsdkim2001;h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;d=cisco.com; i=stbryant@cisco.com;z=From:=20Stewart=20Bryant=20<stbryant@cisco.com>|Subject:=20Y.1720=20liased=20text |Sender:=20;bh=LpUbxPuuuLqeGCNsmC+xJSMhsmTJvaR6WNljA4iKNB4=;b=odI1FyZueofTxCdoRqXJizQPYGqh5rLaG5ENEkQnUjXAtlvRS43IVnDAoJs9/iXnOKDd4pogg8zJmzt0U0V5v2O4AaE4tE3ZXAveQCavMxpO07mUj9+11LvLSGO1w5eu;
  • User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)

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
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls