Protocol Action: 'Detecting MPLS Data Plane Failures' to Proposed Standard

The IESG has approved the following document:

- 'Detecting MPLS Data Plane Failures '
   <draft-ietf-mpls-lsp-ping-13.txt> as a Proposed Standard

This document is the product of the Multiprotocol Label Switching Working 
Group. 

The IESG contact persons are Alex Zinin and Bill Fenner.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-13.txt

Technical Summary

  This document describes a simple and efficient mechanism that can be
  used to detect data plane failures in Multi-Protocol Label Switching
  (MPLS) Label Switched Paths (LSPs).  There are two parts to this
  document: information carried in an MPLS "echo request" and "echo
  reply" for the purposes of fault detection and isolation; and
  mechanisms for reliably sending the echo reply.

Working Group Summary

 The WG had consensus on progressing this document.

Protocol Quality

 The document has been reviewed by Ross Callon, and Russ White for Routing
 area directorate, and by Alex Zinin for the IESG.

RFC Editor Note:

 Section 1.1 Conventions

 [Add new paragraph at end]

 Since this document refers to the MPLS TTL far more frequently than the
 IP TTL, the authors have chosen the convention of using the unqualified
 "TTL" to mean "MPLS TTL" and using "IP TTL" for the TTL value in the IP
 header.

In section:  6. Security

OLD:

   Although this document makes special use of 127/8 address, these are
   used only in conjunction with the UDP port 3503.  Further these
   packets are only processed by routers.  All other hosts MUST treat
   all with a destination address in the range 127/8 in accordance to
   RFC1122.  Any packet received by a router with a destination address
   in the range 127/8 without a destination UDP port of 3503 MUST be
   treated in accordance to RFC1812.

NEW:

   Although this document makes special use of 127/8 address, these are
   used only in conjunction with the UDP port 3503.  Further these
   packets are only processed by routers.  All other hosts MUST treat
   all packets with a destination address in the range 127/8 in
   accordance to RFC1122.  Any packet received by a router with a
   destination address in the range 127/8 without a destination UDP port
   of 3503 MUST be treated in accordance to RFC1812.  In particular, the
   default behavior is to treat packets destined to a 127/8 address as
   "martians".

Section 2.1., para. 9:
OLD:

    The 127/8 range for IPv4 and that same range embedded in an IPv6
    addresses for IPv6 was chosen for a number of reasons.

NEW:

    The 127/8 range for IPv4 and that same range embedded in as
    IPv4-mapped IPv6 addresses for IPv6 was chosen for a number of 
    reasons.

Section 3.3., para. 26:
OLD:

       Key   Type                  Multipath Information
       ---   ----------------      ---------------------
        0    no multipath          Empty (Multipath Length = 0)
        2    IP address            IP addresses
        4    IP address range      low/high address pairs
        8    Bit-masked IPv4       IP address prefix and bit mask
               address set
        9    Bit-masked label set  Label prefix and bit mask

NEW:

       Key   Type                  Multipath Information
       ---   ----------------      ---------------------
        0    no multipath          Empty (Multipath Length = 0)
        2    IP address            IP addresses
        4    IP address range      low/high address pairs
        8    Bit-masked IP         IP address prefix and bit mask
               address set
        9    Bit-masked label set  Label prefix and bit mask

Section 3.3.1., para. 1:
OLD:

    The multipath information encodes labels or addresses which will
    exercise this path.  The multipath information depends on the multi-
    path type.  The contents of the field are shown in the table above.
    IP addresses are drawn from the range 127/8.  Labels are treated as
    numbers, i.e. they are right justified in the field.  For Type 4,
    ranges indicated by Address pairs MUST NOT overlap and MUST be in
    ascending sequence.

NEW:

    The multipath information encodes labels or addresses which will
    exercise this path.  The multipath information depends on the multi-
    path type.  The contents of the field are shown in the table above.
    IPv4 addresses are drawn from the range 127/8; IPv6 addresses are
    drawn from the range 0:0:0:0:0:FFFF:127/104.  Labels are treated as
    numbers, i.e. they are right justified in the field.  For Type 4,
    ranges indicated by Address pairs MUST NOT overlap and MUST be in
    ascending sequence.

