RE: 6MAN WGLC: draft-ietf-6man-sids

Adrian Farrel <adrian@olddog.co.uk> Mon, 26 September 2022 11:28 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135A8C14CE3C; Mon, 26 Sep 2022 04:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 fd3_c8WduJaI; Mon, 26 Sep 2022 04:28:14 -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 E1777C14CE31; Mon, 26 Sep 2022 04:28:09 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.7/8.14.7) with ESMTP id 28QBS7oc026866; Mon, 26 Sep 2022 12:28:07 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C87604604B; Mon, 26 Sep 2022 12:28:06 +0100 (BST)
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B15BC4603D; Mon, 26 Sep 2022 12:28:06 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS; Mon, 26 Sep 2022 12:28:06 +0100 (BST)
Received: from LAPTOPK7AS653V (152.197.bbplus.pte-ag1.dyn.plus.net [81.174.197.152] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 28QBS58N014166 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Sep 2022 12:28:05 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Suresh Krishnan' <suresh.krishnan@gmail.com>
Cc: 'Jen Linkova' <furry13@gmail.com>, '6man' <ipv6@ietf.org>, spring@ietf.org, '6man Chairs' <6man-chairs@ietf.org>, draft-ietf-6man-sids.authors@ietf.org, spring-chairs@ietf.org
References: <CAFU7BARixwPZTrNQOuEw3WP-FqUsVwTj7btMTahcMbXm_NqWGw@mail.gmail.com> <129a313a-d625-dae7-36f6-8541a8aea862@gmail.com> <06eb01d8d038$f0ee3a80$d2caaf80$@olddog.co.uk> <0CF331CA-B40D-49D5-BD01-5CE7C0D42040@gmail.com>
In-Reply-To: <0CF331CA-B40D-49D5-BD01-5CE7C0D42040@gmail.com>
Subject: RE: 6MAN WGLC: draft-ietf-6man-sids
Date: Mon, 26 Sep 2022 12:28:06 +0100
Organization: Old Dog Consulting
Message-ID: <07e501d8d19b$0cb9aa20$262cfe60$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_07E6_01D8D1A3.6E7FBFD0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH9o5ycUyLwhW8Mrgk8iGrHz7QMNQLrhQ+DAkoC2dYBt7266a1wbf5Q
Content-Language: en-gb
X-Originating-IP: 81.174.197.152
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-27164.007
X-TM-AS-Result: No--26.627-10.0-31-10
X-imss-scan-details: No--26.627-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27164.007
X-TMASE-Result: 10--26.626700-10.000000
X-TMASE-MatchedRID: XafQxseY2Bpgrjeh0lt2oAphJ/svEmvGocSvEPKGO+dYfsHHDgAMI7ek d2LX0DpIVDi//Lxc8Svvs5KKG3fKgejZlYzLbgNf3IFFT9wqfr3jLrHqvAiSyzQo2w4n/TiM0QC cC7KiRXZbWgo6SW4dHMcfIU90NOSMKpA7TMhSnKf3dt27LH8hnHZljA0GozoiQmw1cPfvj6kAuw GUpXiTDaO1938NDRmYdbCd4izoES2x1DscCmGip2ArOQGGb1wvIqmf+IJXHPx2R0lHU+3PiVVxc /d4wt8XFD8pjUFFtTeHD2rhvA9QQCIDWvu38Vy6Nxqr5qtGGJRhXC3lnHCTmaFIbih0s/42OXB2 cqV0mCKs4vX/mn+LVlejsQ4eUlc/PetSk5bB6tzX3j/lf1V8LO9Bi8r8zoNMCuSPuSVW5+7JwU/ 2h2ml3Sq66izaRlLo5ZKPjhkB0aIJjCNolxOpSYvefyp1glN0NGC/UiT7n1+Z8Jb+wsOjUDPzb5 MrfULrqS0FK4gjDb7eo3Sz4FBJ9In+yx+lmb2rsFSKfGPIprXB0/7xhd4ByRLrYh6WSYrHpJExm Z473us4HFt+vqKGDNcTa8zT3zBS8l/7T554Jwo4hD0Y/Y/a7yqz6w5v8PFz5NxnjW0aGja1kMso eqnA5Gs+Dz00KoL2CixZGA5wQEkjcfdLUtN6//aOj+OqQ2RbdOaFE388N0U6lCVU94KW08vDQqE dbf1N84H0QJCUuBviaM3d4jHJ5ear/iMJBetyDOs94g784gfcAmu1xqeetjrMvELBEqW14a8tjc E0lxxVt74cDplnfvLc9o1qFIUS1k9eOCPOer+eAiCmPx4NwGmRqNBHmBveGtkvK5L7RXERNAkdu 81AZeYW23/lu+cllExlQIQeRG0=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1ImiGA-2OGJS2oEoIZEBFhyhVSY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2022 11:28:19 -0000

Thanks for the speedy turn-around, Suresh.

 

Lots of snipping to just a few open points….


3.

"It is also fairly clear"
Well, that is illuminating :-)
Perhaps you want to make statements about the SID elements and not about
the clarity of the referenced documents?

 

