Skip to main content

Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute Mechanisms
draft-rathi-mpls-egress-tlv-for-nil-fec-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Deepti N. Rathi , Kapil Arora , Shraddha Hegde
Last updated 2020-09-29
Replaced by draft-ietf-mpls-egress-tlv-for-nil-fec, draft-ietf-mpls-egress-tlv-for-nil-fec
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-rathi-mpls-egress-tlv-for-nil-fec-00
Routing area                                                    D. Rathi
Internet-Draft                                                  K. Arora
Intended status: Standards Track                                S. Hegde
Expires: April 2, 2021                             Juniper Networks Inc.
                                                      September 29, 2020

   Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute
                               Mechanisms
               draft-rathi-mpls-egress-tlv-for-nil-fec-00

Abstract

   Segment routing supports the creation of explicit paths using
   adjacency- sids, node-sids, and anycast-sids.  The SR-TE paths are
   built by stacking the labels that represent the nodes and links in
   the explicit path.  A very useful Operations And Maintenance (OAM)
   requirement is to be able to ping and trace these paths.  A simple
   mpls ping/traceroute mechanism comprises of ability to traverse the
   SR-TE path without having to validate the control plane state.  This
   document describes mpls ping and traceroute procedures using Nil FEC
   with additional extensions.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 2, 2021.

Rathi, et al.             Expires April 2, 2021                 [Page 1]
Internet-Draft           Egress TLV for Nil FEC           September 2020

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem with Nil FEC  . . . . . . . . . . . . . . . . . . . .   3
   3.  Egress TLV  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Procedure . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Sending Egress TLV in MPLS Echo Request . . . . . . . . .   4
     4.2.  Receiving Egress TLV in MPLS Echo Request . . . . . . . .   5
   5.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  New TLV . . . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   MPLS ping and traceroute mechanism as described in [RFC8029] and
   related extensions for SR as defined in [RFC8287] is very useful to
   precisely validate the control plane and data plane synchronization.
   It also provides ability to traverse multiple ECMP paths and validate
   each of the ECMP paths.

   In certain usecases, the traffic engineered (TE) paths are built
   using mechanisms described in
   [I.D-ietf-spring-segment-routing-policy].  When the TE paths are
   built by the controller, the head-end routers may not have the
   complete database of the network and may not be aware of the FEC
   associated with labels that are used in the label stack.  In such
   cases, it is useful to have ability to traverse the paths using ping

Rathi, et al.             Expires April 2, 2021                 [Page 2]
Internet-Draft           Egress TLV for Nil FEC           September 2020

   and traceroute without having to obtain the Forwarding Equivalence
   Class (FEC) for each label.  RFC 8029 supports this mechanism with
   Nil FEC.  Nil FEC consists of the label and there is no other
   associated FEC information.  The procedures described in RFC 8029 are
   mostly applicable when the Nil FEC is used where the Nil FEC is an
   intermediate FEC in the label stack.  When all labels are represented
   using Nil FEC, it poses some challenges.

   Section 2 discusses the problems associated with using all Nil FECs
   in a MPLS ping/traceroute procedure and Section 3 and Section 4
   discusses simple extensions needed to solve the problem.

2.  Problem with Nil FEC

   The purpose of Nil FEC as described in [RFC8029] is to ensure hiding
   of transit tunnel information and in some cases to avoid false
   negatives when the FEC information is not known.

   The MPLS ping/traceroute packet consists of only single Nil FEC
   corresponding to the complete label stack irrespective of number of
   segments in the label-stack.  When router in the label-stack path
   receives MPLS ping/traceroute packets, there is no definite way to
   decide on whether its egress or transit since Nil FEC does not carry
   any information.  So there is high possibility that the packet may be
   mis-forwarded to incorrect destination but the ping/traceroute might
   still show success.

   To avoid this problem, there is a need to add additional information
   in the MPLS ping/traceroute packet along with Nil FEC that will help
   to do needed validation on each router of the label-stack path and
   sends proper information to ingress router on success and failure.

   Thus it will be useful to add egress information in ping/traceroute
   packet that will help in validating Nil-FEC on each receiving router
   on label-stack path to ensure the correct destination.

