Thanks, some additional clarification on my remarks below /Eduard
> With regard to RFC4291 I assume the main observation is that the SRv6 SID > structure does not match with the structure of RFC4291, in particular the > interface ID part. A small discussion on the other aspects of RFC4291 could > be added to further clarify this (as done for the subnet-router anycast > address). In theory, if the SRv6 SID would start with "000" the interface > ID would not even be a problem. > > > The actual block to be allocated will come from IANA but there are a whole > bunch of allocations in this space that are used for special purposes > already and the goal might be to make this prefix separate from the > existing used blocks. If you have a suggestion for a recommendation from > the WG, feel free to put one up. > > The remark was actually not about the to be allocated block, but about the analysis of SRv6 SID vs RFC4291. To rephrase, my suggestion is to include a (small) discussion on all the aspects covered in RFC4291 in relation to SRv6 SIDs. To have a complete view and point out the "issues" if any. > > > > Some specific points in the draft-01 text: > > > [RFC8754] defines the Segment List of the SRH as a contiguous array of > 128-bit IPv6 addresses, and that each of the elements in this list are > SIDs. But all of these elements are not necessarily made equal. Some of > these elements may represent a local interface as described in Section 4.3 > of [RFC8754] <https://datatracker.ietf.org/doc/html/rfc8754#section-4.3> > as "A FIB entry that represents a local interface, not locally instantiated > as an SRv6 SID". From this it follows that all the SIDs that appear in the > SRH are not SRv6 SIDs as defined by [RFC8402 > <https://datatracker.ietf.org/doc/html/rfc8402>]. > > This paragraph starts with stating that each of the elements in an SR list > of the SRH are SIDs (first sentence) and ends with that all the SIDs in > the SRH are not SRv6 SIDs. This is contradicting. > > > Hmm. The whole point of this paragraph is to establish that all SIDs are > not SRv6 SIDs as some SIDs represent local interfaces and are RFC4291 > compliant. Not sure where the contradiction is. > > Maybe it is just the wording, possibly stating that Segment List consists of segments, and that segments are SRv6 SIDs with some (one?) exception. 4.3.2 <https://datatracker.ietf.org/doc/html/rfc8754#section-4.3.2>. FIB Entry Is a Local Interface If the FIB entry represents a local interface and is not locally instantiated as an SRv6 SID, the SRH is processed as follows: If Segments Left is zero, the node must ignore the routing header and proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header. If Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognized Routing Type. The last part of this paragraph states that if the DA of the packet is not an SRv6 SID (but a local IPv6 address) and Segments left is non-zero, it is considered an error situation (hence, non SRv6 SID segments should not appear at arbitrary positions in the segment list. If segments left is zero, the packet is processed. So the non-SRv6 SID segment could be the last (or first) in the Segment List. > > "Some of these elements may represent a local interface as described in > Section 4.3 > of [RFC8754] <https://datatracker.ietf.org/doc/html/rfc8754#section-4.3> > as "A FIB entry that represents a local interface, not locally instantiated > as an SRv6 SID"" > Section 4.3 describes the potential outcomes of an LPM lookup on IPv6 DA > address on a packet in an SRv6 capable node, it does not describe the SRH. > > > "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 > <https://datatracker.ietf.org/doc/html/rfc4291>]. " > Having non-SRv6-SID elements in the SRH list seems an error condition? See > also RFC8745, section 4.3.2. Non SRv6 SID in DA field of packet with SRH is > an error condition here. > > > > > When the packet reaches the ultimate end host it will have an SRH with > SL=0 and this is not considered an error as per Section 4.3.2 when the DA > contains an address assigned to a local interface (non SRv6 SID). > > Yes, but having non-SRv6 SID segment in the middle is a problem. Also, the DA in this case may not have been in the Segment List at all. Come to think of it, the analysis of Segment List may be even left out. It is the SRv6 SID itself that is central to this document. > Section 4.1 > > > Section 4.1. is expected to be removed from the draft pending consensus > from the spring WG to pick up the issues. The 6man chairs and the spring > chairs will provide further guidance on this. If the text needs to remain > in the draft I think your comments make sense and I will address them in > the next rev. If not, I will pass along the comments to the authors of > C-SID. > > > Chapter 6 > The size of the block seems possibly small. How is it sized? > > > The size was picked based on feedback from some operators who would like > to deploy SRv6 with C-SIDs in this block and the suggested block size of > /16 provides a good balance between efficiency and address conservation. My > personal opinion is that allocating a larger block would be excessive, but > if you have arguments as to why it should be larger please make them to the > WG. > > > I would suggest to reserve a block that is sufficiently large and include > at least some high-level guidelines regarding its use. For example is it > intended to be ULA alike, or globally unique? Is use of the block for SRv6 > mandatory, or optional? > > > The use of this block for SRv6 is optional. Please let me know if there is > any text that states or implies otherwise. > > Well it is not stated that it is mandatory, also it is not stated it is optional. I suggest to include the assumptions regarding the block in the document. Like the optional use, should be seperate block, and the assumptions underlying the sizing. With regard to sizing, if the idea is to have a block that an operator can use within its "domain", and each operator uses the same block the required sizing would be different that from the case where each operator has a (statistically) unique prefix for SR within this block. I assume the former is the idea / assumption? > Thanks > Suresh >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
