[spring] Review of draft-ietf-spring-mpls-path-segment-00
"Adrian Farrel" <adrian@olddog.co.uk> Wed, 28 August 2019 10:19 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672231200C5; Wed, 28 Aug 2019 03:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsBPvqPF7x9p; Wed, 28 Aug 2019 03:19:01 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5421200BA; Wed, 28 Aug 2019 03:18:57 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x7SAIthV028384; Wed, 28 Aug 2019 11:18:55 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DC58022040; Wed, 28 Aug 2019 11:18:54 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id C5A002203C; Wed, 28 Aug 2019 11:18:54 +0100 (BST)
Received: from LAPTOPK7AS653V ([87.112.232.99]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x7SAIqae015281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Aug 2019 11:18:54 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'SPRING WG' <spring@ietf.org>
Cc: draft-ietf-spring-mpls-path-segment@ietf.org
Date: Wed, 28 Aug 2019 11:18:50 +0100
Organization: Old Dog Consulting
Message-ID: <010101d55d89$fddbc980$f9935c80$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdVdiduFOBuz6Q59TbWe7ccz7fQbiw==
Content-Language: en-gb
X-Originating-IP: 87.112.232.99
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24874.005
X-TM-AS-Result: No--14.858-10.0-31-10
X-imss-scan-details: No--14.858-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24874.005
X-TMASE-Result: 10--14.858300-10.000000
X-TMASE-MatchedRID: p69JlGAt1/4/9d9Rtcc0Q1yuZHgmvm5oS/ceBQrgS1GmPVDJNbpM8Jy8 UG+qg0r7mrVYIjGuUUi25WIsdFfJGLz5DD0+tkb148SQ1JLtjzbnaaW2UTafyAQsw9A3PIlLjQb 0ZijHcXBdrzeynHN7tvYEY66YFlO6W3GTrVa/FS7P/uumIUCPf2rNcACR7H8iLzUzuO6zeIlZly GUwPkzt0ogw6zAMqQ/n+IANb3q1gCedPXiHMWBMm1rAlJKwOBJQZpQRfyCdHz5w23Kuluq0fHi3 7rLYicCKkLVi99UdhZQJFvlrBLJrf3flyGWfT3UWS2u1ZE9NECJDcnxSM8mRb+Z3Zp2Td1E6N0P kLbxFjOciBwad5HvMjjTJTyaO4THdLzqQcWLMXATS0S9JNzCsTXAqTvm8SubuSIn8GC9fqtl1XI ooYqOSf40thXagGmRO8DNQUc5XjYNjSVetjn4ciQ7ls378/zHomfP1J8KYpaqvcIF1TcLYJwP9f GM7KHkp1zNn0TW6gSqBtKZYXGLot8WL/kWgsttBcaL/tyWL2PPz/TMqSwFh5l8NETW6pKC1ZkNk Wn2wr5dn27CIn0HMdxsPzlwa12NTsjB/rxmtwe5R/Gy/ffHb5KLNrbpy/A0ZfeU/vWAuFWLijUQ +JYGF6yUYt6Lv5tPl/ZqERfMFveGFWqjeDE74Tnb8O0YN0Q5pHTu027282PXIZTIUrehXnGaI3o bawWADNDPNrK+A/OkV528GEKq7DC8Z6yBHvVBaK+MsTwM+1kYgyDj5TiRtccySOqW2ey32vWVrg 304q2f/6smF5+QYGzlLAWyLHZTTX7PJ/OU3vL+xOhjarOnHis3zPQeiEbe+gtHj7OwNO2FR9Hau 8GO7pgpLtAJDWrv5J5AEFLSWevPJuju8zD+KbrcHUqQshBNsfmiRTsfFIY=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/XkJB91QmCi_fXy4QxRVHZj6Ib24>
Subject: [spring] Review of draft-ietf-spring-mpls-path-segment-00
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Aug 2019 10:19:03 -0000
Hi SPRING and document authors, Now we've adopted this draft, I thought I should give it a more careful reading. Here are some thoughts and nits. Best, Adrian === General thoughts === I think that the Abstract and Introduction need to make it clear (as the title does, and does Section 2) that this document only applies to SR-MPLS. I have suggested edits in line. --- Do we need to cover PHP? --- In the case of a centralised controller, there is a risk that a Path Segment will be applied for an egress that does not expect it. It will know what to do with the last segment identifier in the path list (i.e., pop it) and will then find the path segment label. The risk is that that label is somehow in the LFIB (if it is not, then it is unrecognised and the packet is simply dropped). Presumably, the important thing is for the centralised controller to not make this mistake, and there is nothing the egress can do to protect itself. The big risk is when a central controller is allocating Path Segment identifiers and the egress node is allocating labels from the same space. It is important to write something about this. Probably you can reduce the risk by splitting the label space. Maybe this all belongs in Section 4. === Edits === Abstract OLD A Segment Routing (SR) path is identified by an SR segment list, one or partial segments of the list cannot uniquely identify the SR path. Path identification is a pre-requisite for various use-cases such as performance measurement (PM) of an SR path. NEW A Segment Routing (SR) path is identified by an SR segment list. Only the full segment list identifies the full end-to-end path, and one segment or a partial set of segments from the list cannot identify the SR path and distinguish it from other SR paths that may be partially congruent. But path identification is a pre-requisite for various use-cases such as performance measurement (PM) of an SR path. In SR for MPLS (SR-MPLS) the segment identifiers are stripped from the packet through label popping as the packet transits the network. This means that when a packet reaches the egress of the SR path, it is not possible to determine on which SR path it traversed the network. END OLD This document defines a new type of segment that is referred to as Path Segment, which is used to identify an SR path. When used, it is inserted at the ingress node of the SR path and immediately follows the last segment of the SR path. The Path Segment will not be popped off until it reaches the egress node of the SR path. NEW This document defines a new type of segment that is referred to as Path Segment, which is used to identify an SR path in an SR-MPLS network. When used, it is inserted at the ingress node of the SR path and immediately follows the last segment identifier in the segment list of the SR path. The Path Segment will not be popped off until it reaches the egress node of the SR path. END OLD Path Segment can be used by the egress node to implement path identification hence to support various use-cases including SR path PM, end-to-end 1+1 SR path protection and bidirectional SR paths correlation. NEW A Path Segment can be used by the egress node to implement path identification hence to support various use-cases including SR path PM, end-to-end 1+1 SR path protection, and bidirectional SR paths correlation. END --- 1. Introduction OLD Segment Routing (SR) [RFC8402] is a source routed forwarding method that allows to directly encode forwarding instructions (called segments) in each packet, hence it enables to steer traffic through a network without the per-flow states maintained on the transit nodes. Segment Routing can be instantiated on MPLS data plane or IPv6 data plane. The former is called SR-MPLS, the latter is called SRv6 [RFC8402]. SR-MPLS leverages the MPLS label stack to construct SR path, and SRv6 uses the a new IPv6 Extension Header (EH) called the IPv6 Segment Routing Header (SRH) [I-D.ietf-6man-segment-routing-header] to construct SR path. NEW Segment Routing (SR) [RFC8402] is a source routed forwarding method that allows to directly encode forwarding instructions (called segments) in each packet, hence it enables steering traffic through a network without the per-flow states maintained on the transit nodes. Segment Routing can be instantiated on an MPLS data plane or an IPv6 data plane. The former is called SR-MPLS [I-D.ietf-spring-segment-routing-mpls], the latter is called SRv6 [RFC8402]. SR-MPLS leverages the MPLS label stack to construct SR paths. END OLD In an SR-MPLS network, when a packet is transmitted along an SR path, the labels in the MPLS label stack will be swapped or popped. So that no label or only the last label may be left in the MPLS label stack when the packet reaches the egress node. Thus, the egress node cannot determine from which SR path the packet comes. NEW In an SR-MPLS network, when a packet is transmitted along an SR path, the labels in the MPLS label stack will be swapped or popped. So that no label or only the last label may be left in the MPLS label stack when the packet reaches the egress node. Thus, the egress node cannot determine along which SR path the packet came. END However, to support use cases like end-to-end 1+1 path protection (Live-Live case), bidirectional path correlation or performance measurement (PM), the ability to implement path identification is a pre-requisite. >>> Would be good to give a reason for this pre-requisite. OLD Therefore, this document introduces a new segment that is referred to as Path Segment. A Path Segment is defined to uniquely identify an SR path in the context of the egress node. It is normally used by egress nodes for path identification or correlation. NEW Therefore, this document introduces a new segment that is referred to as the Path Segment. A Path Segment is defined to uniquely identify an SR path in an SR-MPLS network in the context of the egress node. It is normally used by egress nodes for path identification or correlation. END --- 1.1. 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 BCP14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. >>> Need a space between the references (to stop idnits complaining) --- 2. Path Segment A Path Segment is a single label that is assigned from the Segment Routing Local Block (SRLB) or Segment Routing Global Block (SRGB) of the egress node of an SR path. It means that the Path Segment is unique in the context of the egress node of the SR path. When Path >>> s/When/When a/ Segment is used, the Path Segment MUST be inserted at the ingress node and MUST immediately follow the last label of the SR path. The Path Segment may be used to identify an SR-MPLS Policy, its Candidate-Path (CP) or a SID List (SL) >>> s/(CP)/(CP),/ [I-D.ietf-spring-segment-routing-policy] terminating on an egress node depending on the use-case. OLD The value of the TTL field of the Path Segment MUST be set to the same value of the last segment label of the SR path. If the Path Segment is the bottom label, the S bit MUST be set. NEW The value of the TTL field in the MPLS label stack entry containing the Path Segment MUST be set to the same value as the TTL of the last label stack entry for the last segment in the SR path. If the Path Segment is the bottom label, the S bit MUST be set. END +--------------------+ | ... | +--------------------+ | Label 1 | +--------------------+ | Label 2 | +--------------------+ | ... | +--------------------+ | Label n | +--------------------+ | Path Segment | +--------------------+ | ... | +--------------------+ >>> Shouldn't the last entry be +--------------------+ ~ Payload ~ +--------------------+ Figure 1: Label Stack with Path Segment --- 6. Path Segment for Bi-directional SR Path With the current SR architecture, an SR path is a unidirectional path. In some scenarios, for example, mobile backhaul transport network, there are requirements to support bidirectional path, and >>> s/path/paths/ the path is normally treated as a single entity and both directions of the path have the same fate, for example, failure in one direction will result in switching at both directions. MPLS supports this by introducing the concepts of co-routed bidirectional LSP and associated bidirectional LSP. With SR, to support bidirectional path, a straightforward way is to bind two >>> s/path/paths/ unidirectional SR paths to a single bidirectional path. Path segments can be used to correlate the two unidirectional SR paths at >>> s/segments/Segments/ both ends of the paths. --- 7. Path Segment for End-to-end Path Protection For end-to-end 1+1 path protection (i.e., Live-Live case), the egress node of an SR path needs to know the set of paths that constitute the primary and the secondary(s), in order to select the primary packet s/y(s)/ies/ for onward transmission, and to discard the packets from the secondary(s). s/y(s)/ies/ OLD It is obvious that this group can be instantiated in the network by an SDN controller. NEW It is obvious that this group can be instantiated in the network by an SDN controller and that the Path Segment achieves the desired function. END ---
- [spring] Review of draft-ietf-spring-mpls-path-se… Adrian Farrel
- [spring] 答复: Review of draft-ietf-spring-mpls-pat… Weiqiang Cheng