[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PWE3] Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt


Sasha Vainshtein wrote:
Stewart and all,

I am not sure I understand the idea about the new registry.
ECMP safety of the "generic" CW is based on the fact that
value 0 is not used in the "protocol versions" registry, and the decision to swap the CW and RTP header in TDM PWs over MPLS has been based on value 8 (that is what the nibble in question is
in the RTP header) has been allocated for something called PIP in this
registry even if it probably has never been used.
The protocol (and values) will stay the same. We are only
talking about the way that we formally describe the protocol.
The issue was that the IESG did not like PWE3 changing the IP
version registry, but our incomming AD thought that a new
registry, as described, would be more acceptable.

If we go for the new registry, what is going to happen if somebody, at some time, decides to allocate value 4 (or, in fact, any value between 4 and 9) in it? Do we expect IANA to maintain the linkage between the
two seemingly unrelated registries?
4 and 6 will be preallocated, so that they do not get trodden on.

We need to find out if there is any use of 5, 7, 8 and 9. I.e.
are there any routers in the Internet that carry IP versions
5, 7, 8 or 9 over MPLS. If there are, we need to include them
in the registry as pre-allocated values. If not, then a
new implementation would need to operate under the rules
proposed below (i.e. run under 0, 1 or their own value).

The IESG would advise IANA on the usage of this registry.

- Stewart

With best regards,
Sasha Vainshtein
email: sasha@axerra.com <mailto:sasha@axerra.com> tel: +972-3-7659993 (office)
+972-8-9254948 (res.)
+972-58-674833 (cell.)



-----Original Message-----
From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Monday, February 16, 2004 2:00 PM
To: Curtis Villamizar
Cc: avt@ietf.org; pwe3@ietf.org
Subject: [PWE3] Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt



There are some operations that need to be able to distinguish
between IP and non-IP MPLS payloads. For example a router
performing ECMP based on the IP addresses or other information
in the IP header, or an IPFIX/PSAMP packet sampling system
that needs to analyse the payload contents.

We identified this need in PWE3 and proposed a solution. This
is described in sections 5.4.3 and 5.4.4 of the PWE3 Architecture
draft:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-06.txt

In essence we proposed that the nibble that immediately follows
the MPLS bottom label has the following semantics:

Value Meaning
0 PWE3 payload*
1 Identified payload type (see below)
4 IPv4
6 IPv6

* It might be argued that this should be changed to mean
"unidentified payload type"

The identified payload type above is the first nibble
in a longword with the following definition:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1| reserved = 0 | PA | Protocol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As defined by PPP DLL protocol definition |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 14: PWE3 PID

The meaning of the fields of the PWE3 PID (Figure 14) is as follows:


PA protocol authority for the user plane or the control plane
protocol ID
0 = PPP DLL
1-15 = Reserved

Protocol ID
Protocol ID following the format defined by the protocol
authority identified in PA.

Bits 4 to 11 inclusive are reserved for future use and must be zero.

PWE3 currently describes this in terms of historic IP version numbers,
but IESG feedback is that we need to use a new registry.

The proposal is that there is a new "nibble that follows the MPLS
label" registry. This will still have the values and semantics described
above. A new draft describing this will be submitted when the IETF
embargo on new drafts lifts, and the PWE3 architecture draft modified accordingly. Note that this does not change the existing PWE3 protocol
or headers, just the way that we describe the protocol.

If this proposal gains approval, the implication for ecrtp-over-mpls
would be that it should either:

1) Run under first nibble 0
2) Run under first nibble 1 with an ecrtp-over-mpls as the PPP-DLL value
3) Request a first nibble value from the new registry

- Stewart


Curtis Villamizar wrote:


------- Blind-Carbon-Copy

To: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>
cc: avt@ietf.org
Reply-To: curtis@fictitious.org
Subject: Re: I-D
ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt
In-reply-to: Your message of "Mon, 09 Feb 2004 07:39:42 CST."
<9473683187ADC049A855ED2DA739ABCA0201F057@KCCLUST06EVS1.ugd.att.com>
Date: Mon, 09 Feb 2004 11:28:58 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>


In message 
<9473683187ADC049A855ED2DA739ABCA0201F057@KCCLUST06EVS1.ugd.att.com>


, "Ash, Gerald R (Jerry), ALABS" writes:
All,

Please review and comment on 'Protocol Extensions for ECRTP 
over MPLS' http:/


/www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-
protocol-00.txt.
The protocol extensions enable the use of MPLS to route
enhanced compressed
RTP (ECRTP) compressed packets over an MPLS LSP without 
compression/decompres
sion cycles at each router.

The proposed extensions are based on the requirements 
documented in 'Requirem
ents for ECRTP over MPLS' 
http://www.ietf.org/internet-drafts/draft-ash-avt-e


crtp-over-mpls-reqs-01.txt.

Thanks,
Jerry


	Title		: Protocol Extensions for ECRTP over MPLS
	Author(s)	: J. Ash
	Filename	: draft-ash-avt-ecrtp-over-mpls-protocol-00.txt
	Pages		: 0
	Date		: 2004-2-5


Jerry,

This looks to be a very good direction to go in. I've dropped MPLS
from the Cc and put MPLS on the bcc so people know the discussion is
on the AVT mailing list only.

In your encapsulations you should make sure to avoid any 
values in the
first byte that could be mistaken as IPv4 or IPv6 or any of the
encapsulations being worked on by those working on VPN and PW. See
"The PWE3 Control Word", Jonathan Stein, 22-Oct-02,
draft-stein-pwe3-controlword-00.txt, for some early discussion on
that. Note though that "Payload Type" is something that many
providers require so that multipath can be used on IP traffic which
consitutes the majority of traffic yet reordering is avoided for
traffic which cannot be split based on what appears to be 
an IP header
and the IP src/dst pair.

It might be best to reserve a single fixed first byte for 
the "Packet
Type" (and I suggest you make up a name for this shim such as
SCID_Packet_Type) and use the second byte for the packet types that
you have defined. Just as you have to get numbers for SCID_Request
Object and Header_Compression_Reply Object from IANA, you'll have to
coordinate with others over this number space, though it is 
less clear


if IANA is the authority on this quite yet.

Curtis

------- End of Blind-Carbon-Copy





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






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