Subject: [mpls] Last-last call on LSR Self Test

From: George Swallow <[email-masked]>
Date: Thu, 10 Nov 2005 20:15:53 -0500

This begins a one week last call on LSR Self Test, 
draft-ietf-mpls-lsr-self-test-06.txt

The last call ends 17 NOV 2005 24:00 UTC.

The last call is limited to the changes made as a result of the previous
last call.  Attached are the diffs from version 05 to 06.

...George

Section 1., para. 1:
OLD:

    This document defines a means for a Label-Switching Router (LSR) to
    verify that its dataplane is functioning for certain key Multi-Proto-
    col Label Switching (MPLS) applications, including unicast forwarding
    based on LDP [LDP] and traffic engineering tunnels based on [RSVP-
    TE].  MPLS Echo Request and MPLS Echo Reply messages [LSP-Ping] are
    extended to do the actual probing.  The pings are sent to an upstream
    neighbor, looped back through the LSR under test and intercepted, by
    means of TTL expiration by a downstream neighbor.  Extensions to LSP-
    Ping [LSP-Ping] are defined to allow the down stream neighbor to
    report the test results.

NEW:

    This document defines a means for a Label-Switching Router (LSR) to
    verify that its data plane is functioning for certain key Multi-Pro-
    tocol Label Switching (MPLS) applications, including unicast forward-
    ing based on LDP [LDP] and traffic engineering tunnels based on
    [RSVP-TE].  MPLS Verification Request and MPLS Verification Reply
    messages are defined to do the actual probing.  The pings are sent to
    an upstream neighbor, looped back through the LSR under test and
    intercepted, by means of TTL expiration by a downstream neighbor.

Section 1., para. 2:
OLD:

    In order to minimize the load on upstream LSRs a new loopback FEC is
    defined. Receipt of a packet labeled with a loopback label will cause
    the advertising LSR to pop the label off the label stack and send the
    packet out the advertised interface.

NEW:

    In order to minimize the load on upstream LSRs a loopback FEC Type is
    defined. Labels advertised with this FEC Type are referred to as
    loopback labels.  Receipt of a packet labeled with a loopback label
    will cause the advertising LSR to pop the label off the label stack
    and send the packet out the advertised interface.

Section 1., para. 3:
OLD:

    Note that use of a loopback allows an LSR to test label entries for
    which the LSR is not currently some neighbor's next hop.  In this way
    label entries can be verified prior to the occurrence of a routing
    change.

NEW:

    Use of a loopback mechnism allows an LSR to test label entries which
    are not currently in use.  For example many LSRs advertise label map-
    pings for all IPv4 routes to all of their neighbors.  For some por-
    tion of these their neighbor LSR is not currently upstream and the
    label entry is not used.  But if the neighbors best path to a desti-
    nation changes, that route and the associated label entry will be
    used.  An LSR can loop traffic through a "non-upstream" LSR because
    that LSR is acting only on the loopback label and not on the underly-
    ing label associated with the actual FEC being tested.  In this way
    label entries can be verified prior to the occurrence of a routing
    change.

Section 1., para. 4:
OLD:

    Some routing protocls, most notably OSPF have no means of exchanging
    the "Link Local Identifiers" used to identify unnumbered links and
    components of bundled links.  These test procedures can be used to
    associate the neighbor's interfaces with the probing LSRs interfaces.
    This is achieved by simply having the TTL of the MPLS Ping expire one
    hop sooner, i.e. at the testing LSR itself.

NEW:

    Some routing protocols, most notably OSPF have no means of exchanging
    the "Link Local Identifiers" used to identify unnumbered links and
    components of bundled links.  These test procedures can be used to
    associate the neighbor's interfaces with the probing LSRs interfaces.
    This is achieved by simply having the TTL of the MPLS Ping expire one
    hop sooner, i.e. at the testing LSR itself.

Section 2., para. 1:
OLD:

    The Loopback FEC type is defined to enable an upstream neighbor to
    assist in LSR self-testing at very low cost.  This FEC causes the
    loopback to occur in the dataplane without control plane involvement
    beyond the initial LDP exchange and dataplane setup.  The FEC also
    carries information to indicate the desired encapsulation should it
    be the only label in a received label stack.  Values are defined for
    IPv4 and IPv6.

