Hi Suresh,
Thank you for the replies.
Please see inline:
On 10/27/23 11:30, Suresh Krishnan wrote:
[…]
Section 1:
"SR segment endpoint nodes process a local segment present the Destination
Address of an IPv6 header." I have a hard time parsing this phrase, and I think
adding a preposition or an "-ing" somewhere would make it easier. Is this "SR
segment endpoint nodes processing a local segment present the Destination
Address of an IPv6 header." or "SR segment endpoint nodes process a local
segment which presents the Destination Address of an IPv6 header." or something
else?
I will reword this to
"SR segment endpoint nodes process a local segment present in the Destination
Address of an IPv6 header”
Does that clarify the intent?
Yes, thank you.
Section 3:
Are all SIDs IPv6 addresses? This section sounds like it implies that they are,
while the abstract says that they merely "resemble" IPv6 addresses. I suggest
clarifying this point in the document.
I had attempted to address this with the following text in Section 3.
Some of these elements may represent a local interface as described
in Section 4.3 of [RFC8754] as "A FIB entry that represents a local
interface, not locally instantiated as an SRv6 SID". From this it
follows that not all the SIDs that appear in the SRH are SRv6 SIDs as
defined by [RFC8402].
Does that clarify further?
I did see this text, but I could not get an answer to my question from
this text, being a general reviewer without a lot of context on SRv6.
In my reading, either all SIDs are IPv6 addresses (which is what Section
3 seems to imply), or all SIDs resemble IPv6 addresses but are not
necessarily IPv6 addresses (which is what the Abstract seems to imply).
Is it possible to make a direct statement saying which of the two is
true, or am I making the wrong distinction?
If all SIDs are in fact IPv6 addresses, then I suggest changing text in
the abstract such as:
OLD: "Segment Identifiers (SIDs) used by SRv6 can resemble IPv6
addresses and behave like them while exhibiting slightly different
behaviors in some situations"
NEW: "Segment Identifiers (SIDs) used by SRv6 are IPv6 addresses which
may exhibiting slightly different behaviors than specified in the IPv6
Addressing architecture [RFC4291] in some situations"
If not all SIDs are IPv6 addresses, then I suggest changing text in
Section 3 such as:
OLD: "[RFC8754] defines the Segment List of the SRH as a contiguous
array of 128-bit IPv6 addresses"
NEW: "[RFC8754] defines the Segment List of the SRH as a contiguous
array of 128-bit identifiers which resemble IPv6 addresses"
Of course, if the text is quoting from RFC8754, it might not be possible
to make this change. My comment is not blocking, it's just a point of
confusion for me.
"Such a SID is assigned to a node within a prefix defined as a Locator of
length L." Does "Such a SID" refer to the previous sentence, which talks about
SIDs with L+F+A < 128? If not, what is meant by "Such a SID"?
"Such as SID" refers to the "Section 3.1. of [RFC8986] describes the format of an SRv6 SID…”. The padding piece you mentioned is still part of the definition from RFC8986 and was added to the draft since it was brought up as a question in 6man.
I see. In this case, maybe it helps to simply remove the "Such" from the
sentence, as it appears the sentence is talking about SIDs in general?
IANA Considerations:
This document asks IANA to allocate a Global Unicast Prefix for SIDs. According
to Section 5.1 of RFC 5226, I suggest that this document explicitly identify
the namespace in which a value is to be allocated - The "Internet Protocol
Version 6 Address Space" registry has multiple prefixes marked as "Reserved by
IETF". According to RFC 3513, I assume this will be under the 1000::/4 prefix,
but I may be missing context here.
There is a separate discussion ongoing with IANA on this and it appears to tend towards an allocation of the
fbff::/16 block. I will update this in the next version of the draft.
Sounds good, thanks!
Best,
Reese
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
