Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Mon, 28 September 2020 07:31 UTC

Return-Path: <xiejingrong@huawei.com>
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 1F8BD3A0407; Mon, 28 Sep 2020 00:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 eJQY4dI9pJe5; Mon, 28 Sep 2020 00:31:26 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 7F8033A084A; Mon, 28 Sep 2020 00:31:26 -0700 (PDT)
Received: from lhreml712-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id AAC5916BA0984EBABB0C; Mon, 28 Sep 2020 08:31:24 +0100 (IST)
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 28 Sep 2020 08:31:23 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 28 Sep 2020 15:31:20 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Mon, 28 Sep 2020 15:31:20 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: "Pablo Camarillo (pcamaril)" <pcamaril=40cisco.com@dmarc.ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: Bruno Decraene <bruno.decraene@orange.com>, "spring@ietf.org" <spring@ietf.org>, Joel Halpern <jmh@joelhalpern.com>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "draft-ietf-spring-srv6-network-programming@ietf.org" <draft-ietf-spring-srv6-network-programming@ietf.org>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)
Thread-Index: AQHWk2o/ZiqtllsCYkCPkau6scKcnql9onQQ
Date: Mon, 28 Sep 2020 07:31:20 +0000
Message-ID: <2ec228d15e974549a19f13a94787b2e4@huawei.com>
References: <160093393224.24080.1727360124332839831@ietfa.amsl.com> <MWHPR11MB1374716970EDB9357D533A06C9360@MWHPR11MB1374.namprd11.prod.outlook.com>
In-Reply-To: <MWHPR11MB1374716970EDB9357D533A06C9360@MWHPR11MB1374.namprd11.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.201.174]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/kJu9pO2fHxHFhftsIPHO9zRjl1k>
Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)
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: Mon, 28 Sep 2020 07:31:30 -0000

Hi,
I have some comments inline below marked with [XJR].
Thanks
Jingrong

-----Original Message-----
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Pablo Camarillo (pcamaril)
Sent: Saturday, September 26, 2020 2:32 AM
To: Benjamin Kaduk <kaduk@mit.edu>du>; The IESG <iesg@ietf.org>
Cc: Bruno Decraene <bruno.decraene@orange.com>om>; spring@ietf.org; Joel Halpern <jmh@joelhalpern.com>om>; spring-chairs@ietf.org; draft-ietf-spring-srv6-network-programming@ietf.org
Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

Hi Benjamin,

Thank you for your time and review. Please see inline with [PC].

Regards,
Pablo.