NEW:

    The Loopback FEC type is defined to enable an upstream neighbor to
    assist in LSR self-testing at very low cost.  This FEC causes the
    loopback to occur in the dataplane without control plane involvement
    beyond the initial LDP exchange and data-plane setup.  The FEC also
    carries information to indicate the desired encapsulation should it
    be the only label in a received label stack.  Values are defined for
    IPv4 and IPv6.

Section 2.1., para. 3:
OLD:

          Must be set to zero on transmission and ignored on receipt.

NEW:

          MUST be set to zero on transmission and ignored on receipt.

Section 2.1., para. 6:
OLD:

          Note that this type also indicates the encapsulation type for payloads
          that have a label stack contain the one loopback label.

NEW:

          Note that these type values also indicate the encapsulation (IPv4 or
          IPv6) for payloads that have a label stack containing only a loopback
          label.

Section 2.2., para. 1:
OLD:

    It is RECOMMENDED that loopback labels only be distributed in
    response to a Label Request message, irrespective of the label adver-
    tisement mode of the LDP session.  However it is recognized that in
    certain cases such as OSPF with unnumbered links, the upstream LSR
    may not have sufficiently detailed information of the neighbor's link
    identifier to form the request.  In these cases, the downstream LSR
    will need to be configured to make unsolicited advertisements.

NEW:

    It is RECOMMENDED that loopback labels only be distributed in
    response to a Label Request message, irrespective of the label adver-
    tisement mode of the LDP session.  However it is recognized that in
    certain cases such as OSPF with unnumbered links, the upstream LSR
    may not have sufficiently detailed information of the neighbor's link
    identifier to form the request.  In these cases, the downstream LSR
    MAY be configured to make unsolicited advertisements.

Section 3., para. 1:
OLD:

    A self test operation involves three LSRs, the LSR doing the test, an
    upstream neighbor and a downstream neighbor.  We refer to these as
    LSRs T, U, and D respectively.  In order to minimize the processing
    load on LSR-D, two new LSP Ping messages are defined, called the MPLS
    Data Plane Verification Request and the MPLS Data Plane Verification
    Reply.  These messages are used to allow LSR-T to obtain the label
    stack, address and interface information of LSR-D.
 
    If FEC verification is required, the MPLS Echo Request and Reply mes-
    sages are used.

NEW:

    A self test operation involves three LSRs, the LSR doing the test, an
    upstream neighbor and a downstream LSR.  Upstream here is with
    respect to the flow of the test (which in some cases could be differ-
    ent than the normal sense of upstream in IP routing).  We refer to
    these as LSRs T, U, and D respectively.  In order to minimize the
    processing load on LSR-D, two new LSP Ping messages are defined,
    called the MPLS Data Plane Verification Request and the MPLS Data
    Plane Verification Reply.  These messages are used to allow LSR-T to
    obtain the label stack, address and interface information of LSR-D.

Section 3.1., para. 6:
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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Version Number        |         Must Be Zero          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Message Type |   Reply mode  |  Return Code  | Return Subcode|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Sender's Handle                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Sequence Number                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            TLVs ...                           |
    .                                                               .
    .                                                               .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The MPLS Data Plane Verification Request message MAY contain the fol-
    lowing objects:

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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Version Number        |         MUST Be Zero          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Message Type |   Reply mode  |  Return Code  | Return Subcode|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Sender's Handle                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Sequence Number                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            TLVs ...                           |
    .                                                               .
    .                                                               .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    The MPLS Data Plane Verification Request message MAY contain the fol-
    lowing objects:

Section 3.1., para. 7:
OLD:

           Type #               Object
           ------               -----------
             3                  Pad
             5                  Vendor Enterprise Code
            11 (provisional)    IPv4 Reply-to Object
            12 (provisional)    IPv6 Reply-to Object