Section 3.3.1., para. 2:
OLD:

    Type 8 allows a denser encoding of IP address.  The IPv4 prefix is
    formatted as a base IPv4 address with the non-prefix low order bits
    set to zero.  The maximum prefix length is 27.  Following the prefix
    is a mask of length 2^(32-prefix length) bits.  Each bit set to one
    represents a valid address.  The address is the base IPv4 address
    plus the position of the bit in the mask where the bits are numbered
    left to right beginning with zero.  For example the IP addresses
    127.2.1.0, 127.2.1.5-127.2.1.15, and 127.2.1.20-127.2.1.29 would be
    encoded as follows:

NEW:

    Type 8 allows a denser encoding of IP address.  The IP prefix is
    formatted as a base IP address with the non-prefix low order bits
    set to zero.  The maximum prefix length is 27.  Following the
    prefix is a mask of length 2^(32-prefix length) bits for IPv4 and
    2^(128-prefix length) bits for IPv6.  Each bit set to one
    represents a valid address.  The address is the base IPv4 address
    plus the position of the bit in the mask where the bits are
    numbered left to right beginning with zero.  For example the IPv4
    addresses 127.2.1.0, 127.2.1.5-127.2.1.15, and
    127.2.1.20-127.2.1.29 would be encoded as follows:

        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 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Those same addresses embedded in IPv6 would be encoded as follows:

Section 3.3.1., para. 3:
OLD:

        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 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NEW:

        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 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Section 4.3., para. 1:
OLD:

    An MPLS echo request is a UDP packet.  The IP header is set as fol-
    lows: the source IP address is a routable address of the sender; the
    destination IP address is a (randomly chosen) address from 127/8; the
    IP TTL is set to 1.  The source UDP port is chosen by the sender; the
    destination UDP port is set to 3503 (assigned by IANA for MPLS echo
    requests).  The Router Alert option MUST be set in the IP header.

NEW:

    An MPLS echo request is a UDP packet.  The IP header is set as fol-
    lows: the source IP address is a routable address of the sender; the
    destination IP address is a (randomly chosen) IPv4 address from the
    range 127/8 or IPv6 address from the range 0:0:0:0:0:FFFF:127/104.
    the IP TTL is set to 1.  The source UDP port is chosen by the sender;
    the destination UDP port is set to 3503 (assigned by IANA for MPLS
    echo requests).  The Router Alert option MUST be set in the IP
    header.

Section 4.4., para. 36:
OLD:

             If the IP address in the TLV is 127.0.0.1 or 0::1: {
                Set Best-return-code to 6 ("Upstream Interface Index
                Unknown").  An Interface and Label Stack TLV SHOULD be
                included in the reply and filled with Interface-I and
                Stack-R.
             }

NEW:

             If the IP address in the TLV is 127.0.0.1 or 0::1 {
                Set Best-return-code to 6 ("Upstream Interface Index
                Unknown").  An Interface and Label Stack TLV SHOULD be
                included in the reply and filled with Interface-I and
                Stack-R.
             }

Section 4.4., para. 56:
OLD:

       If received Echo Request contains no Downstream Mapping TLV, or
          the Downstream IP Address is set to 127.0.0.1 or 0::1:
             Go t0 step 6 (Egress FEC Validation).

NEW:

       If received Echo Request contains no Downstream Mapping TLV, or
          the Downstream IP Address is set to 127.0.0.1 or 0::1
             Go t0 step 6 (Egress FEC Validation).

Section 6., para. 8:
OLD:

    Although this document makes special use of 127/8 address, these are
    used only in conjunction with the UDP port 3503.  Further these pack-
    ets are only processed by routers.  All other hosts MUST treat all
    packets with a destination address in the range 127/8 in accordance
    to RFC1122.  Any packet received by a router with a destination
    address in the range 127/8 without a destination UDP port of 3503
    MUST be treated in accordance to RFC1812.

NEW:

    Although this document makes special use of 127/8 address, these are
    used only in conjunction with the UDP port 3503.  Further these pack-
    ets are only processed by routers.  All other hosts MUST treat all
    packets with a destination address in the range 127/8 in accordance
    to RFC1122.  Any packet received by a router with a destination
    address in the range 127/8 without a destination UDP port of 3503
    MUST be treated in accordance to RFC1812.  In particular, the default
    behavior is to treat packets destined to a 127/8 address as 
    "martians".

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce