[spring] Re: [Re]Some comments on draft-ietf-spring-srv6-path-segment

Adrian Farrel <adrian@olddog.co.uk> Tue, 03 September 2024 10:47 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 3C693C180B47; Tue, 3 Sep 2024 03:47:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR4ys6HMJpWK; Tue, 3 Sep 2024 03:47:32 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1C2C151552; Tue, 3 Sep 2024 03:47:23 -0700 (PDT)
Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 483AlAiq015072; Tue, 3 Sep 2024 11:47:10 +0100
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 08AB34604A; Tue, 3 Sep 2024 11:47:10 +0100 (BST)
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E5D8146043; Tue, 3 Sep 2024 11:47:09 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs4.iomartmail.com (Postfix) with ESMTPS; Tue, 3 Sep 2024 11:47:09 +0100 (BST)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 483Al9f3011208 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Sep 2024 11:47:09 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Cheng Li' <c.l@huawei.com>, spring@ietf.org
References: <88a84837ed414c4d8040efd077b98bc4@huawei.com>
In-Reply-To: <88a84837ed414c4d8040efd077b98bc4@huawei.com>
Date: Tue, 03 Sep 2024 11:47:09 +0100
Organization: Old Dog Consulting
Message-ID: <05ba01dafdee$a09c1bc0$e1d45340$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_05BB_01DAFDF7.02647B60"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJs7uzr01eKkgjHhuGl1ivz7YKKH7Eh/UmQ
Content-Language: en-gb
X-Originating-IP: 82.69.109.75
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=ANV+F26hGreDuUnNjU+9u ttvwbxWebf6VISXlQZY5mo=; b=T/gHV/ydLjFsvdvV1MIL3/ArY8VIT7nMa8iZw nv2ZkujcfjpyDXN0gbq8Zcd2jB+g3rihHVMIeYRkxX7UqfDhOZfOqWnCHfOLuUy/ 8z3tfAgr1OlWh3M+eXs+EjbyL1tBgXg8nWz7cXBMgJ8BhKXHv93ygQksb6I+oaAL nHKVQNxtl9l+eg5J2l2w9ApAdHYov9kU4mD6qjhS+o3uWqgtXAD2KPVR22hsO46N +novDRSWlSY3YJEoAvV9qB0Ga2JK1xD+F9gXhJuzRltL+0udNAxQQbVJ9VGEpByy xbkXRsOcRgu8MWYEt03JL7oI0ypjXK3mlzAOgHlKTEPOoO/hg==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28352.003
X-TM-AS-Result: No--25.755-10.0-31-10
X-imss-scan-details: No--25.755-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003
X-TMASE-Result: 10--25.755400-10.000000
X-TMASE-MatchedRID: vJMTL+QvMTfuYusHgJkgymjJpufOqOIAtwi3bXRtaAjOxZdIoBn2VKRX naYAhcWlan6Qq5dmwpwkTzJZAOv6JJVRzPxemJL0TSz0JdEAJbS3L2aPW6sT0rLjeg9NVTVHBm3 3ka/xTVetXC5A/GvXaCg8iUFKzrB2+s0+QZYAcN9KXsyDwNHgj8s3mdBBdiYSdhhLQh0EWTtQ7A xygpyOlZX8ggSYyf2R1OA1SJ4kORFIcJTn2HkqscnlJe2gk8vIggrVGi5LBfDjG7lc3cmGGj/t+ va8hHXmefTHqxypj9MAtOj9AryGOd+pUF0HsjxRv8jdqvFOu+KbOhzJnf8pOF16jRKYEsyLVu8Q Uxp8c0RpqmyqWWTNQxGz3MxdrbPUxvp0tuDMx3nMMm8zT7DdnArkj7klVufuqpc0qSXG1rcqduy 6rUQhOFqiwVJPzWtLESSoXSzffEj2TS1YFaI5/0+crEA4+nhZPhVMN+gapYSETMjf6aTOJ+88Fc s91t4cLsolx7AOEJ6a/+UIUzPJguL9GXA85E8rAKAGvZKDftBUjspoiX02F10cUmVUESQrvPkgE fSNhgDDN7MwcTV80yONKPnKmSjfi95/KnWCU3TArKx94POT2TnZfxjBVQRbW8REdt1lp49Zms6w /rdLbrMTUjboGcLoxEEtnnH5KRcgFhzkd+/gEzPRJAFM8pbhatCpvVFEyno1mi+eHHOFpxyQILe il6PyUugvNl02vW9XodxPGLVTcvQxpA7auLwMLL6mJOIs/vbN/524wIksTJ6iAL9xjLpIu9IbnA qDg7rM1G+DI07bPyJjKXkRvL9+qLiIn4tHBVx9LQinZ4QefK9dKZJ2VxiayeMtMD9QOgCcvwj3d dqeiRqoLbG0ul5BuaN8gZEMR2YRNAkdu81AZV1FkXVL+ky7tT4piLWpY7p+3BndfXUhXQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Message-ID-Hash: LML4ETI3UQ4MCESH45GTS3LZXBJM7BQO
X-Message-ID-Hash: LML4ETI3UQ4MCESH45GTS3LZXBJM7BQO
X-MailFrom: adrian@olddog.co.uk
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spring.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-spring-srv6-path-segment@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Reply-To: adrian@olddog.co.uk
Subject: [spring] Re: [Re]Some comments on draft-ietf-spring-srv6-path-segment
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/yxDXHSrkAlEOS3cuCnCZyiU-3Mo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Owner: <mailto:spring-owner@ietf.org>
List-Post: <mailto:spring@ietf.org>
List-Subscribe: <mailto:spring-join@ietf.org>
List-Unsubscribe: <mailto:spring-leave@ietf.org>

Thanks Cheng.

 

It has been a while, but as you say, we talked about this back around -04.

 

I just ran through your resolution of my comments and everything looks good.

 

Cheers,

Adrian

 

From: Cheng Li <c.l@huawei.com> 
Sent: 02 September 2024 20:56
To: spring@ietf.org; adrian@olddog.co.uk
Cc: draft-ietf-spring-srv6-path-segment@ietf.org
Subject: [Re][spring] Some comments on draft-ietf-spring-srv6-path-segment

 

This is a thread to discuss the comments from Adrian. Thanks to Adrian!

 

I made a mistake that only discuss with co-authors and Adrian( who kindly
reviewed the draft and provided his valuable comments), and then submitted
the draft revision 04 directly.

I copied the content of Adrian's original email below, since the email was
too long ago and cannot be found locally.

 

Hi Adrian, please review the revision 04 or the latest revision to see if
your comments are addressed. If you have further comments(since this is a
fly-by review), you are welcome to share for sure!

I also attach the latest revision(10, to be uploaded), please review.

 

Thanks,

Cheng

 

 

 

====================================================

Hi,
 
This is a bit of a "fly-by" review. I happened to need to read the draft
to check on the use of SRH flags, so here are a few quick comments.
I hope they are useful.
 
Best,
Adrian
 
==Medium==
 
General
 
Some of my points below are cleared up when I finally got to Section 7
and discovered that you are asking for a new Endpoint Behavior to be 
assigned. I think that means it *is* possible to detect that a PSID is
present at the wrong place in the stack *if* the processing node knows
enough to look at the endpoint behaviour and understand it. However, the
only (clear) mention of the new endpoint behaviour is in Section 7: TBA1
should be mentioned in the text somewhere!
[Cheng]You are correct. I added a simple sentence in section 3.1.1 as below.
 
__OLD__
SRv6 Path Segment can follow the format, where the LOC part identifies the
egress node that allocates the Path Segment, and the FUNCT part is a unique
local ID to identify an SRv6 Path and its endpoint behavior, which is
END.PSID (End Function with Path Segment Identifier). 
 
__NEW__
SRv6 Path Segment can follow the format, where the LOC part identifies the
egress node that allocates the Path Segment, and the FUNCT part is a unique
local ID to identify an SRv6 Path and its endpoint behavior, which is
END.PSID (End Function with Path Segment Identifier). The code point of
END.PSID is 100.  
 
The code point has been registered cause the value is FCFS,  please see
https://www.iana.org/assignments/segment-routing/segment-routing.xhtml
 
 
4.1
 
Here you are attempting to state which bit is used as the P-flag.
But there is a registry for the SRH Header flags (at 
 
<https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segm
e>
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segme
nt-routing-header-flags)
so you should leave this as bit number TBD, and specifically ask IANA 
to assign *a* bit.
 
You do actually do this in Section 7 but it is in conflict with 4.1.
 
Note that the registry is IETF review which does allow early assignment
if you want to get the flag agreed for early implementation and interop
etc.
 
[Cheng]Ok, Bruno also suggested to remove the bit from the figure, so I will
do it in the next revision. Please see the diff.
 
My another mistake is that I mistakenly deleted one more paragraph in IANA
in revision 05, which is about the P-flag, oh my god, how it could happen.
https://author-tools.ietf.org/iddiff?url1=draft-ietf-spring-srv6-path-segmen
t-04
<https://author-tools.ietf.org/iddiff?url1=draft-ietf-spring-srv6-path-segme
nt-04&url2=draft-ietf-spring-srv6-path-segment-05&difftype=--html>
&url2=draft-ietf-spring-srv6-path-segment-05&difftype=--html
 
I have added back the text.
 
 
 
==Minor==
 
Section 1
 
   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 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 can not
   determine from which ingress node or SR path the packet came from.
   Therefore, to identify an SR-MPLS path, a Path Segment is defined in
   [I-D.ietf-spring-mpls-path-segment].
 
   Likewise, a path needs to be identified in an SRv6 network for
   several use cases such as binding bidirectional paths
   [I-D.ietf-pce-sr-bidir-path] and end-to-end performance measurement
   [I-D.gandhi-spring-udp-pm].
 
This all reads like the main use case in SR-MPLS is source
identification, and that bidirectional path binding and PM are special
for SRv6. I suggest reversing the order of the paragraphs so...
 
   In SR, a path needs to be identified for several use cases such as
   binding bidirectional paths [I-D.ietf-pce-sr-bidir-path] and end-to-
   end performance measurement [I-D.gandhi-spring-udp-pm].
 
   Additionally, 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 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 can not determine from which ingress node or SR path the
   packet came from.  To identify an SR-MPLS path, a Path Segment is
   defined in [I-D.ietf-spring-mpls-path-segment].
 
[Cheng]updated accordingly.
 
---
[]
1.
 
   An SRv6 Path Segment MUST NOT be copied to the IPv6 destination
   address, so it is not routable.
 
I think this is back-to-front...
 
   An SRv6 Path Segment is not routable (it is just an abstract 128 bit
   identifier) so it MUST NOT be copied to the IPv6 destination address.
 
---
 
Usually, we don't use BCP 14 language (you have MAY and MUST NOT) in the 
Introduction. It is supposed to be introducing the concepts not 
defining behaviour.
 
There are ways around this:
- use lower case (and sometimes reword)
- reduce the Introduction and move the normative language to later
[Cheng]Thank you, updated already, please check
---
 
4.1
 
   o  P-bit: set when SRv6 Path Segment is inserted.  It MUST be ignored
      when a node does not support SRv6 Path Segment processing.
 
Well, some nodes not supporting SRv6 Path Segment processing don't
understand the P flag and have never read this document. So you can't
tell them in this document what to do!
 
You have to refer them back to 8754 with something like
 
   o  P-bit: set when SRv6 Path Segment is inserted.  A node that does
      not understand the P-bit will ignore it as described in [RFC8754].
      A node that understands the P-flag but does not support SRv6 Path
      Segment processing MUST ignore the P-bit.
 
However, what is missing, I think is what happens at an egress node
when the P-flag is set and the egress either doesn't understand or
doesn't support SRv6 Path Segments. In this case, the P-flag will be
ignored, but what will happen to the PSID? Will processing be attempted?
You might argue that "A Path Segment is a local segment allocated by an
egress node, so this situation cannot happen." But I would say that is
"should not happen" because there are ingress errors, and there are 
timing windows. So you need to describe this edge case.
[Cheng]Ack, please see the update
---
 
5.
 
   When a Path Segment is allocated by the egress, it MUST be
   distributed to the ingress node of the path that identified by the
   path segment.  In this case, only the egress will process the Path
   Segment, and other nodes specified by SIDs in the segment list do not
   know how to process the Path Segment.
 
   Depending on the use case, a Path Segment may be distributed to the
   SRv6 nodes along the SRv6 path.  In this case, the SRv6 nodes that
   learned the Path Segment may process the Path Segment depending on
   the use case.
 
This is pretty unclear about how the distribution happens. I think you
either need to describe or reference the mechanisms, or you have to be
clear that the distribution mechanisms are for future study (although,
in that case, it is debatable whether there is any value to this
document!)
[Cheng]Please see the update, we leave this to other drafts.
 
---
 
6.
 
      An SRv6 Path
      Segment that appears at any other location in the SID list will be
      treated as an error.
 
Will it, though? Or will an attempt be made to treat it as some other
form of SID causing unpredictable behaviour? That is, regardless of the
P-flag, if a PSID is inserted into the middle of a SID stack, an
attempt will be made to process it (possibly resulting in an error, or
possibly resulting in the packet being forwarded on an address that
should not be treated as routable). But is there any way to know that
the PSID is at the wrong location (or present multiple times)?
 
So, I think you are fine to say "MUST be bottom of stack" and "MUST NOT
appear at other locations." But all that you can say beyond that is  
that "placing a PSID at any location in the SID list will result in
unpredictable forwarding behavior." 
[Cheng]Ack please see the update
---
 
 
==Nits==
 
Section 1
 
OLD
from which ingress node or SR path the packet came from.
NEW
from which ingress node or SR path the packet came.
END
[Cheng]OK
---
 
1.
 
s/called "SRv6 Path Segment"/called the "SRv6 Path Segment"/
 
---
[Cheng]OK
1.2
 
You don't need to include terms that appear at in the RFC Editor's list
at  <https://www.rfc-editor.org/materials/abbrev.expansion.txt>
https://www.rfc-editor.org/materials/abbrev.expansion.txt marked with
an asterisk (*).
 
In this case, that's "MPLS"
[Cheng]Deleted
---
 
3.1
 
   This document proposes two types of SRv6 Path Segment format.
 
Be future-proof! "This document defines..."
[Cheng]OK
---
 
3.1.1
 
Here you appear to say that the SRv6 Path Identifier can be routable
(i.e., is built with as LOC:FUNCT), but in the Introduction you are 
adamant that it is not routable.
[Cheng]We do not prevent the operator to allocate a routable value to it,
but we do not use it in routing.
---
 
4.1
 
Nothing wrong with Figure 1 (except the alignment of the bit counters)
but it seems overkill to draw what the text says. 
[Cheng]Already updated. Please see the latest revison.
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-path-segment-09
 
---
 
Please decide "P-flag" or "P-bit". Probably flag.
[Cheng]OK, P-flag
---
 

*
<https://mailarchive.ietf.org/arch/msg/spring/AsRF1-XMAbT3yu3GUbvnnU2dyBk/>
[spring] Some comments on draft-ietf-spring-srv6-.  Adrian Farrel

 

 

 

 

 

https://mailarchive.ietf.org/arch/msg/spring/AsRF1-XMAbT3yu3GUbvnnU2dyBk/