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

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
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> 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:
> > 
> > 
> > 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
> 
> 
> 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
> 

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

---

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.