NEW:

           Type #               Object
           ------               -----------
             3                  Pad
               10                  Reply TOS Byte
               11 (provisional)    IPv4 Reply-to Address
               12 (provisional)    IPv6 Reply-to Address
            64512-65535            Vendor Private TLVs

Section 3.1., para. 9:
OLD:

           Type #            Object
           ------            -----------
             3               Pad
             4               Error Code
             5               Vendor Enterprise Code
             7               IPv4 Interface and Label Stack Object
             8               IPv6 Interface and Label Stack Object

NEW:

           Type #            Object
           ------            -----------
                7                  Interface and Label Stack
                9                  Errored TLVs
            64512-65535            Vendor Private TLVs

Section 3.2., para. 1:
OLD:

    MPLS Data Plane Verification Request messages MAY be sent to port
    3503 as is used for [LSP-PING].  However to aid implementations that
    wish to handle these messages at a lower level than MPLS Echo Request
    messages another UDP port, tbd, is provided.  Port tbd SHOULD be used
    by default.  The source UDP port, as in [LSP-PING] is chosen by the
    sender.

NEW:

    MPLS Data Plane Verification Request messages MAY be sent to port
    3503 as is used for [LSP-PING].  However to aid implementations that
    wish to handle these messages at a lower level than MPLS Echo Request
    messages another UDP port, <tbd>, is provided.  Port <tbd> SHOULD be
    used by default.  The source UDP port, as in [LSP-PING] is chosen by
    the sender.

Section 3.2., para. 2:
OLD:

 3.3. Reply-To Object

NEW:

 3.3. Reply-To Address Object

Section 3.2., para. 4:
OLD:

 3.3.1. IPv4 Reply-To Object

NEW:

 3.3.1. IPv4 Reply-To Address Object

Section 3.2., para. 5:
OLD:

    The length of an IPv4 Reply-To Object is 4 octets; the value field
    has the following format:

NEW:

    The length of an IPv4 Reply-to Address object is 4 octets; the value
    field has the following format:

Section 3.2., para. 9:
OLD:

 3.3.2. IPv6 Reply-To Object

NEW:

 3.3.2. IPv6 Reply-To Address Object

Section 3.2., para. 10:
OLD:

    The length of an IPv6 Reply-To Object is 16 octets; the value field
    has the following format:

NEW:

    The length of an IPv6 Reply-to Address object is 16 octets; the value
    field has the following format:

Section 3.4., para. 2:
OLD:

    The LSR creates an MPLS Data Plane Verification Request message and
    includes a Data Plane Verification Object.  Optionally a FEC Stack
    TLV may be included.  In this case an MPLS Echo Request Message MUST
    be used.

NEW:

    The LSR creates an MPLS Data Plane Verification Request message.

Section 3.4., para. 3:
OLD:

    In normal use, the source address is set to an address belonging to
    the LSR and the destination set to an address in the range of 127/8.
    The incoming label stack (if any) is prepended to the packet.  The
    TTL of these labels and the packet header SHOULD be set to appropri-
    ate values - 2 for those labels and/or header which will be processed
    by this node when the packet is looped back; 1 for those labels
    and/or header which will be carried through.  Finally the loopback
    label bound to the incoming interface is prepended to the packet.  In
    the case of an otherwise unlabeled packet the label's FEC MUST indi-
    cate the appropriate IP version.  The TTL is set such that it will
    have the value of 3 on the wire.

NEW:

    In normal use, the source address is set to an address belonging to
    the LSR and the destination set to an address in the range of 127/8.
 
    The incoming label stack (if any) is prepended to the packet.  The
    TTL of these labels and the packet header SHOULD be set to appropri-
    ate values - 2 for those labels and/or header which will be processed
    by this node when the packet is looped back; 1 for those labels
    and/or header which will be carried through.  Finally the loopback
    label bound to the incoming interface is prepended to the packet.  In
    the case of an otherwise unlabeled packet the label's FEC MUST indi-
    cate the appropriate IP version.  The TTL is set such that it will
    have the value of 3 on the wire.

