The MPLS WG Archive

[George Swallow <swallow@cisco.com>]

Version -08 of the RSVP-TE draft contains updates based on
the IESG last call.  They are summarized below.

...George

> Hello RSVP Tunnel Editors,
> 
>  here are the IESG's comments on <draft-ietf-mpls-rsvp-lsp-tunnel-07.txt>
> 
> 1)  The null/best-effort service has already been advanced as a
>      PS.  The CoS object in the RSVP-TE (draft
>     draft-ietf-mpls-rsvp-lsp-tunnel-07.txt) has an object that essentially
>     serves the same purpose.  The CoS object can also provide indications of
>     better than BE traffic, but such indications can also be provided via the
>     objects described in draft-ietf-mpls-diff-ext-07.txt.
>     The IESG would like the now redundant CoS object removed  from the
>     RSVP-TE draft

Section removed.
 
> 2) There is some wording that needs tweaking:
> 
> >         If the DF bit is set in the IP header, then
> >
> >           (a) the datagram MUST NOT be forwarded
> >
> >           (b) Create an ICMP Destination Unreachable Message:
> >                i. set its Code field [12] to "Fragmentation Required
> >                   and DF Set",
> >               ii. set its Next-Hop MTU field [13] to M
> 
>     The above is OK for IPv4, but the ICMP message is called "packet too
>     big" in IPv6. Also, there is no DF bit in the IPv6 header. So some
>     wordsmithing seems in order.


      1. Let N be the number of bytes in the label stack (i.e, 4 times
         the number of label stack entries) including labels to be added 
         by this node.

      2. Let M be the smaller of the "Maximum Initially Labeled IP 
         Datagram Size" or of (Path MTU - N).

      When the size of an IPv4 datagram (without labels) exceeds the 
        value of M,
              
        If the DF bit is not set in the IPv4 header, then

          (a) the datagram MUST be broken into fragments, each of whose 
              size is no greater than M, and

          (b) each fragment MUST be labeled and then forwarded.

        If the DF bit is set in the IPv4 header, then

          (a) the datagram MUST NOT be forwarded

          (b) Create an ICMP Destination Unreachable Message:
               i. set its Code field [12] to "Fragmentation Required
                  and DF Set",
              ii. set its Next-Hop MTU field [13] to M

          (c) If possible, transmit the ICMP Destination Unreachable
              Message to the source of the of the discarded datagram.

      When the size of an IPv6 datagram (without labels) exceeds the 
        value of M,
              
          (a) the datagram MUST NOT be forwarded

          (b) Create an ICMP Packet too Big Message with the 
              Next-Hop link MTU field [14] set to M

          (c) If possible, transmit the ICMP Packet too Big Message
              to the source of the of the discarded datagram.

 
> 3)  Reword. IANA is the authority
> 
> > 7. IANA Considerations
> >
> >    The responsible Internet authority (presently called the IANA)
> >    assigns values to RSVP protocol parameters.  With the current
> 
>     Suggested rewording:
> 
>     IANA assigns values to RSVP protocol parameters.  With the current ...

Reworded as suggested.
 
> 4)  The IANA section does not give specific guidance on the
>     conditions under which IANA  grants requests for numbers. See RFC 2434
>     for details.
> 
EXPLICIT_ROUTE Subobject Type 

   EXPLICIT_ROUTE Subobject Type is a 7-bit number that identifies the
   function of the subobject.  There are no range restrictions.  All
   possible values except zero are available for assignment.

   Following the policies outlined in [15], subobject types in the range
   0x00 - 0x3F are allocated through an IETF Consensus action, codes in
   the range 00x40 - 0x5F are allocated as First Come First Served, and
   codes in the range 0x60 - 0x7F are reserved for Private Use.


ROUTE_RECORD Subobject Type

   ROUTE_RECORD Subobject Type is an 8-bit number that identifies the
   function of the subobject.  There are no range restrictions.  All
   possible values except zero are available for assignment.

   Following the policies outlined in [15], subobject types in the range
   0x00 - 0x7F are allocated through an IETF Consensus action, codes in
   the range 00x80 - 0xBF are allocated as First Come First Served, and
   codes in the range 0xC0 - 0xFF are reserved for Private Use.  

> 5) Some of the author information is now out of date.
> 

Updated.

> thanks,
> ---rob


Also added the following error value to the Notify error code in
response to my own last call comment.

          3    Tunnel locally repaired




======================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824