Sure :-). Suggest 

 

OLD:

   It is also fairly clear that the non-SRv6-SID elements that appear in

   the SRH SID list are simply IPv6 addresses assigned to local

   interfaces annd MUST conform to [RFC4291].

 

NEW:

   As stated above, the non-SRv6-SID elements that appear in

   the SRH SID list are simply IPv6 addresses assigned to local

   interfaces and they need to conform to [RFC4291].


[AF] OK


3.

  Section 3.1. of [RFC8986] describes the format of an SRv6 SID as
  composed of three parts 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). 

Would it be helpful to qualify L+F+A = 128 in all cases?

 

Actually not. RFC8986 defines L+F+A <=128 instead and this would be inconsistent with that. 


[AF] OK, this is important!

You have…

   [RFC8754] defines the Segment List of the SRH as a contiguous array

   of 128-bit IPv6 addresses

…and…

   Section 3.1. of [RFC8986] describes the format of an SRv6 SID as

   composed of three parts LOC:FUNCT:ARG

 

8986 helps me by saying that “When L+F+A is less than 128, then the remaining bits of the SID MUST be zero.”

 

But I think it behoves this document to be unambiguous. “Composed of three parts” does not imply to me “composed of three parts and another part that must be set to zero.” So, perhaps you need a bit more detail and some gentle wordsmithing. For example,

 

   Section 3.1. of [RFC8986] describes the format of an SRv6 SID as

   containing three parts 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). If L+F+A < 128,

   the ARG is followed by enough zero bits to fill the 128 bit SID.


3.

  When an SRv6 SID occurs in the IPv6 destination address field of an
  IPv6 header, only the longest match prefix corresponding to the
  locator is used to forward the packet to the node identified by the
  Locator.

Possibly you mean s/is used/should be used/
Or maybe s/used/used by an SRv6-capable node/

 

This is written as a statement about what happens today rather than specifying behavior for the node to follow.

 

[AF] Well, I like your confidence about all the implementations that are out there 😊

I think there are two points:

1.	You are describing SRv6-capable nodes, I think.
2.	You might more accurately provide the normative reference to where this behavior is defined, and then say “As defined in [ref], when an SRv6 SID…” 

 

BTW you have “locator” and “Locator”



3.

  Hence the relevant standard to apply here is [RFC7608]
  that allows the use of variable length prefixes in forwarding

I think 7608 is not a standard. Maybe say specification?
But also, I don't think that 7608, as a BCP, "allows" anything.

 

Suggest changing this to

 

Hence the relevant specification to apply here is [RFC7608]
that requires implementations to support the use of variable 

length prefixes in forwarding.

 

Does that work?

 

[AF] Much better



4.

  A node
  taking part in this mechanism accomplishes this by using the ARG part
  [RFC8986] of the Destination address field of the IPv6 header to come
  up with a new Destination address in some of these flavors.

"to come up with" and "flavors" are a bit colloquial. Maybe say 
"derive" and "mechanisms".

 

Ack on the “derive” part, but “flavor” is a specific term used in [I-D.ietf-spring-srv6-srh-compression]

 

[AF] Hrmph! draft-ietf-spring-srv6-srh-compression is a work in progress, is not a normative reference here, and is not part of this last call. I see it uses “flavor” extensively, but it is a poor choice of word.

 

I tell you what: if the meaning of the word is clear, you can tell me what it means in this context. And if you can tell me what it means, you can use that description in your draft.


4.1.

  There are a few issues that need to be addressed in the C-SID draft
  prior to its publication as RFC:

Erm, no! You can't have an RFC that chats about the current state of
another draft, or that claims it is going to be published as an RFC.

Perhaps the best solution is to compress sections 4, 4.1, and 4.2 into
a very short note that "Many approaches to SID list compression have
been proposed. It is important that any solution preserves the
properties of the LOC as described in Section 3."

 

This text was added as requested by one of the spring chairs to specify that the spring document needs to address these issues. It would be great if the 6man/spring chairs and ADs can chime in on this topic.

 