Section 3.4., para. 5:
OLD:

    In diagnostic situations, the source and destination addresses MAY be
    set to any value.  In this case, a Reply-to IPv4 or IPv6 Object MUST
    be included.  The IP TTL MUST be set to 1.  The TTL of labels other
    than the loopback label MUST be set to appropriate values - 2 for
    those labels which will be process by this LSR when the packet is
    looped back; 1 for those labels which will be carried through.

NEW:

    In diagnostic situations, the source and destination addresses MAY be
    set to any value.  In this case, a Reply-to IPv4 or IPv6 Address
    object MUST be included.  The IP TTL MUST be set to 1.  The TTL of
    labels other than the loopback label MUST be set to appropriate val-
    ues - 2 for those labels which will be process by this LSR when the
    packet is looped back; 1 for those labels which will be carried
    through.

Section 3.4., para. 6:
OLD:

    In some MPLS deployments TTL hiding is used to make a providers net-
    work appear as a single hop.  That is the TTL in the imposed label
    does not refect the TTL of the received packet.  It is RECOMMENDED
    that testing of label imposition SHOULD NOT be performed in such cir-
    cumstances as the Echo Request will in most case travel multiple
    hops.

NEW:

    In some MPLS deployments TTL hiding is used to make a providers net-
    work appear as a single hop.  That is the TTL in the imposed label
    does not reflect the TTL of the received packet.  It is RECOMMENDED
    that testing of label imposition SHOULD NOT be performed in such cir-
    cumstances as the Verification Request will in most case travel mul-
    tiple hops.

Section 3.5., para. 2:
OLD:

    X then parses the packet to ensure that it is a well-formed packet,
    and that the TLVs that are not marked "Ignore" are understood.  If
    not, X SHOULD send an MPLS echo reply with the Return Code set to
    "Malformed echo request received" or "TLV not understood" (as appro-
    priate), and the Subcode set to zero.  In the latter case, the misun-
    derstood TLVs (only) are included in the reply.

NEW:

    X then parses the packet to ensure that it is a well-formed packet,
    and that the TLVs that are not marked "Ignore" are understood.  If
    not, X SHOULD set the Return Code set to "Malformed echo request
    received" or "TLV not understood" (as appropriate), and the Subcode
    set to zero.  In the latter case, the misunderstood TLVs (only) are
    included in the reply.

Section 3.5., para. 3:
OLD:

    If the echo request is good, X notes the interface I over which the
    echo was received, and the label stack with which it came. If the
    MPLS echo request contained a Downstream Verification object, then X
    must format this information as a Downstream Verification object and
    include it in its MPLS echo reply message.

NEW:

    If the Verification Request is good, X MUST note the interface and
    label stack of the received Verification Request and format this
    information as a Downstream Verification object.  This object is
    included in the MPLS Verification Reply message.  The Return Code and
    Subcode MUST be set to zero, indicating "No return code".

Section 3.5., para. 4:
OLD:

    The source address of the Reply message MUST be an address of the
    replying LSR.  If the request included a Reply-to IPv4 or IPv6
    Object, the MPLS Data Plane Verification Reply message MUST be sent
    to that address.  Otherwise the Reply message is sent to the source
    address of the Verification Request message.

NEW:

    The source address of the Reply message MUST be an address of the
    replying LSR.  If the request included a Reply-to IPv4 or IPv6
    Address object, the MPLS Data Plane Verification Reply message MUST
    be sent to that address.  Otherwise the Reply message is sent to the
    source address of the Verification Request message.

Section 5., para. 4:
OLD:

        LSP Ping Object Type    11        IPv4 Reply-to Object
        LSP Ping Object Type    12        IPv6 Reply-to Object

NEW:

        LSP Ping Object Type    11        IPv4 Reply-to Address
        LSP Ping Object Type    12        IPv6 Reply-to Address

Section 7.2., para. 2:
OLD:

 Authors' Addresses

NEW:

 8. Authors' Addresses

Section 7.2., para. 11:
OLD:

    January 2006

NEW:

    April 2006

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Monique Morrow <[email-masked]>
Date: Sun, 13 Nov 2005 11:00:25 -0500

Support last call.

/monique