3.  Egress TLV

   The Egress object is a TLV that MAY be included in an MPLS Echo
   Request message.  Its an optional TLV and should appear before FEC-
   stack TLV in the MPLS Echo Request packet.  In case multiple Nil FEC
   is present in Target FEC Stack TLV, Egress TLV should be added
   corresponding to the ultimate egress of the label-stack.  The format
   is as specified below:

Rathi, et al.             Expires April 2, 2021                 [Page 3]
Internet-Draft           Egress TLV for Nil FEC           September 2020

       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type = TBD (EGRESS TLV)  |          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Prefix (4 or 16 octets)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type : TBD

   Length : variable based on IPV4/IPV6 prefix.  Length excludes the
   length of Type and length field.  Length will be 4 octets for IPv4
   and 16 octets for IPv6.

   Prefix : This field carries the valid IPv4 prefix of length 4 octets
   or valid IPv6 Prefix of length 16 octets.  It can be obtained from
   egress of Nil FEC corresponding to last label in the label-stack or
   SR-TE policy endpoint field [I.D-ietf-idr-segment-routing-te-policy].

4.  Procedure

   This section describes aspects of LSP Ping and Traceroute operations
   that require further considerations beyond [RFC8029].

4.1.  Sending Egress TLV in MPLS Echo Request

   As stated earlier, when the sender node builds a Echo Request with
   target FEC Stack TLV, Egress TLV SHOULD appear before Target FEC-
   stack TLV in MPLS Echo Request packet.

   Ping

   When the sender node builds a Echo Request with target FEC Stack TLV
   that contains a single NiL FEC corresponding to the last segment of
   the SR-TE path, sender node MUST add a Egress TLV with prefix
   obtained from SR-TE policy endpoint field
   [I.D-ietf-idr-segment-routing-te-policy] to indicate the egress for
   this Nil FEC in the Echo Request packet.  In case endpoint is not
   specified or is equal to 0, sender MUST use the prefix corresponding
   to last segment of the SR-TE path as prefix for Egress TLV.

   Traceroute

   When the sender node builds a Echo Request with target FEC Stack TLV
   that contains a single NiL FEC corresponding to complete segment-list
   of the SR-TE path, sender node MUST add a Egress TLV with prefix
   obtained from SR-TE policy endpoint field

Rathi, et al.             Expires April 2, 2021                 [Page 4]
Internet-Draft           Egress TLV for Nil FEC           September 2020

   [I.D-ietf-idr-segment-routing-te-policy] to indicate the egress for
   this Nil FEC in the Echo Request packet.  In case of multiple Nil
   FEC, Egress TLV SHOULD be added with prefix that indicate endpoint
   for last Nil-FEC corresponding to respective segment in label-stack.
   In case endpoint is not specified or is equal to 0, sender MUST use
   the prefix corresponding to the last segment endpoint of the SR-TE
   path i.e. ultimate egress as prefix for Egress TLV.

   Consider the SR-TE policy configured with label-stack as 1001, 1002 ,
   1003 and end point as X on ingress router N1 to reach egress router
   N3.  Segment 1003 belongs to N3 that has prefix X configured on it
   locally.

   In Ping Echo Request, with target FEC Stack TLV that contains a
   single NiL FEC corresponding to 1003, should add Egress TLV for
   endpoint X with type as EGRESS-TLV, length depends on if X is IPv4 or
   IPv6 address and prefix as X.

   In Traceroute Echo Request, with target FEC Stack TLV that contains a
   single NiL FEC corresponding to complete label-stack (1001, 1002,
   1003) or multiple Nil-FEC corresponding to each label in label-stack,
   should add single Egress TLV for endpoint X with type as EGRESS-TLV,
   length depends on if X is IPv4 or IPv6 address and prefix as X or
   endpoint of segment 1003.  In case X is not present or is set to 0,
   sender should use endpoint of segment 1003 as prefix for Egress TLV.

