< draft-ninan-spring-mpls-inter-as-oam-00.txt   draft-ninan-spring-mpls-inter-as-oam-01.txt >
Routing area S. Hegde Routing area S. Hegde
Internet-Draft K. Arora Internet-Draft K. Arora
Intended status: Standards Track S. Ninan Intended status: Standards Track S. Ninan
Expires: January 5, 2020 Juniper Networks Inc. Expires: January 6, 2020 M. Srivastava
July 4, 2019 Juniper Networks Inc.
July 5, 2019
PMS/Head-end based MPLS Ping and Traceroute in Inter-AS SR Networks PMS/Head-end based MPLS Ping and Traceroute in Inter-AS SR Networks
draft-ninan-spring-mpls-inter-as-oam-00 draft-ninan-spring-mpls-inter-as-oam-01
Abstract Abstract
Segment Routing (SR) architecture leverages source routing and Segment Routing (SR) architecture leverages source routing and
tunneling paradigms and can be directly applied to the use of a tunneling paradigms and can be directly applied to the use of a
Multiprotocol Label Switching (MPLS) data plane. Segment Routing Multiprotocol Label Switching (MPLS) data plane. Segment Routing
also provides an easy and efficient way to provide inter connectivity also provides an easy and efficient way to provide inter connectivity
in a large scale network as described in [RFC8604]. [RFC8287] in a large scale network as described in [RFC8604]. [RFC8287]
illustrates the problem and defines extensions to perform LSP Ping illustrates the problem and defines extensions to perform LSP Ping
and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency
Segment Identifiers (SIDs) with an MPLS data plane. It is useful to Segment Identifiers (SIDs) with an MPLS data plane. It is useful to
have the LSP Ping and traceroute procedures when an SRend-to-end path have the LSP Ping and traceroute procedures when an SR end-to-end
spans across multiple ASes. This document describes mechanisms to path spans across multiple ASes. This document describes mechanisms
facilitae LSP ping and traceroute in inter-AS SR networks in an to facilitae LSP ping and traceroute in inter-AS SR networks in an
efficient manner with simple OAM protocol extension. efficient manner with simple OAM protocol extension which uses
dataplane forwarding alone for sending Echo-Reply.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 47 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2020.
This Internet-Draft will expire on January 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 40
3.3. Sending an Echo-Reply . . . . . . . . . . . . . . . . . . 6 3.3. Sending an Echo-Reply . . . . . . . . . . . . . . . . . . 6
4. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 6 4. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Procedures for Segment Routing LSP ping . . . . . . . . . 7 4.1. Procedures for Segment Routing LSP ping . . . . . . . . . 7
4.2. Procedures for Segment Routing LSP Traceroute . . . . . . 7 4.2. Procedures for Segment Routing LSP Traceroute . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
+----------------+ +----------------+
| Controller/PMS | | Controller/PMS |
+----------------+ +----------------+
|---------AS1----------| |--------AS2----------| |---------AS1----------| |--------AS2----------|
ASBR2-------ASBR3 ASBR2-------ASBR3
/ \ / \
skipping to change at page 3, line 46 skipping to change at page 3, line 46
Routing enabled and the EPE links have EPE labels configured and Routing enabled and the EPE links have EPE labels configured and
advertised via [I-D.ietf-idr-bgpls-segment-routing-epe]. Controller advertised via [I-D.ietf-idr-bgpls-segment-routing-epe]. Controller
or head-end can build end-to-end Traffic-Engineered path Node-SIDs, or head-end can build end-to-end Traffic-Engineered path Node-SIDs,
Adjacency-SIDs and EPE-SIDs. It is advantageous for operations to be Adjacency-SIDs and EPE-SIDs. It is advantageous for operations to be
able to perform LSP ping and traceroute procedures on these inter-AS able to perform LSP ping and traceroute procedures on these inter-AS
SR paths. LSP ping/traceroute procedures use ip connectivity for SR paths. LSP ping/traceroute procedures use ip connectivity for
Echo-reply to reach the head-end. In inter-AS networks, ip Echo-reply to reach the head-end. In inter-AS networks, ip
connectivity may not be there from each router in the path.For connectivity may not be there from each router in the path.For
example in Figure 1 P3 and P4 may not have ip connectivity for PE1. example in Figure 1 P3 and P4 may not have ip connectivity for PE1.
[RFC8403] describes mechanisms to carry out the mpls ping/traceroute [RFC8403] describes mechanisms to carry out the MPLS ping/traceroute
from a PMS. It is possible to build GRE tunnels or static routes to from a PMS. It is possible to build GRE tunnels or static routes to
each router in the network to get IP connectivity for the return each router in the network to get IP connectivity for the return
path. This mechanism is operationally very heavy and requires PMS to path. This mechanism is operationally very heavy and requires PMS to
be capable of building huge number of GRE tunnels, which may not be be capable of building huge number of GRE tunnels, which may not be
feasible. feasible.
It is not possible to carry out LSP ping and Traceroute functionality It is not possible to carry out LSP ping and Traceroute functionality
on these paths to verify basic connectivity and fault isolation using on these paths to verify basic connectivity and fault isolation using
existing LSP ping and Traceroute mechanism([RFC8287] and [RFC8029]). existing LSP ping and Traceroute mechanism([RFC8287] and [RFC8029]).
This is because, there exists no IP connectivity to source address of This is because, there exists no IP connectivity to source address of
skipping to change at page 5, line 22 skipping to change at page 5, line 22
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Reverse Path label stack TLV Figure 2: Reverse Path label stack TLV
Type: TBD Type: TBD
Length: Length of TLV including TLV header Length: Length of TLV including TLV header
No. Of elements in set: No. Of labels:
Ordered set of Labels in the Reverse Path label stack Ordered set of Labels in the Reverse Path label stack
Label : Label :
Represents 20 bit label. This field should be used to build the Represents 20 bit label. This field should be used to build the
return packet. The first label in the label stack represents the top return packet. The first label in the label stack represents the top
most label that should be encoded in the return packet. most label that should be encoded in the return packet.
2.2. SRv6 Dataplane 2.2. SRv6 Dataplane
skipping to change at page 5, line 44 skipping to change at page 5, line 44
A future version of this document will address the SRv6 Dataplane. A future version of this document will address the SRv6 Dataplane.
3. Detailed Procedures 3. Detailed Procedures
3.1. Sending an Echo-Request 3.1. Sending an Echo-Request
LSP ping initiator MUST add a Return Path Label Stack TLV in the LSP ping initiator MUST add a Return Path Label Stack TLV in the
Echo-request message. The return label stack MUST correspond to the Echo-request message. The return label stack MUST correspond to the
return path from the egress. The Reverse Path Label Stack TLV is an return path from the egress. The Reverse Path Label Stack TLV is an
ordered list of labels. The first label corresponds to the top label ordered list of labels. The first label corresponds to the top label
that the reponder should use to construct the Echo-reply. that the responder should use to construct the Echo-reply.
3.2. Receiving an Echo-Request 3.2. Receiving an Echo-Request
When a receiver does not understand the Reverse Path Label Stack TLV, When a receiver does not understand the Reverse Path Label Stack TLV,
it SHOULD silently ignore the TLV and proceed with normal processing it SHOULD silently ignore the TLV and proceed with normal processing
as described in [RFC8029].When a Reverse Path Label Stack TLV is as described in [RFC8029].When a Reverse Path Label Stack TLV is
received, and the responder supports processing it, it MUST use the received, and the responder supports processing it, it MUST use the
labels in Reverse Path Label Stack TLV to build the echo-reply. The labels in Reverse Path Label Stack TLV to build the echo-reply. The
responder MUST follow the normal FEC validation procedures as responder MUST follow the normal FEC validation procedures as
described in [RFC8029] and [RFC8287] and this document does not described in [RFC8029] and [RFC8287] and this document does not
suggest any change to those procedures. When the Echo-reply has to suggest any change to those procedures. When the Echo-reply has to
be sent out the Reverse Path label Stack TLV is used to construct the be sent out the Reverse Path label Stack TLV is used to construct the
MPLs packet to send out. MPLS packet to send out.
3.3. Sending an Echo-Reply 3.3. Sending an Echo-Reply
The Echo-Reply message is sent as mpls packet with a mpls label The Echo-Reply message is sent as MPLS packet with a MPLS label
stack. The Echo-Reply message MUST be constructed as described in stack. The Echo-Reply message MUST be constructed as described in
the [RFC8029]. An MPLS packet is constructed with Echo-reply in the the [RFC8029]. An MPLS packet is constructed with Echo-reply in the
payload. The top label MUST be the first label from the Reverse Path payload. The top label MUST be the first label from the Reverse Path
Label Stack TLV. The remaining labels MUST follow the order from the Label Stack TLV. The remaining labels MUST follow the order from the
Reverse Path Label Stack. The responder MAY check the reachability Reverse Path Label Stack. The responder MAY check the reachability
of the top label in its own LFIB before sending the Echo-Reply. of the top label in its own LFIB before sending the Echo-Reply.
4. Detailed Example 4. Detailed Example
An example topology is given in Figure 1 . This will be used in below An example topology is given in Figure 1 . This will be used in below
sections to explain LSP Ping and Traceroute procedures. The PMS/ sections to explain LSP Ping and Traceroute procedures. The PMS/
Head-end has complete view of topology. PE1, P1, P2, ASBR1 and ASBR2 Head-end has complete view of topology. PE1, P1, P2, ASBR1 and ASBR2
are in AS1. Similarly ASBR3, ASBR4, P3, P4 and PE4 are in AS2. are in AS1. Similarly ASBR3, ASBR4, P3, P4 and PE4 are in AS2.
AS1 and AS2 are Segment Routing enabled. IGPs like OSPF/ISIS are AS1 and AS2 have Segment Routing enabled. IGPs like OSPF/ISIS are
used to flood SIDs in each Autonomous System. The ASBR1, ASBR2, used to flood SIDs in each Autonomous System. The ASBR1, ASBR2,
ASBR3, ASBR4 advertise BGP EPE SIDs for the inter-AS links. Topology ASBR3, ASBR4 advertise BGP EPE SIDs for the inter-AS links. Topology
of AS1 and AS2 are advertised via BGP-LS to the controller/PMS or of AS1 and AS2 are advertised via BGP-LS to the controller/PMS or
Head-end node. The EPE-SIDs are also advertised via BGP-LS as Head-end node. The EPE-SIDs are also advertised via BGP-LS as
described in [I-D.ietf-idr-bgpls-segment-routing-epe] described in [I-D.ietf-idr-bgpls-segment-routing-epe]
The description in the document uses below notations for Segment The description in the document uses below notations for Segment
Identifiers(SIDs). Identifiers(SIDs).
Node SIDs : N-PE1, N-P1, N-ASBR1 etc. Node SIDs : N-PE1, N-P1, N-ASBR1 etc.
skipping to change at page 7, line 28 skipping to change at page 7, line 28
multiple labels in "Reverse Path Label Stack TLV" as defined above. multiple labels in "Reverse Path Label Stack TLV" as defined above.
An example return path label stack for PE1 to PE4 for LSP ping i An example return path label stack for PE1 to PE4 for LSP ping i
[N-ASBR4, EPE-ASBR4-ASBR1, N-PE1]. An implementation may also build [N-ASBR4, EPE-ASBR4-ASBR1, N-PE1]. An implementation may also build
a Reverse Path Label stack consisting of labels to reach its own AS. a Reverse Path Label stack consisting of labels to reach its own AS.
Once the label stack is popped-off the Echo-reply message will be Once the label stack is popped-off the Echo-reply message will be
exposed.The further packet forwarding will be based on ip lookup. An exposed.The further packet forwarding will be based on ip lookup. An
example Reverse Path Label Stack for this case could be [N-ASBR4, example Reverse Path Label Stack for this case could be [N-ASBR4,
EPE-ASBR4-ASBR1]. EPE-ASBR4-ASBR1].
On receiving MPLS Echo-request PE4 first validates FEC in the Echo- On receiving MPLS Echo-request PE4 first validates FEC in the Echo-
request and calculates label stack to send the response from PE4 to request. PE4 then builds label stack to send the response from PE4
PE1 using "Return label stack TLV". PE4 builds the Echo-reply packet to PE1 by copying the labels from "Return Path Label Stack TLV". PE4
with the mpls label stack constructed out of Reverse Path Label Stack builds the Echo-reply packet with the MPLS label stack constructed
TLV and sends out the Echo-reply to PE1. This label stack can and imposes MPLS headers on top of Echo-reply packet and sends out
successfully steer reply back to Head-end node(PE1). the packet towards PE1. This label stack can successfully steer
reply back to Head-end node(PE1).
4.2. Procedures for Segment Routing LSP Traceroute 4.2. Procedures for Segment Routing LSP Traceroute
As described in the procedures for LSP ping, the return label stack As described in the procedures for LSP ping, the return label stack
may be sent from head-end in which case the LSP Traceroute procedures may be sent from head-end in which case the LSP Traceroute procedures
are similar to mpls-ping. The head-end constructs the Reverse Path are similar to LSP ping. The head-end constructs the Reverse Path
Label Stack TLV and the egress node uses the Reverse Path Label Stack Label Stack TLV and the egress node uses the Reverse Path Label Stack
to construct the Echo-reply packet header. Head-end/PMS is aware of to construct the Echo-reply packet header. Head-end/PMS is aware of
the return path from every node visited in the network and builds the the return path from every node visited in the network and builds the
Reverse Path Label Stack for every visited node accordingly. Reverse Path Label Stack for every visited node accordingly.
For Example: For Example:
For the same traffic engineered path PE1 to PE4 mentioned in above For the same traffic engineered path PE1 to PE4 mentioned in above
sections, let us assume there is no return path available from the sections, let us assume there is no return path available from the
nodes ASBR2 to PE1. During the Traceroute procedure, when PE1 has to nodes ASBR2 to PE1. During the Traceroute procedure, when PE1 has to
visit ASBR2, it builds Return Path Label Stack TLV and includes label visit ASBR2, it builds Return Path Label Stack TLV and includes label
to the border-node which has the route to, PE1. In this example the to the border-node which has the route to, PE1. In this example the
Return Path Label Stack TLV will contain [EPE-ASBR2-ASBR1]. Further Return Path Label Stack TLV will contain [EPE-ASBR2-ASBR1]. Further
down the traceroute procedure when P3 or P4 node is being visited, down the traceroute procedure when P3 or P4 node is being visited,
PE1 build the Return Path Label Stack TLV containing [N-ASBR2, EPE- PE1 build the Return Path Label Stack TLV containing [N-ASBR2, EPE-
ASBR2-ASBR1]. The Echo-reply will be an mpls packet with this label ASBR2-ASBR1]. The Echo-reply will be an MPLS packet with this label
stack and will be forwarded to PE1. stack and will be forwarded to PE1.
5. Security Considerations 5. Security Considerations
TBD TBD
6. IANA Considerations 6. IANA Considerations
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
Parameters TLVs Registry Parameters TLVs Registry
skipping to change at page 10, line 4 skipping to change at page 10, line 14
Authors' Addresses Authors' Addresses
Shraddha Hegde Shraddha Hegde
Juniper Networks Inc. Juniper Networks Inc.
Exora Business Park Exora Business Park
Bangalore, KA 560103 Bangalore, KA 560103
India India
Email: shraddha@juniper.net Email: shraddha@juniper.net
Kapil Arora Kapil Arora
Juniper Networks Inc. Juniper Networks Inc.
Email: kapilaro@juniper.net Email: kapilaro@juniper.net
Samson Ninan Samson Ninan
Juniper Networks Inc. Juniper Networks Inc.
Email: samsonn@juniper.net Email: samsonn@juniper.net
Mukul Srivastava
Juniper Networks Inc.
Email: msri@juniper.net
 End of changes. 16 change blocks. 
23 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/