Subject: RE: Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol- 00.txt

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 16 Feb 2004 14:26:08 +0200

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.

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?

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Monday, February 16, 2004 2:00 PM
> To: Curtis Villamizar
> Cc: [email-masked]; [email-masked]
> 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" <[email-masked]>
> > cc: [email-masked]
> > Reply-To: [email-masked]
> > 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."
> >              
> <[email-masked]> 
> > Date: Mon, 09 Feb 2004 11:28:58 -0500
> > From: Curtis Villamizar <[email-masked]>
> > 
> > 
> > In message 
> <[email-masked]>
> > , "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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 16 Feb 2004 13:06:11 +0000

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

> 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

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 16 Feb 2004 21:05:14 +0200

Curtis and Stewart,
Thank you for the detailed explanation.

To handle the new registry in a "safe" way, I would suggest to specify
that only values 0 to 3 can be used, with 0 assigned to unindentified 
payload type, 1 - to identified payload type and leave 2 and 3 unassigned.

In parallel IANA should declare values 1 to 3 (currently unassigned)
as reserved in the version numbers registry to prevent any attempt to 
assign these values in future.

Does it make sense?

With best regards,
                                   Sasha Vainshtein

> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Monday, February 16, 2004 5:08 PM
> To: [email-masked]
> Cc: Sasha Vainshtein; [email-masked]; [email-masked]; Curtis Villamizar
> Subject: Re: [PWE3] Re: I-D 
> ACTION:draft-ash-avt-ecrtp-over-mpls-protocol- 00.txt 
> 
> 
> 
> In message <[email-masked]>, Stewart Bryant writes:
> > 
> > 
> For all pracical purposes 7, 8 and 9 are not used at all, over MPLS or
> otherwise.  These are left overs from the competing proposals to
> replace IPv4.  The decision was made to go with IPv6.  Since then none
> of them have been used.  It would be reasonable for IESG/IANA to
> declare these values as having been temporarily assigned for protocol
> experiments which are long ago over and available for reclaim, but
> apparently they are choosing not to do so.  There is (or was at some
> point) some use of 5 (ST-II).  Use of ST-II may have disappeared, but
> I'm uncertain of that.
> 
> IESG does have a very good point in that what these are being used for
> is not IP version numbers where the other 20 bytes are also an IP
> header.  That IPv4 and IPv6 values are reserved in the new registry to
> allow the largest single contributor of traffic to be placed in MPLS
> without a shim is good, and not breaking very widespread current usage
> is good.  If you reserve any number for "other IP version" then an IP
> packet with 5, 7, 8 and 9 or any new assignments of IP versions could
> be carried with a shim.
> 
> Curtis
>

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 16 Feb 2004 15:17:24 -0500

In message <AF5018AC03D1D411ABB70002A5091326D31BE8@TLV1>, Sasha Vainshtein writ
> tel:       +972-3-7659993 (office)

No it doesn't make sense.  Separate number spaces allow a value to be
reserved for "other IP version" in which case there would be a shim
followed by the complete 20 byte IP header with the version number
filled in there.  The values of 4 and 6 can be marked as "reserved to
accommodate direct encapsulation of IPv4 and IPv6".  If you wanted to
be nice to ST-II then you could also reserve the number 5, but there
is no ST-II over MPLS currently flowing so there is no concern over
breaking a current deployment by requiring a shim.

For the purpose of multipath, 4 and 6 are splitable, looking into the
IPv4 or IPv6 headers for src/dst addresses.  Any other value is either
not supported by the multipath implementation or if supported, must
look deeper into the packet.  For example with TUBA traffic (version
7?) the shim would have the value for "other IP version" followed by a
full header with the actual version in it.  The TUBA traffic would be
splitable by looking into the 20 byte addresses (but chances of
running at line rate would be real small which is part of why we don't
see any TUBA traffic).

Curtis

ps - No modern router supports IPv 7 8, or 9.  No commercial router,
or ISP deployed router ever supported IPv 7 8, or 9.  No IPv 7 8, or 9
has been seen on a commercial network in nearly a decade.  Other than
TUBA (over OSI) there probably has never been any of this traffic on
anything but a demo setup.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 16 Feb 2004 10:08:24 -0500

Curtis