Hi Francois and best wishes for the New Year.
Tl;dr This is good work. Thank you for the effort.
Individual responses in line.
Adrian
Thank you for this follow-up.
Indeed, we were still working on some of your comments when revision -09
was pushed. Those remaining comments should now be addressed in revision
-10
(https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/10/).
Please see our reply to each comment below.
Thanks,
Francois (on behalf of the C-SID co-authors)
0. Please get into the habit of running idnits before posting a new
revision.
== Missing Reference: 'RFC8200' is mentioned on line 996, but not
defined
RFC 8200 is only mentioned in a quoted text from RFC 8754. We fixed
the quote format in revision -09, so that idnits should no longer complain
about this.
Hmmm. Idnits continues to object.
I don’t have a strong opinion, but inserting an Informative Reference would
clean it up.
We added a reference to RFC 8200 in revision -10 for another purpose, so that
nit
should be gone for good this time.
Perfect
13. Section 2 has:
| A compressed Segment List encoding may also contain
| any number of uncompressed SID sequences.
Yeah, and zero is any number. But I think you say this more
gracefully.
This zero case was not intended to be covered by "any number" but
by the use of the modal "may": "A compressed Segment List encoding
**may** also contain \[...\]." That said, please let us know if you have
any suggestion to improve this phrasing.
Well, not sure. If you meant to exclude zero, then perhaps
| A compressed Segment List encoding contains one or more
| uncompressed SID sequences.
If you meant to allow zero, then
| A compressed Segment List encoding contains zero, one, or more
| uncompressed SID sequences.
We rephrased this in revision -10 per your suggestion.
| * Compressed segment list encoding: A segment list encoding that
| reduces the packet header length thanks to one or more C-SID
| sequences. A compressed segment list encoding also contains zero,
| one, or more uncompressed SID sequences.
Nice
16. Section 3
| When a sequence of consecutive SIDs in a Segment List shares a common
| Locator-Block, a compressed Segment-List encoding can optimize the
| packet header length by avoiding the repetition of the Locator-Block
| and trailing bits with each individual SID.
I think you are saying two separate things in this paragraph, but the
text is not very clear:
- a compressed Segment-List encoding can be used
- the act of compressing the Segment-List might reduce the packet
header length
We rephrased this sentence in revision -09.
| The compressed segment list encoding decreases the packet header
| length by avoiding the repetition of the same Locator-Block and
| reducing the use of padding bits.
This is much better.
I think you are asserting that the compressed list always reduces the
packet header length, but (of course) there is an edge condition where
it makes no difference (compress one SID into a C-SID).
You're right. We adjusted the wording in revision -10 to state the intend
rather the result.
| The compressed segment list encoding seeks to decrease the packet
| header length by avoiding the repetition of the same Locator-Block
| and reducing the use of padding bits.
Good
26. Section 4.1
| An SR segment endpoint node instantiating a SID with the NEXT-C-SID
| flavor MUST accept any argument value for that SID.
It is clear that the endpoint knows the flavor of the SIDs it has
initiated, but it is not clear how the flavor of the SID is known
by anyone else in order that they can compress it or use an
argument value.
The SID flavor is advertised in the control plane as part of the "behavior"
identifier (see RFC 9252, RFC 9352, https://www.iana.org/assignments/
segment-routing/segment-routing.xhtml#srv6-endpoint-behaviors).
If you believe this is clear then, that’s fine. Otherwise, just add a few words.
We added some text at the beginning of section 6 in revision -10 to clarify
this aspect.
| An SR source node may learn from a control plane protocol (see
| Section 8) or local configuration the SIDs that it can use in a
| segment list, along with their respective SR segment endpoint
| behavior, flavors, structure, and any other relevant attribute (e.g.,
| the set of L3 adjacencies associated with an End.X SID).
Looks good.
40. Note that, per #39, there is a gnarly error condition. If a not
REPLACE-C-SID LNF finds its way into a C-SID sequence and it is not
at the end of the sequence, that is OK because the rest of the
sequence will be skipped, except...
If the not-REPLACE-C-SID is in one C-SID container and there follows
another (continuation) C-SID container, then stuff will go badly
wrong! The packet will either be misrouted or dropped at the next
node. Dropping is not so bad, misrouting is embarrassing and to be
avoided. In both cases, network diagnostics are needed.
In general, it may be argued that this is an encoding error. Whoever,
built the SID list made a mess. But there is the case where the node
that initiated the SID has made a mistake, and there may be a transit
case where a SID is moving between flavors.
The problem that you describe can happen with any SRv6 SID. If the
SR source node places an incorrect SID in the segment list, or if the
SR segment endpoint node advertises something different than
what it installed, then issues can happen. Classic network diagnostic
tools like ping or traceroute can be used to troubleshoot such issues.
I don’t want to make a big thing of this, and you are, of course, right that
any SID list could be messed up with “interesting” results.
However, I think this document introduces another way to mix things up
because the SID list could be built correctly, but compressed incorrectly.
I appreciate that ping and traceroute are good diagnostic tools, and they
can help isolate the point in the compressed SID list where the error is
found.
Maybe it is not necessary to say any more, although I always like to call
out potential problems because they help people identify what they
should worry about in an implementation and deployment.
The compression is really a part of building the SRv6 packet. The source
node is responsible for finding our the right SIDs to use, compressing them,
and generating the appropriate packet header. It may outsource the first
operation (e.g., when the segment list is obtained via config, PCEP, or BGP),
but remains in charge of the last two and may mess them up.
Yes, that's the point I was trying to drive at. The SID list is built by one
component and it gets it right (or wrong in the way we are familiar with).
Another component is responsible for SID compression and could mess that up in
its own way.
From an externally visible perspective, there is no difference whether the
bug resides in the compression logic or in the header generation. The same
erroneous packet can be produced with the same results in the network.
Right. If we treat everything as a black box, wrong is just wrong.
Again, this is not a biggie, but I just think that this document adds more
complexity (it's good complexity!) and so more opportunity for errors.
62. I had to read Section 8 a few times.
The End.XPS is a new SID behavior defined in this document. While you
then go on to define how it may be given a C-SID flavor, the End.XPS
SID is not anything to do with compression: it is a new concept and I
don't see why you have "hidden" it in this document. Indeed, it
doesn't seem to be mentioned in the Implementation Status section or
in the IANA section, so perhaps it is "ambitious" to include it in
this document.
While you say that the "End.XPS behavior described in this section is
OPTIONAL" I think that is a bit confusing. It implies that the
described processing is optional. I think you could use "The use of
the End.XPS SID behavior is OPTIONAL." But you do go on to write...
| This section defines an optional solution and SID behavior allowing
| for the use of different Locator-Blocks between routing domains.
So how do you handle the scenario described if you don't use this
optional solution and an End.XPS SID behavior?
You don’t seem to have answered this one (now Section 7).
Yes. We did not forget your question, but were still working on the text
update for this section.
We reworked this section 7 in revision -10, making it more clear why the
solution is useful and how it works.
If this solution is not available, the source node may need to use a different
C-SID sequence for each of the traversed domains, ending the previous
sequence before the domain boundary and starting a new one for the next
domain (this is also mentionned in the new text).
Section 7 in -10 is much better. Thanks.
66. Section 9
| The SR segment endpoint node MUST set the SID argument bits to 0 when
| advertising a locally instantiated SID of this document in the
| routing protocol (e.g., IS-IS [RFC9352], OSPF
| [I-D.ietf-lsr-ospfv3-srv6-extensions], or BGP-LS
| [I-D.ietf-idr-bgpls-srv6-ext]).
b. What happens if a node receives an advertisement of a SID with one
of these flavors but does not support the advertised flavor? That
may be answered with a simple "handled as described in..."
If a node does not support the SIDs of this document, then it won't follow
whatever this document says. It is not clear how adding text here could help.
It’s true, you can’t say anything normative about how an implementation
that does not support this specification must behave.
But you can add information for the reader to explain how this is backward
compatible by noting (with reference) the expected behavior or a node that
receives an advertisement of a SID with SID type that is unknown or
unsupported.
We added text following your suggestion at the end of section 8 in revision -10
of the document.
| When a node that does not support this specification receives an
| advertisement of a SID of this document, it handles it as described
| in the corresponding control plane specification (e.g., Sections 7.2,
| 8.1, and 8.2 of [RFC9352], Sections 8, 9.1, and 9.2 of
| [I-D.ietf-lsr-ospfv3-srv6-extensions], and Section 3.1 of [RFC9252]).
Nice
c. What happens if a node receives an advertisement of a SID with one
of these flavors but the argument bits are non-zero? The answer is
is not to be found in other documents because those documents don't
describe those flavors (but you might have "MUST treat the received
advertisement as malformed/unsupported and process it as described
in Section x.y of RFC abcd."
This is described in section 6. For example,
| A SID with the NEXT-C-SID flavor is compressible if its structure is
| known to the SR source node and its Argument value is 0.
In this case the source node would not compress the SID.
Ah, interesting. So this would be a valid advertisement and a valid SID that
can be used as a normal SID. It just can’t be compressed using the
mechanisms defined in this document.
This is correct.
OK. Clear.
67. Section 9
| Signaling the SRv6 SID Structure is REQUIRED for all the SIDs
| introduced in this document.
b. What does a receiver do if it gets an advertisement of one of a
SID with one of these SID flavors but without an indication of the
SRv6 SID Structure? Again, possibly, "MUST treat the received
advertisement as malformed/unsupported and process it as described
in Section x.y of RFC abcd."
This is described in section 6 (see response to comment 66.c. above).
And a similar response. You are saying that this is a valid advertisement
of a SID that can be used as normal, but can’t be compressed using the
mechanisms defined in this document.
It wouldn't be a valid advertisement in the sense that the node advertising
the SID did not follow the "REQUIRED", but the SID remains usable by the
source node.
Let's not quibble about the meaning of "valid advertisement" or we will get in
a mess 😊
The advertisement indicates a SID that can be used, so we're good.
70. Section 9
For a segment list computed by a controller and signaled to an SR
source node (e.g., via BGP [I-D.ietf-idr-segment-routing-te-policy]
or PCEP [I-D.ietf-pce-segment-routing-ipv6]), the controller provides
the ordered segment list comprising the uncompressed SIDs to the SR
source node. The SR source node may then compress the segment list
as described in Section 7.
I asked a question in #53 about whether the compression could be done
by a controller. You seem to be saying that it cannot, but I don't see
why that is the case. Compression is non-trivial processing, and there
could be implementation benefits from placing it in a controller.
However, it is possible that your thinking is that the source node
would like to hold an uncompressed SID list for diagnostic purposes.
In any case, how does a source node process if it receives a SID list
that has already been compresses? In some cases, how would it even
know!
Actually, there is an implicit architectural requirement here that
sets the control as determining the path as a SID list, but the source
node as responsible for listening to the SID advertisements to know
what flavors (and SID structures) have been advertised in order to
process the compression. Why do you force this separation? Why can't
the controller listen to all the advertisements?
When a controller computes the segment list, it listens to all
advertisements. It needs to know the meaning of each of the segments
that it places in the segment list.
I agree with this statement.
We rephrased this paragraph in revision -09 to clarify that the controller
passes the behavior/structure information to the source node along with
each SID.
| For a segment list computed by a controller and signaled to an SR
| source node (e.g., via BGP [I-D.ietf-idr-segment-routing-te-policy]
| or PCEP [I-D.ietf-pce-segment-routing-ipv6]), the controller provides
| the ordered segment list comprising the uncompressed SIDs, with their
| respective behavior and structure, to the SR source node. The SR
| source node may then compress the segment list as described in
| Section 6.
OK, this is clear, and reading the cited drafts indicates that the “SID list”
they facilitate the controller providing is a list of SIDs and not the SID list
that is placed in the SRH (without compression).
I still think it is sad that there is no facility for the controller to perform
compression (since it has the time and the CPU), but, well, I won’t force
the point.
We do not want to prevent a controller from performing compression in
the future, but would like to limit the scope of this document to the case
where the source node performs this operation.
74. I wonder what the plans are for the draft referenced from Section 11
I-D.clad-spring-srv6-srh-compression-illus appears to have expired
some long time ago and has only had nit changes since it was first
posted in October 2021. Is the content even consistent with this draft
which has constantly evolved over the last two years?
Clearly, that draft is not normative and only supplies illustrations,
but if it is deemed helpful to have illustrations, something needs to
change. Alternatively, perhaps Section 11 should be cut.
You didn’t answer this and I don’t see any change in the document.
Also, I see no progress on the referenced draft.
I think it is time to cut this section – this document stands on its own.
We removed this section and reference in revision -10.
Ack
75. I think Section 12 could really use some more details.
For example:
- Do you expect deployments to restrict a single SR-domain to use at
most one flavor of C-SID?
- If not, it would be useful to have a section in the document
making a clear description of the processing when both flavors
are present. I think it "just works" but a little more text
describing how/why this is the case would help. And compare with
Section 4 where there is a recommendation to limit to a single
flavor in a single domain - certainly, the "ease of operation"
mentioned in that section deserves to be called out here.
- Do you make a distinction between SR-domain and AS/routing domain
as described in Section 8?
We reworked the text in section 3 and 8 to clearly differentiate the SR
domain (RFC 8402) and the routing domain.
In section 4,
| The SIDs of both flavors can co-exist in the same SR domain, on the
| same SR segment endpoint node, and even in the same segment list.
| However, it is RECOMMENDED, for ease of operation, that a single
| compressed encoding flavor be used in a given routing domain. In a
| multi-domain deployment, different flavors MAY be used in different
| routing domains of the SR domain.
In section 8 (section 7 in revision -09),
| Some SRv6 traffic may need to cross multiple routing domains, such as
| different Autonomous Systems (ASes) or different routing areas within
| an SR domain. Different routing domains may use different addressing
| schema and Locator-Blocks.
These are good changes. But Section (now) 11 remains looking very thin.
If you are reluctant to add substance to the section maybe we should cut it.
We merged this section into the security considerations in revision -10.
A good solution.
76. You might add a note to the top of Section 13 to remind the RFC
Editor to clean up the many references from this section when it is
deleted.
This sentence is an XML2RFC boilerplate (`<section removeInRFC="true">`).
Can it be edited?
You can write whatever you like in addition to the auto-generated text.
My suggestion is to add something like.
RFC-Editor: Please clean up the references cited by this section before
publication.
We added this text in revision -10.
Fine.
77. I found Section 14 to be very sparse and so a little unbelievable.
Surely Section 8 introduces some Security concerns? Should you
have an Informative reference to draft-li-spring-srv6-security-
consideration or some similar ongoing work to address the continued
concerns about SR security.
I don’t see an answer or any changes on this point. In order to get through
today’s IESG, I think you are going to have to say more than is written here.
It is not a weakness to call out security vulnerabilities/concerns because
it helps people know exactly what precautions to take when deploying.
Similar to #62 above, we were still working on the text update for this section.
We reworked this section in revision -10.
This is better. Thanks. We'll see what the IESG does with it.
78. Is Section 15 (IANA) missing registration for End.XPS with and
without flavors?
I don’t see an answer or any changes on this point. Surely if the section
defining End.XPS is to remain in this document, there must also be
corresponding IANA work.
Fixed in revision -10. We will request the codepoint allocation from IANA
and update the table as soon as we get that.
This looks right.
I was momentarily concerned that there is no request of vanilla End.PS and
End.XPS SIDs, but that is aligned with Sections 7.1 and 7.2.
81. Hoping that Appendix A will be resolved
Are these issues, in fact, resolved and just listed here for information?
If so, then I think it is time to remove the section or add a note that the
issues have been resolved. If not, then we need a plan to resolve them!
This text indeed seems outdated. We will work with the chairs to figure
out what to do with it.
The issues related to this draft are tracked on GitHub.
OK. I would certainly recommend having all existing issue in git hub resolved
and this section removed before passing the draft to the AD.
82. I wonder whether you need some clarification in the document to
describe if you can have multiple C-SID flavors of the same SID
advertised and, if so, how a path selection node might decide which
flavor (including the non-CSID flavor) to use at any hop as it
builds the path.
It seems generally better for a source node to select a C-SID flavor SID
over an equivalent non-C-SID flavor SID, given that the former enables
compression.
That’s a good thing to say. Want to add it to the document? It’s either plain
text, or a recommendation. And it is a very few words.
However, a choice between one C-SID flavor or the other is unlikely to
present itself given the recommendation to avoid mixing C-SID flavors
within a routing domain (section 4).
Weeeeell, it is “only” a recommendation. And, indeed, the document
goes to some lengths (possibly to address the issue of “is this one or
two solutions presented in a single document?”) to show that you can
mix compression flavours in the same SID list. That means that
advertising both flavours of C-SID is both possible and acceptable. So
you can’t gloss over answering what happens when both flavours are
present: how do you choose?
We added some guidance on this aspect in section 6.2 in revision -10,
although the general mechanism to come up with an uncompressed
segment list remains out of scope.
| It is out of the scope of this document to describe the mechanism
| through which an uncompressed segment list is derived. As a general
| guidance for implementation or future specification, such a mechanism
| should aim to select the combination of SIDs that would result in the
| shortest compressed segment list. For example, by selecting a C-SID
| flavor SID over an equivalent non-C-SID flavor SID or by consistently
| selecting SIDs of the same C-SID flavor within each routing domain.
That helps. Thanks.
83. It would be really good to include a section on future compatibility.
a. What consideration should be given to future SID endpoint behaviors
in terms of making them compressible using the flavors here?
We added this new section in revision -10.
| 11. Applicability to other SR Segment Endpoint Behaviors
|
| Future documents may extend the applicability of the NEXT-C-SID and
| REPLACE-C-SID flavors to other SR segment endpoint behaviors.
|
| For an SR segment endpoint behavior that can be used before the last
| position of a segment list, a C-SID flavor is defined by reproducing
| the same logic as described in Section 4.1 and Section 4.2 of this
| document to determine the next segment in the segment list.
Nice
b. Are there any comments the document should include about inventing
future C-SID flavors
No comment. :)
Well, section 11 says it all now, so good.
=== END
On Nov 16, 2023 at 19:55:38, Adrian Farrel <mailto:adr...@olddog.co.uk> wrote:
Hi again Francois,
Thanks for your patience while I got back from Prague.
I have looked through the diffs and respond in line below.
This is good work, and captures very nearly everything. I snipped out every point of agreement.
Best,
Adrian
0. Please get into the habit of running idnits before posting a new
revision.
== Missing Reference: 'RFC8200' is mentioned on line 996, but not
defined
RFC 8200 is only mentioned in a quoted text from RFC 8754. We fixed
the quote format in revision -09, so that idnits should no longer complain
about this.
Hmmm. Idnits continues to object.
I don’t have a strong opinion, but inserting an Informative Reference would
clean it up.
13. Section 2 has:
| A compressed Segment List encoding may also contain
| any number of uncompressed SID sequences.
Yeah, and zero is any number. But I think you say this more
gracefully.
This zero case was not intended to be covered by "any number" but
by the use of the modal "may": "A compressed Segment List encoding
**may** also contain \[...\]." That said, please let us know if you have
any suggestion to improve this phrasing.
Well, not sure. If you meant to exclude zero, then perhaps
| A compressed Segment List encoding contains one or more
| uncompressed SID sequences.
If you meant to allow zero, then
| A compressed Segment List encoding contains zero, one, or more
| uncompressed SID sequences.
16. Section 3
| When a sequence of consecutive SIDs in a Segment List shares a common
| Locator-Block, a compressed Segment-List encoding can optimize the
| packet header length by avoiding the repetition of the Locator-Block
| and trailing bits with each individual SID.
I think you are saying two separate things in this paragraph, but the
text is not very clear:
- a compressed Segment-List encoding can be used
- the act of compressing the Segment-List might reduce the packet
header length
We rephrased this sentence in revision -09.
| The compressed segment list encoding decreases the packet header
| length by avoiding the repetition of the same Locator-Block and
| reducing the use of padding bits.
This is much better.
I think you are asserting that the compressed list always reduces the packet
header length, but (of course) there is an edge condition where it makes no
difference (compress one SID into a C-SID).
26. Section 4.1
| An SR segment endpoint node instantiating a SID with the NEXT-C-SID
| flavor MUST accept any argument value for that SID.
It is clear that the endpoint knows the flavor of the SIDs it has
initiated, but it is not clear how the flavor of the SID is known
by anyone else in order that they can compress it or use an
argument value.
The SID flavor is advertised in the control plane as part of the "behavior"
identifier (see RFC 9252, RFC 9352,
https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#srv6-endpoint-behaviors).
If you believe this is clear then, that’s fine. Otherwise, just add a few words.
40. Note that, per #39, there is a gnarly error condition. If a not
REPLACE-C-SID LNF finds its way into a C-SID sequence and it is not
at the end of the sequence, that is OK because the rest of the
sequence will be skipped, except...
If the not-REPLACE-C-SID is in one C-SID container and there follows
another (continuation) C-SID container, then stuff will go badly
wrong! The packet will either be misrouted or dropped at the next
node. Dropping is not so bad, misrouting is embarrassing and to be
avoided. In both cases, network diagnostics are needed.
In general, it may be argued that this is an encoding error. Whoever,
built the SID list made a mess. But there is the case where the node
that initiated the SID has made a mistake, and there may be a transit
case where a SID is moving between flavors.
The problem that you describe can happen with any SRv6 SID. If the
SR source node places an incorrect SID in the segment list, or if the
SR segment endpoint node advertises something different than
what it installed, then issues can happen. Classic network diagnostic
tools like ping or traceroute can be used to troubleshoot such issues.
I don’t want to make a big thing of this, and you are, of course, right that any SID list could be messed up with “interesting” results.
However, I think this document introduces another way to mix things up because
the SID list could be built correctly, but compressed incorrectly.
I appreciate that ping and traceroute are good diagnostic tools, and they can
help isolate the point in the compressed SID list where the error is found.
Maybe it is not necessary to say any more, although I always like to call out potential problems because they help people identify what they should worry about in an implementation and deployment.
62. I had to read Section 8 a few times.
The End.XPS is a new SID behavior defined in this document. While you
then go on to define how it may be given a C-SID flavor, the End.XPS
SID is not anything to do with compression: it is a new concept and I
don't see why you have "hidden" it in this document. Indeed, it
doesn't seem to be mentioned in the Implementation Status section or
in the IANA section, so perhaps it is "ambitious" to include it in
this document.
While you say that the "End.XPS behavior described in this section is
OPTIONAL" I think that is a bit confusing. It implies that the
described processing is optional. I think you could use "The use of
the End.XPS SID behavior is OPTIONAL." But you do go on to write...
| This section defines an optional solution and SID behavior allowing
| for the use of different Locator-Blocks between routing domains.
So how do you handle the scenario described if you don't use this
optional solution and an End.XPS SID behavior?
You don’t seem to have answered this one (now Section 7).
66. Section 9
| The SR segment endpoint node MUST set the SID argument bits to 0 when
| advertising a locally instantiated SID of this document in the
| routing protocol (e.g., IS-IS [RFC9352], OSPF
| [I-D.ietf-lsr-ospfv3-srv6-extensions], or BGP-LS
| [I-D.ietf-idr-bgpls-srv6-ext]).
b. What happens if a node receives an advertisement of a SID with one
of these flavors but does not support the advertised flavor? That
may be answered with a simple "handled as described in..."
If a node does not support the SIDs of this document, then it won't follow
whatever this document says. It is not clear how adding text here could help.
It’s true, you can’t say anything normative about how an implementation that does not support this specification must behave.
But you can add information for the reader to explain how this is backward
compatible by noting (with reference) the expected behavior or a node that
receives an advertisement of a SID with SID type that is unknown or unsupported.
c. What happens if a node receives an advertisement of a SID with one
of these flavors but the argument bits are non-zero? The answer is
is not to be found in other documents because those documents don't
describe those flavors (but you might have "MUST treat the received
advertisement as malformed/unsupported and process it as described
in Section x.y of RFC abcd."
This is described in section 6. For example,
| A SID with the NEXT-C-SID flavor is compressible if its structure is
| known to the SR source node and its Argument value is 0.
In this case the source node would not compress the SID.
Ah, interesting. So this would be a valid advertisement and a valid SID that can be used as a normal SID. It just can’t be compressed using the mechanisms defined in this document.
67. Section 9
| Signaling the SRv6 SID Structure is REQUIRED for all the SIDs
| introduced in this document.
b. What does a receiver do if it gets an advertisement of one of a
SID with one of these SID flavors but without an indication of the
SRv6 SID Structure? Again, possibly, "MUST treat the received
advertisement as malformed/unsupported and process it as described
in Section x.y of RFC abcd."
This is described in section 6 (see response to comment 66.c. above).
And a similar response. You are saying that this is a valid advertisement of a SID that can be used as normal, but can’t be compressed using the mechanisms defined in this document.
70. Section 9
For a segment list computed by a controller and signaled to an SR
source node (e.g., via BGP [I-D.ietf-idr-segment-routing-te-policy]
or PCEP [I-D.ietf-pce-segment-routing-ipv6]), the controller provides
the ordered segment list comprising the uncompressed SIDs to the SR
source node. The SR source node may then compress the segment list
as described in Section 7.
I asked a question in #53 about whether the compression could be done
by a controller. You seem to be saying that it cannot, but I don't see
why that is the case. Compression is non-trivial processing, and there
could be implementation benefits from placing it in a controller.
However, it is possible that your thinking is that the source node
would like to hold an uncompressed SID list for diagnostic purposes.
In any case, how does a source node process if it receives a SID list
that has already been compresses? In some cases, how would it even
know!
Actually, there is an implicit architectural requirement here that
sets the control as determining the path as a SID list, but the source
node as responsible for listening to the SID advertisements to know
what flavors (and SID structures) have been advertised in order to
process the compression. Why do you force this separation? Why can't
the controller listen to all the advertisements?
When a controller computes the segment list, it listens to all
advertisements. It needs to know the meaning of each of the segments
that it places in the segment list.
I agree with this statement.
We rephrased this paragraph in revision -09 to clarify that the controller
passes the behavior/structure information to the source node along with
each SID.
| For a segment list computed by a controller and signaled to an SR
| source node (e.g., via BGP [I-D.ietf-idr-segment-routing-te-policy]
| or PCEP [I-D.ietf-pce-segment-routing-ipv6]), the controller provides
| the ordered segment list comprising the uncompressed SIDs, with their
| respective behavior and structure, to the SR source node. The SR
| source node may then compress the segment list as described in
| Section 6.
OK, this is clear, and reading the cited drafts indicates that the “SID list” they facilitate the controller providing is a list of SIDs and not the SID list that is placed in the SRH (without compression).
I still think it is sad that there is no facility for the controller to perform compression (since it has the time and the CPU), but, well, I won’t force the point.
74. I wonder what the plans are for the draft referenced from Section 11
I-D.clad-spring-srv6-srh-compression-illus appears to have expired
some long time ago and has only had nit changes since it was first
posted in October 2021. Is the content even consistent with this draft
which has constantly evolved over the last two years?
Clearly, that draft is not normative and only supplies illustrations,
but if it is deemed helpful to have illustrations, something needs to
change. Alternatively, perhaps Section 11 should be cut.
You didn’t answer this and I don’t see any change in the document.
Also, I see no progress on the referenced draft.
I think it is time to cut this section – this document stands on its own.
75. I think Section 12 could really use some more details.
For example:
- Do you expect deployments to restrict a single SR-domain to use at
most one flavor of C-SID?
- If not, it would be useful to have a section in the document
making a clear description of the processing when both flavors
are present. I think it "just works" but a little more text
describing how/why this is the case would help. And compare with
Section 4 where there is a recommendation to limit to a single
flavor in a single domain - certainly, the "ease of operation"
mentioned in that section deserves to be called out here.
- Do you make a distinction between SR-domain and AS/routing domain
as described in Section 8?
We reworked the text in section 3 and 8 to clearly differentiate the SR
domain (RFC 8402) and the routing domain.
In section 4,
| The SIDs of both flavors can co-exist in the same SR domain, on the
| same SR segment endpoint node, and even in the same segment list.
| However, it is RECOMMENDED, for ease of operation, that a single
| compressed encoding flavor be used in a given routing domain. In a
| multi-domain deployment, different flavors MAY be used in different
| routing domains of the SR domain.
In section 8 (section 7 in revision -09),
| Some SRv6 traffic may need to cross multiple routing domains, such as
| different Autonomous Systems (ASes) or different routing areas within
| an SR domain. Different routing domains may use different addressing
| schema and Locator-Blocks.
These are good changes. But Section (now) 11 remains looking very thin.
If you are reluctant to add substance to the section maybe we should cut it.
76. You might add a note to the top of Section 13 to remind the RFC
Editor to clean up the many references from this section when it is
deleted.
This sentence is an XML2RFC boilerplate (`<section removeInRFC="true">`).
Can it be edited?
You can write whatever you like in addition to the auto-generated text.
My suggestion is to add something like.
RFC-Editor: Please clean up the references cited by this section before publication.
77. I found Section 14 to be very sparse and so a little unbelievable.
Surely Section 8 introduces some Security concerns? Should you
have an Informative reference to draft-li-spring-srv6-security-
consideration or some similar ongoing work to address the continued
concerns about SR security.
I don’t see an answer or any changes on this point. In order to get through today’s IESG, I think you are going to have to say more than is written here.
It is not a weakness to call out security vulnerabilities/concerns because it helps people know exactly what precautions to take when deploying.
78. Is Section 15 (IANA) missing registration for End.XPS with and
without flavors?
I don’t see an answer or any changes on this point. Surely if the section defining End.XPS is to remain in this document, there must also been corresponding IANA work.
81. Hoping that Appendix A will be resolved
Are these issues, in fact, resolved and just listed here for information? If so, then I think it is time to remove the section or add a note that the issues have been resolved. If not, then we need a plan to resolve them!
82. I wonder whether you need some clarification in the document to
describe if you can have multiple C-SID flavors of the same SID
advertised and, if so, how a path selection node might decide which
flavor (including the non-CSID flavor) to use at any hop as it
builds the path.
It seems generally better for a source node to select a C-SID flavor SID
over an equivalent non-C-SID flavor SID, given that the former enables
compression.
That’s a good thing to say. Want to add it to the document? It’s either plain text, or a recommendation. And it is a very few words.
However, a choice between one C-SID flavor or the other is unlikely to
present itself given the recommendation to avoid mixing C-SID flavors
within a routing domain (section 4).
Weeeeell, it is “only” a recommendation. And, indeed, the document goes to some lengths (possibly to address the issue of “is this one or two solutions presented in a single document?”) to show that you can mix compression flavours in the same SID list. That means that advertising both flavours of C-SID is both possible and acceptable. So you can’t gloss over answering what happens when both flavours are present: how do you choose?
83. It would be really good to include a section on future compatibility.
a. What consideration should be given to future SID endpoint behaviors
in terms of making them compressible using the flavors here?
b. Are there any comments the document should include about inventing
future C-SID flavors
Nothing for this?
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
