--- 1/draft-ietf-mpls-sr-over-ip-05.txt 2019-05-23 10:13:56.547334800 -0700 +++ 2/draft-ietf-mpls-sr-over-ip-06.txt 2019-05-23 10:13:56.595336013 -0700 @@ -1,27 +1,27 @@ Network Working Group X. Xu Internet-Draft Alibaba, Inc Intended status: Standards Track S. Bryant -Expires: November 11, 2019 Huawei +Expires: November 24, 2019 Huawei A. Farrel Old Dog Consulting S. Hassan Cisco W. Henderickx Nokia Z. Li Huawei - May 10, 2019 + May 23, 2019 SR-MPLS over IP - draft-ietf-mpls-sr-over-ip-05 + draft-ietf-mpls-sr-over-ip-06 Abstract MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source routing paradigm in which the sender of a packet is allowed to partially or completely specify the route the packet takes through the network by imposing stacked MPLS labels on the packet. SR-MPLS can be leveraged to realize a source routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source routing instruction set while making no changes to SR-MPLS @@ -39,21 +39,21 @@ 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 November 11, 2019. + This Internet-Draft will expire on November 24, 2019. Copyright Notice Copyright (c) 2019 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 @@ -120,24 +120,24 @@ capitals, as shown here. 2. Use Cases Tunneling SR-MPLS using IPv4 and/or IPv6 tunnels is useful at least in the use cases listed below. In all cases, this can be enabled using an IP tunneling mechanism such as MPLS-in-UDP as described in [RFC7510]. The tunnel selected MUST have its remote end point (destination) address equal to the address of the next SR-MPLS capable node identified as being on the SR path (i.e., the egress of - the active node segment). The local end point (source) address is - set to an address of the encapsulating node. [RFC7510] gives further - advice on how to set the source address if the UDP zero-checksum mode - is used with MPLS-in-UDP. + the active segment). The local end point (source) address is set to + an address of the encapsulating node. [RFC7510] gives further advice + on how to set the source address if the UDP zero-checksum mode is + used with MPLS-in-UDP. o Incremental deployment of the SR-MPLS technology may be facilitated by tunneling SR-MPLS packets across parts of a network that are not SR-MPLS as shown in Figure 1. This demonstrates how islands of SR-MPLS may be connected across a legacy network. It may be particularly useful for joining sites (such as data centers). ________________________ _______ ( ) _______ @@ -222,24 +222,24 @@ Global Block (SRGB). The SRGB is defined in [RFC8402]. There are a number of ways that the advertisement can be achieved including IGPs, BGP, configuration/management protocols. For example, see [I-D.ietf-bess-datacenter-gateway]. o When Router E advertises the prefix-SID SID(E) of prefix P(E) it MUST also advertise the encapsulation endpoint and the tunnel type of any tunnel used to reach E. This information is flooded domain wide. - o If A and E are in different IGP domains then the information MUST - be flooded into both domains. How this is achieved depends on the - advertisement mechanism being used. The objective is that router - A knows the characteristics of router E that originated the + o If A and E are in different routing domains then the information + MUST be flooded into both domains. How this is achieved depends + on the advertisement mechanism being used. The objective is that + router A knows the characteristics of router E that originated the advertisement of SID(E). o Router A programs the FIB entry for prefix P(E) corresponding to the SID(E) according to whether a pop or swap action is advertised for the prefix. The resulting action may be: * pop the top label * swap the top label to a value equal to SID(E) plus the lower bound of the SRGB of E @@ -699,43 +699,43 @@ May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . 8.2. Informative References [I-D.ietf-6man-segment-routing-header] - Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and - d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header - (SRH)", draft-ietf-6man-segment-routing-header-18 (work in - progress), April 2019. + Filsfils, C., Dukes, D., Previdi, S., Leddy, J., + Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment + Routing Header (SRH)", draft-ietf-6man-segment-routing- + header-19 (work in progress), May 2019. [I-D.ietf-bess-datacenter-gateway] Farrel, A., Drake, J., Rosen, E., Patel, K., and L. Jalil, "Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection", draft- ietf-bess-datacenter-gateway-02 (work in progress), February 2019. [I-D.ietf-isis-encapsulation-cap] Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, L., and L. Jalil, "Advertising Tunnelling Capability in IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in progress), April 2017. [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", draft-ietf-isis-segment-routing- - extensions-24 (work in progress), April 2019. + extensions-25 (work in progress), May 2019. [I-D.ietf-mpls-spring-entropy-label] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., Shakir, R., and J. Tantsura, "Entropy label for SPRING tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in progress), July 2018. [I-D.ietf-ospf-encapsulation-cap] Xu, X., Decraene, B., Raszuk, R., Contreras, L., and L. Jalil, "The Tunnel Encapsulations OSPF Router