4.2.  Receiving Egress TLV in MPLS Echo Request

   No change in the processing for Nil FEC as defined in [RFC8029] in
   Target FEC stack TLV Node that receives an MPLS echo request.

   Additional processing done for Egress TLV on receiver node as
   follows:

   1.  Get the prefix from the Egress TLV

   2.  Look up for an exact match of the prefix to any of locally
   configured interface as well loopback address.

   3.  Set Best-return-code to 3 ("Replying router is an egress for the
   FEC at stack-depth") if found or to 8 ("Label switched at stack-
   depth") and Best-rtn-subcode to Label-stack-depth to report transit
   switching in MPLS Echo Reply message.

   4.  If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at
   FEC-stack-depth is Nil FEC and look up for EGRESS TLV prefix fails,
   set the Best-return-code to 10, "Mapping for this FEC is not the
   given label at stack-depth".

Rathi, et al.             Expires April 2, 2021                 [Page 5]
Internet-Draft           Egress TLV for Nil FEC           September 2020

   5.  If the Label-stack-depth is greater than 0 and the Target FEC
   Stack sub-TLV at FEC-stack-depth is Nil FEC and look up for EGRESS
   TLV prefix succeeds, set the Best-return-code to 10, "Mapping for
   this FEC is not the given label at stack-depth".

5.  Backward Compatibility

   The extension proposed in this document is backward compatible with
   procedures described in [RFC8029].

6.  Security Considerations

   TBD

7.  IANA Considerations

7.1.  New TLV

   IANA need to assign new value for EGRESS TLV in the "Multi-Protocol
   Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
   TLV registry [IANA].

   EGRESS TLV : (TBD)

8.  Acknowledgements

   TBD.

9.  References

9.1.  Normative References

   [I.D-ietf-idr-segment-routing-te-policy]
              Filsfils, C., Ed., Previdi, S., Ed., Talaulikar , K.,
              Mattes, P., Rosen, E., Jain, D., and S. Lin, "Advertising
              Segment Routing Policies in BGP",  draft-ietf-idr-segment-
              routing-te-policy-09,  work in progress, may 2020,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
              segment-routing-te-policy-09>.

   [I.D-ietf-spring-segment-routing-policy]
              Filsfils, C., Talaulikar , K., Bogdanov, A., Mattes, P.,
              and D. Voyer, "Segment Routing Policy Architecture",
              draft-ietf-spring-segment-routing-policy-08,  work in
              progress, July 2020,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              segment-routing-policy-08>.

Rathi, et al.             Expires April 2, 2021                 [Page 6]
Internet-Draft           Egress TLV for Nil FEC           September 2020

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
              Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
              Switched (MPLS) Data-Plane Failures", RFC 8029,
              DOI 10.17487/RFC8029, March 2017,
              <https://www.rfc-editor.org/info/rfc8029>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8287]  Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
              N., Kini, S., and M. Chen, "Label Switched Path (LSP)
              Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
              IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
              Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
              <https://www.rfc-editor.org/info/rfc8287>.

9.2.  Informative References

   [IANA]     IANA, "Multiprotocol Label Switching (MPLS) Label Switched
              Paths (LSPs) Ping Parameters",
              <http://www.iana.org/assignments/mpls-lsp-ping-
              parameters>.

Authors' Addresses

   Deepti N. Rathi
   Juniper Networks Inc.
   Exora Business Park
   Bangalore, KA  560103
   India

   Email: deeptir@juniper.net

   Kapil Arora
   Juniper Networks Inc.
   Exora Business Park
   Bangalore, KA  560103
   India

   Email: kapilaro@juniper.net

Rathi, et al.             Expires April 2, 2021                 [Page 7]
Internet-Draft           Egress TLV for Nil FEC           September 2020

   Shraddha Hegde
   Juniper Networks Inc.
   Exora Business Park
   Bangalore, KA  560103
   India

   Email: shraddha@juniper.net

Rathi, et al.             Expires April 2, 2021                 [Page 8]