[AF] While we wait for them to speak up, let’s just note that if the intention of this text is to set requirements, you should that in terms of “any specification addressing this problem space needs to provide answers to the following questions.”

 

5.

  All of the SRv6 related specifications discussed above are intended
  to be applicable to a contained SR Domain or between collaborating SR
  Domains.  Hence the behavior of SRv6 SIDs is visible purely within
  the SR domain and they would be treated solely as IPv6 routing
  prefixes by nodes that are not SR aware.

What is meant by a behavior being visible?

 

Any special behavior associated with SRv6 SIDs are not known or acted upon by non-SR-aware nodes and these nodes use them for forwarding based on the prefix as described in RFC7608.

 

[AF] OK. Perhaps we can rephrase as…


All of the SRv6 related specifications discussed above are applicable

to a contained SR Domain or between collaborating SR Domains. 

Nodes either inside or outside the SR Domains that are not SR-aware 

will not perform any special behavior for an SRv6 SIDs and will treat

them solely as IPv6 routing prefixes. 



I know that the permeability of SR domain boundaries is something that
really worries at least one of the current ADs, and it might be good to
spend some time discussing what happens when things go wrong and a 
packet with a SID in the DA field escapes from the domain (this is
distinct from the behavior of a non-SR node within the domain).

Yes. I certainly do understand that concern and one of the tools in reducing the permeability is moving this traffic to a well known filterable prefix at the borders of the domains depending on the stance of the domain. 

 

[AF] This helps so long as we include a remark on what will happen when a packet carrying a DA that uses one of these special prefixes is encountered by a node outside the domain. You possibly need to explain how a non-SR node inside the domain differs from a non-SR node outside the domain.


5.

  As an added factor of safety, it might be prudent to allocate some
 address space that explicitly signals that the addresses within that
  space are not intended to comply with [RFC4291].  As described in

"are not intended to comply" means "do not comply"?

No. It simply means that compliance to RFC4291 cannot be expected. Are you looking for stronger text for requiring non-compliance?

 

[AF] Then just say “cannot be expected to comply with [RFC4291]”

The text “are not intended to comply with” can be confused with “are intended to not comply with”


  Section 3 above, there is precedent for mechanisms that use IPv6
  addresses in a manner different from that specified in [RFC4291].
  This would be useful in identifying and potentially filtering packets
  at the edges of the SR Domains as described in Section 4.1.

  The SRv6 operational community, which is the first intended user of
  this block, is requested to come up with conventions and guidelines
  for the use of this newly allocated address block in line with their
  requirements.

This sounds like you are:
- not proposing any specific use
- allocating the address space on the off-chance that someone might 
 find a use for it
- not suggesting that deployments (or implementations) actually change
 their current behavior

How are you arriving at this conclusion. 

 

[AF] I arrive at this conclusion by reading your text! It is “unusual” but not forbidden for an Informational RFC to assign a code point with no use described, but in this case it seems reasonable. What is odd is the paragraph quoted. But…

 

Spring is working on draft-ietf-spring-srv6-srh-compression-02. What address space do you think it can be deployed in? Here are some of the potential options

 

a) RIR allocations

b) ULA space

c) Something else* (this allocation)

 

I think all of these options have pros and cons and what you think of this prefix allocation might depend on what properties you desire. 

 

[AF] So, perhaps you could replace the paragraph as…

 

  Future specifications are needed to describe the conventions and

 guidelines for the use of this newly allocated address block.


6. 

Obviously, there are many ranges in the registry marked as "Reserved
by IETF" and IANA will need help selecting one. 

Also, since this registry is "IESG Approval" it would be timely to
approach the IESG and determine whether they are likely to say "yes" or
will need further changes to the document. Those changes should happen
while the document is still in the working group.

 

Hmm. Isn’t that what the IESG review process is for? Or are you suggesting an early allocation request prior to advancing the draft so that the IESG can decide if a temporary allocation is worthwhile? If it is neither, can you elaborate on your proposed procedure.


[AF] Quite. That is the purpose. However, I’m am just suggesting that you engage your AD now rather than complete WG last call etc. before discovering that the IESG is unlikely to support the proposal. This can be completely informal. I’m not suggesting that you do early allocation or anything like that.


I'm surprised that section 7 doesn't point back to the "additional 
safety" described in section 5. In particular, not using that safety
would appear to be a risk.

I can certainly duplicate some of the text from section 5 if the WG would find it useful.

 

[AF] Feel free to duplicate text, but I was suggesting highlighting the risk (which is not significantly stressed in section 5), and then pointing back at section 5 as the resolution.

 

Cheers,

Adrian