-----Original Message-----
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
Sent: jueves, 24 de septiembre de 2020 9:52
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-spring-srv6-network-programming@ietf.org; spring-chairs@ietf.org; spring@ietf.org; Bruno Decraene <bruno.decraene@orange.com>om>; Joel Halpern <jmh@joelhalpern.com>om>; jmh@joelhalpern.com
Subject: Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-spring-srv6-network-programming-20: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[edited to remove nonsensical point that had crept in about the SRH being a new extension header; it's "just" a routing header]

The current requirement that IANA-assigned SRv6 Endpoint Behavior codepoints are used, with no range reserved for local assignment, seems to be inviting codepoint squatting from the nominally reserved range.
Why is there an absolute requirement for registration (even FCFS) without ranges for local or experimental use?  (What are the various reserved ranges reserved for?) [PC] I agree with you that a range for local use would come useful. Hence, we’ve carved 2k entries of the registry for Private Use.
The Reserved range (half of the 65k registry) is for future allocation by IETF. Future RFCs might decide how to use that.

The (normative) pseudocode does not seem to handle the case when the SRH is omitted for the degenerate case where there is only a single segment, or for the PSP flavor.
[PC] Each one of the pseudocodes provides the SRH processing and the Upper-Layer processing. If there is no SRH, then the SRH processing is not executed, but the Upper-layer Header processing is. This is the same as in RFC8754.

The pseudocode for the PSP and USP procedures seem incorrect -- Hdr Ext Len is measured in units of 8 octets, and does not include the first 8 octets of the extension header, but Payload Length is measured in octets.  Literally decreasing the Payload Length by the Hdr Ext Len value will produce a malformed IPv6 packet.
[PC] Indeed. Fixed.
[XJR] Seems still not correct in rev-21. " Hdr Ext Len is measured in units of 8 octets, and does not include the first 8 octets of the extension header".

If "PSP operation is deterministically controlled by the SR Source Node", why do we need to define behavior codepoints that (for example) use both PSP and USP?  I don't see how there is full determinism in this case while being different from the "PSP only" flavor.
[PC] In order for the PSP behavior to be executed there must happen two things. First, the SR Source Node must instruct it wants to use the PSP behavior. This is done by using an SRv6 SID associated with a behavior that support the PSP flavor (either End with PSP alone, or End with PSP in combination of other). Then, the second thing is that the received packet at the node it must have a SL value of 1, that during processing is decremented to 0. (In other words, it must be the penultimate segment). If both conditions are given, then lines S14.2-S14.4 of the pseudocode are executed.
[XJR] The method to define a behavior codepoint for every possible combination is very overwhelming. Looking at section 10.2.1 of rev-21, there are 8 codepoints for End/Ent.X/End.T each when there are 3 flavors. How about 4 flavors or 5 flavors then ???

There are numerous factual errors and un/under-specified protocol behavior (see COMMENT), including: how to set the outer Hop Limit (multiple instances), the order of segments in the SRH, specification of headend behavior by reference to informal example, L2 frame en/decapsulation procedures, and the "Opaque" note for endpoint behavior 65535.
[PC] I’ll comment on each point in the comment.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I note that this document references
draft-filsfils-spring-srv6-net-pgm-illustration, which uses the IPv4 CIDR 20/8 in examples instead of addresses from the RFC 5737 range.  It would be disappointing to have a PS refer to a draft that squats on the IPv4 namespace in such a manner.
[PC] Ack. I’ve updated draft-filsfils-spring-srv6-net-pgm-illustration to correct that.

Abstract, Introduction

   This document defines the SRv6 Network Programming concept and
   specifies the base set of SRv6 behaviors that enables the creation of
   interoperable overlays with underlay optimization (Service Level
   Agreements).

I don't understand what the parenthetical is intending to convey.
[PC] I’ve removed the parenthesis. Its unneeded.

Section 2

   The following terms used within this document are defined in
   [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6
   SID, SR Policy, Prefix SID, and Adjacency SID.

[RFC 8402 spells it Prefix-SID (with hyphen) and Adj-SID.] [PC] Fixed in rev21.

Section 3

The text allegedly reproduced from RFC 8754 §4.3 differs in case and hyphenation.
[PC] Fixed in rev21.

Section 3.1

   This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
   where a locator (LOC) is encoded in the L most significant bits of
   the SID, followed by F bits of function (FUNCT) and A bits of
   arguments (ARG).  L, the locator length, is flexible, and an operator
   is free to use the locator length of their choice.  F and A may be
   any value as long as L+F+A <= 128.  When L+F+A is less than 128 then
   the remaining bits of the SID MUST be zero.

Why does A have to be a fixed value; can't it safely be a function of F (even if we exclude things like huffman coding for F)?
[PC] Can you please re-state your point? The text above does not suggest that A is a fixed value, hence I’m not sure I fully understand what you mean.

   An SRv6 Segment Endpoint Behavior may require additional information
   for its processing (e.g. related to the flow or service).  This
   information may be encoded in the ARG bits of the SID.

(Assuming that it can be sufficiently compactly encoded?) [PC] Correct

   The ARG value of a routed SID SHOULD remain constant among packets in
   a given flow.  Varying ARG values among packets in a flow may result

(Thus limiting the type of information that can be represented in the
ARG?)
[PC] This text provides a SHOULD, and a reason for it. If other behaviors defined in future documents would like to have ARG value varying for packets belonging to the same flow, it is important that they take this into consideration.

Section 3.2

   SIDs.  The provider historically deployed IPv6 and assigned
   infrastructure addresses from a portion of the fc00::/7 prefix.  They
   further subdivided the prefix into three /48 prefixes (Country X,
   Country Y, Country Z) to support their SRv6 infrastructure.  From
   those /48 prefixes each router is assigned a /64 prefix from which
   all SIDs of that router are allocated.

This is not the language I would have expected for use of the ULA address range.  It looks like this may be related to Erik Kline's Discuss point...
[PC] Indeed related. Erik Kline has suggested text. Ill use Erik’s text as provided.

   IPv6 address consumption in both these examples is minimal,
   representing one billionth and one millionth of the assigned address
   space, respectively.

I'm not sure I understand the calculation that produced these values.
[PC] If the operator got assigned a /20 by the RIR, then they have 2^28 /48 prefixes available. Thus, if they are only using a few /48 prefixes, then they are using less than a millionth of the available /48 prefixes.

   An SR Source Node cannot infer the behavior by examination of the
   FUNCT value of a SID.

   Therefore, the SRv6 Endpoint Behavior codepoint is advertised along
   with the SID in the control plane.

These two sentences feel a little out of place in this spot, occurring after previous discussion that the endpoint behavior codepoint is advertised in the control plane.
[PC] Other ADs have expressed the value of precisely those two sentences.

   o  At Router 3, within the locator 2001:db8:bbbb:3::/64, network
      operator or the router performs dynamic assignment for:

nit: missing article ("the network operator").
[PC] Ack. Fixed in rev21.

      *  Function 100 associated with the behavior End.X (Endpoint with
         cross-connect) between router 3 and its connected neighbor
         router, for example Router 4.  This function is encoded as
         16-bit value and has no arguments.

Please clarify that "function 100" is a hex literal.
[PC] Ack. Fixed in rev21.

I also suggest noting clearly at the start of the example that F is 16 and A is 0.
[PC] Ack. Added for each SID in rev21.

      *  Function 101 associated with the behavior End.X (Endpoint with
         cross-connect) between router 3 and its connected neighbor
         router, for example Router 2.  This function is encoded as
         16-bit value and has no arguments.

F is a constant for the SR domain; saying it at each SID assignment is misleading.
[PC] Function is the bits in the SID instantiated by the router. Can you please explain what text gives the impression that F is a constant?

[same note about hex for 101]
[PC] Ack. Added for each SID in rev21.

Section 4

   The list is not exhaustive.  In practice, any function can be
   attached to a local SID: e.g. a node N can bind a SID to a local VM
   or container which can apply any complex processing on the packet.

Yes, but it can't advertise the behavior corresponding to that function without a codepoint.
[PC] This is intended to be an introductory paragraph to the behaviors. But you are absolutely right: for any new behavior you need to write a new I-D (as its currently happening in other SPRING WG docs), and then -once RFCed- get an SRv6 Endpoint Behavior codepoint for it.

Section 4.1.1

   When processing the Upper-layer Header of a packet matching a FIB
   entry locally instantiated as an SRv6 End SID, if Upper-layer Header
   processing is allowed by local configuration (e.g.  ICMPv6), then

nit: the parenthetical is placed so as to apply to "local configuration", which doesn't really make sense; I presume the intent is to say that upper-layer header processing is allowed *for that upper-layer protocol*.  Also, comma after "e.g.".
[PC] Agreed, but see next point.

   problem message to the Source Address and discard the packet.  Error
   code 4 (SR Upper-layer Header Error) and Pointer set to the offset of
   the upper-layer header.

nit: this is not a complete sentence.
[PC] We have been asked to change the entire 4.1.1 to a pseudocode. Please review the pseudocode in revision 21 and let me know your feedback.
[XJR] " Stop processing the SRH, proceed to process the next ..." I think there is a "and" needed to link the two sentences. There are 3 places of this nit in rev-21.

Section 4.2

   It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is
   required to express any traffic-engineering policy.

This text reads as if End.X specifically is required for TE, which does not seem correct to me.
[PC] Fixed.
OLD: and it is required to express any traffic-engineering policy.
NEW: and its main use is for traffic-engineering policies.

Section 4.4, 4.5

                                        This is equivalent to the per-CE
   VPN label in MPLS [RFC4364].

The phrase "per-CE VPN" does not appear in RFC 4364.
[PC] Added to the terminology section.

Section 4.5

   S05.  If the End.DX4 SID is bound to an array of L3 adjacencies, then
   one entry of the array is selected based on the hash of the packet's
   header Section 7.

nit: I suggest "(see Section 7)" to match section 4.4.
[PC] Indeed. Fixed.

Section 4.6, 4.7

   is required.  This is equivalent to the per-VRF VPN label in MPLS
   [RFC4364].

The phrase "per-VRF VPN" does not appear in RFC 4364.
(A similar comment applies to Section 4.8 as well.) [PC] Added to the terminology section of the document.

   Note that an End.DT6 may be defined for the main IPv6 table in which
   case and End.DT6 supports the equivalent of an IPv6inIPv6

nit: s/and/an/
[PC] Thanks. Fixed.

Section 4.7

   The "Endpoint with decapsulation and specific IPv4 table lookup"
   behavior (End.DT4 for short) is a variant of the End behavior.

nit: variant of End.T, just like End.DT6, no?
[PC] Correct, fixed.

Section 4.9

   S04.  An End.DX2 behavior could be customized to expect a specific
   IEEE header (e.g.  VLAN tag) and rewrite the egress IEEE header
   before forwarding on the outgoing interface.

Would this customized behavior require a new codepoint?
Similarly for End.DX2V (Section 4.10)
[PC] No, that customization is local config to the node.

Section 4.10

   S04. Remove the outer IPv6 Header with all its extension headers,
           lookup the exposed VLANs in L2 table T, and forward
           via the matched table entry.

Just to check my understanding: the "exposed VLANs" (plural?!) are in the Ethernet header of the packet that we are left with after removing the outer IPv6 header, right?
[PC] Correct. And multiple tags in case of Q-in-Q.

   S01.  IANA has allocated the Internet Protocol number 143 to Ethernet
   (see Section 10.1).

This seems like a copy/paste leftover from End.DX2 -- we don't mention
143 in this section.
[PC] Indeed. I added by mistake on rev20 to address an AD comment and I have just removed in rev21 again.

Section 4.12

   Two of the applications of the End.DT2M behavior are the EVPN
   Bridging of broadcast, unknown and multicast (BUM) traffic with
   Ethernet Segment Identifier (ESI) filtering and the EVPN ETREE use-
   cases.

Are there references for either/both of these?
[PC] Added in rev21.

   S04. Remove the IPv6 header and all its extension headers

nit: the rest of the document uses "Remove the outer IPv6 header with all its extension headers".
[PC] Fixed. Thanks.

   S06. Forward via all L2 OIFs excluding the one specified in Arg.FE2

nit: s/one/ones/
[PC] Fixed. Thanks.

   Arg.FE2 is encoded in the SID as an (k*x)-bit value.  These bits
   represent a list of up to k OIFs, each identified with an x-bit
   value.  Values k and x are defined on a per End.DT2M SID basis.  The
   interface identifier 0 indicates an empty entry in the interface
   list.

(editorial) rather than have to come up with the concept of an "empty entry" in the interface list, I would probably just say that the identifier 0 is reserved and is ignored when doing the exclusion of OIFs.

I also think we need to say that the order and identifier assignment of elements of the interface list (that is, what the x-bit values index
into) is under the local control of N, but has to remain stable as long as SIDs are advertised that list members of the list in ARG.  (There is otherwise a great deal of freedom in assignment since the values are only consumed by the node that advertises them.) [PC] This text is updated as part of Alvaro’s comment. Can you please check the current text in rev21?

Section 4.13

It's probably worth calling out the MTU considerations of pushing the new IPv6 header+SRH and tunneling the packets.  (I know we reference
2473 already, but the MTU is pretty important.) [PC] MTU considerations are covered in RFC8754.

   S17.  The Payload Length, Traffic Class and Next-Header fields are
   set as per [RFC2473].  The Flow Label is computed as per [RFC6437].

How is the Hop Limit set for the outer header?
(I assume §6.3 of RFC 2473, but given that you provide a reference for all the other fields, it seems like an omission to not mention Hop Limit as well.) [PC] Sure, added.

Section 4.14

   The SRH MAY be omitted when the SRv6 Policy only contains one segment
   and there is no need to use any flag, tag or TLV.

If this is the case does it matter if I use End.B6.Encaps or End.B6.Encaps.Red?
[PC] If you only have a single segment, then it does not matter. However when you have more than one segment the change is significant.

Section 4.16

I don't think I understand what it would mean for a specific SID to support the multiple flavors "in combinations".
[PC] Convoluted sentence indeed.
<OLD>
For each of these
   behaviors these flavors MAY be supported for a SID either
   individually or in combinations.
</OLD>
<NEW>
The End, End.X or End.T behaviors could support these flavors either individually or in combination.
</NEW>

Section 4.16.1.2

   A penultimate SR Segment Endpoint Node is one that, as part of the
   SID processing, copies the last SID from the SRH into the IPv6
   Destination Address and decrements Segments Left value from one to
   zero.

I think technically it copies the first SID from the SRH (SRH.Segment List[0]), which is the last SID from the SR Policy.
[PC] RFC8754 uses the term “last SID” to refer to SRH.SegmentList[0]. Please refer RFC8754 Sec 6.1 for details.
Also, nit: "the" for "the Segments Left value".
[PC] Ack. Corrected.

 S14.2.      Update the Next Header field in the preceding header to the
                Next Header value of the SRH

nit: personally, I would write "from the SRH", since "next header value of the SRH" is very close to "next header value of SRH", i.e., 43.
[PC] Reads better indeed. Corrected.

   As a reminder, [RFC8754] defines in section 5 the SR Deployment Model
   within the SR Domain [RFC8402].  Within this framework, the
   Authentication Header (AH) is not used to secure the SRH as described
   in Section 7.5 of [RFC8754].

I strongly recommend adding another sentence clarifying why this is relevant to discussion of removing an extension header from the packet.
[PC] I suggest that is not relevant to the discussion of PSP since AH is not defined for the SRH.

Section 5

   This list can be expanded in case any new functionality requires it.

How?  By an RFC that Updates: this one?
[PC] New functionality would have to be introduced via a new document but it does not have to update this one since it is not modifying what is in this document but adding something new. 
We have updated the text as s/This list can be expanded in case any new functionality requires it/This list is not exhaustive and future documents may define additional behaviors.

Section 5.x

I agree with the directorate reviewer that the protocol behavior should be written out explicitly, without reference to the handling of example packet(s).
[PC] There is already pseudocode and descriptions in these sections that describes the behavior. Examples are to help understanding. Can you clarify what more is required?

Section 5.1

   S03.   Set outer payload length, traffic class and flow label

What about the outer Hop Limit?
[PC] Added.

   S03: As described in [RFC6437] (IPv6 Flow Label Specification)

Why is this all the way at the bottom of the section instead of included with the corresponding content?
[PC] Ack. Brought up.

Section 5.3

   The encapsulating node MUST remove the preamble or frame check
   sequence (FCS) from the Ethernet frame upon encapsulation and the
   decapsulating node MUST regenerate the preamble or FCS before
   forwarding Ethernet frame.

"or"?  I get to choose one or the other?  It's okay to only put back a preamble but no FCS (or vice versa)?
[PC] Good catch. s/or/and; also preamble removed only if present

Section 6

   traffic that matched that SID and was processed correctly.  The
   retrieval of these counters via MIB, NETCONF/YANG or any other means
   is outside the scope of this document.

(editorial) a MIB is an abstract data structure (likewise a YANG module); information might be retrieved *from* it but not *via* it.  For *via*, that would be SNMP, NETCONF, and/or RESTCONF.
[PC] Fixed.

Section 8.1

Does it make sense to reference RFCs 8491, 8476, 8841, etc. for advertising MSD via IGP?
[PC] I would leave that up to the srv6 control plane drafts; but no strong preference.

   In particular, the SR source (e.g., H.Encaps), intermediate endpoint
   (e.g., End, End.X) and final endpoint (e.g., End.DX4, End.DT6)
   behaviors.  [...]

This is not a complete sentence, and I really have no idea what verb was intended.
[PC] Indeed, fixed in rev21.

Section 8.2, 8.3

Can we get references for the BGP variants here and their usage for signaling SRv6 capabilities and (SID,behavior codepoint) pairs?
[PC] The references to the BGP features have already been provided in the respective sections where these behaviors are specified. There are WG drafts in progress for SRv6 extensions to routing protocols (not just BGP) that normatively reference this document. There used to be informative references the other way around from this document which were removed during WGLC based on feedback. We can add them back if that makes sense for the IESG.

Section 9

I would really like to have a stronger reference to Section 5 of RFC
8754 where the conceptual model of a SR Domain as a single system, where all packets in the domain are encapsulated using IPv6 headers [with SIDs as SA/DA].  The part in brackets is not spelled out very clearly and could well be expounded upon in this document.  I can write up some (very ad hoc) ideas for what I had in mind, which you are welcome to adopt but expected to wordsmith/edit appropriately:

% Section 5 of [RFC8754] describes the SR deployment model and the % baseline requirements for securing the SR Domain.  In many ways the SR % Domain is analogous to an MPLS domain -- it's a tightly controlled % system where packet processing is controlled by a list (or stack) of % opaque identifiers that, by and large, only have defined semantics in % the context of the node that receives and processes the packet when % that identifier is "topmost" or "current".  Experience in securing and % operating MPLS domains should be readily transferrable to SRv6 % domains, in ensuring that all traffic within the network is tightly % controlled, with all external inputs being properly encapsulated (for % SRv6, by an IPv6 header usually with SRH; for MPLS, by the label % stack).  The dedicated format for the MPLS label stack and label % identifiers makes a clear mechanical separation between "internal" and % "external" identifiers. In contrast, SRv6 uses SIDs for the internal % identifiers, which have format and operation of IPv6 addresses.  While % this lets SRv6 benefit from IP longest-prefix routing and thus the % structure of SID values, it also means that there is not a crisp % mechanical separation between "internal" and "external" identifiers.
% As such, care and rigor in annotating which IPv6 addresses/headers are % internal vs external is required in order to maintain the integrity % and security of the SRv6 domain.

[PC] Thanks for your suggestions. Indeed we should update the draft with something along those lines.
The comparison or equivalence to MPLS is likely going to be confusing and hence we avoid going down that path. We were thinking on something like the following.
Please let me know of what you think. (I have not pushed this into the draft yet).
[XJR] "help differentiate internal vs external address space that is required to maintain the integrity and security of the SRv6 Domain", I don't understand how it is relevant to the integrity.
Maybe it is "required to make access control (or ingress filtering) of the SRv6 Domain" ? You need to wordsmith it.

<Proposal>
  The security considerations for Segment Routing are discussed in [RFC8402]. Section 5 of [RFC8754] describes the SR Deployment Model and the requirements for securing the SR Domain. The security considerations of [RFC8754] also cover aspects such as attack vectors and their mitigation mechanisms that also apply to the behaviors introduced in this document. Together, they describe the required security mechanisms that allow establishment of an SR domain of trust to operate SRv6-based services for internal traffic while preventing any   external traffic from accessing or exploiting the SRv6-based services.  Care and rigor in IPv6 address allocation for use for SRv6 SID allocations and network infrastructure addresses to be separate from IPv6 addresses allocated for end-users/systems (as illustrated in Section 5.1 of [RFC8754]) help differentiate internal vs external address space that is required to maintain the integrity and security of the SRv6 Domain. Additionally, [RFC8754] defines an HMAC TLV permitting SR Endpoint Nodes in the SR domain to verify that the SRH applied to a packet was selected by an authorized party and to ensure that the segment list is not modified after generation, regardless of the number of segments in the segment list.  When enabled by local configuration, HMAC processing occurs at the beginning of SRH processing as defined in [RFC8754] Section 2.1.2.1.
This document introduces SRv6 Endpoint and SR Policy Headend   behaviors for implementation on SRv6 capable nodes in the network.   As such, this document does not introduce any new security   considerations.
</Proposal>

There might also be room for discussion (in the main body of the
document) of how the various decapsulation procedures occur precisely when the packet is leaving the SR Domain.
[PC] The sections 4.4 through 4.12 do describe these procedures for the decapsulation behaviors specified in this document.

Having the ARG structure specified as part of the behavior codepoint registration means that a node that can apply that SID can also spoof the ARG to force a different (e.g.) outgoing interface list.
Specifically, it gives the attacker a degree of freedom greater than just the SID behaviors that the node advertises.  The HMAC TLV would mitigate this to the extent that it limits what SIDs the node in question is allowed to apply and what changes can be made on-path.
[PC] The processing of ARG is specific to a behavior defined and not generic. Please refer to the updated text in Sec 4.12 for End.DT2M (which is currently the only specified behavior that accepts ARGs). Since the ARG bits are part of the SID there are no other considerations for them apart from the ones that apply to the SID as a whole.

   services.  Additionally, [RFC8754] defines an HMAC TLV permitting SR
   Endpoint Nodes in the SR domain to verify that the SRH applied to a
   packet was selected by an authorized party and to ensure that the
   segment list is not modified after generation, regardless of the
   number of segments in the segment list.  When enabled by local

I suggest adding a sentence similar to "(This does, however, require that the segment list, and thus, the SRH is present in the packet; the optional ability to elide the SRH when there is only a single segment and no flags, tags, or TLVs needed inherently excludes the protection of the HMAC TLV.)"
[PC] All the SR Policy Headend (i.e. the SR Source Node) behaviors defined in Sec 5 state:
>  The push of the SRH MAY be omitted when the SRv6 Policy only contains   one segment and there is no need to use any flag, tag or TLV.
So, it follows that if HMAC protection is required, then SRH has to be used even with a single segment.

Section 10.1

   definition: The value 143 in the Next Header field of an IPv6 header
   or any extension header indicates that the payload is an Ethernet
   [IEEE.802.3_2018].

nit: is there a missing word here ("frame"?)?
[PC] Ack, fixed.

Many thanks for your time.



_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring