Hi Ketan, Thanks for the clarification and apologies for the misunderstanding.
What I would suggest is that a line be added to section 9 to make it explicitly clear that the end.x TLV’s are NOT sub-tlv’s of the locator – because while I realize on a second read that this is stated – it’s very easy to miss and I think this could end up with implementors making a similar mistake in the reading that I did. Thanks Andrew From: Ketan Talaulikar <ketant.i...@gmail.com> Date: Thursday, 8 June 2023 at 13:16 To: Andrew Alston - IETF <andrew-i...@liquid.tech> Cc: The IESG <i...@ietf.org>, draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org <draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>, lsr-cha...@ietf.org <lsr-cha...@ietf.org>, lsr@ietf.org <lsr@ietf.org>, a...@cisco.com <a...@cisco.com> Subject: Re: Andrew Alston's Discuss on draft-ietf-lsr-ospfv3-srv6-extensions-13: (with DISCUSS) CAUTION: This email has originated from a free email service commonly used for personal email services, please be guided accordingly especially if this email is asking to click links or share information. Hi Andrew, Thanks for your review and please check inline below for responses. On Thu, Jun 8, 2023 at 2:50 PM Andrew Alston via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Andrew Alston has entered the following ballot position for draft-ietf-lsr-ospfv3-srv6-extensions-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions> for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/<https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions> ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi There, Firstly thanks for the document. I'd like to have a discussion about the following text in Section 7.1. If the SRv6 Locator TLV for the same Locator appears in multiple SRv6 Locator LSAs that have the same flooding scope, the TLV in the SRv6 Locator LSA with the numerically smallest Link-State ID MUST be used and subsequent instances of the TLV MUST be ignored. My question may be as a result of not quite understanding the nature of End.X SID's - and as such, this may be easy to resolve. But - Reading the document, you have a limit of the size of an OSPFv3 packet of 65535 bytes (with fragmentation - which I would argue you probably don't wanna rely on). Now, if you are stacking END.X sub-TLV's beneath a locator SID - and you require more KT> The End.X sub-TLVs are not advertised under the Locator TLV but as sub-TLVs of each link/adjacency under the E-Router-Link TLV - refer https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-13#section-9<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-13#section-9>. Furthermore, the E-Router-LSA that carry the E-Router-Link TLV can have multiple instances to accomodate a large set of links - most granularly it could be one E-Router-LSA carrying a single link/adjacency each. This flows from the base OSPFv3 spec - refer https://datatracker.ietf.org/doc/html/rfc5340#section-4.4.3.2<https://datatracker.ietf.org/doc/html/rfc5340#section-4.4.3.2>. than 4000 of them on a large device (though in reality its probably far less than this because of overhead etc - if you avoid fragmentation even on a large MTU network you're at under 500) you're going to run into a problem because you cannot split the announcement by using the same locator in subsequent LSA's (my understanding is that normally this would be accomplished by having the same locator in multiple LSA's with different LS ID's, that the router would then combine). So - the question is - under what scenarios are END.X and END sub tlv's added to the packet and advertised - and could we run into a major length problem here on large dense devices that are, for example, terminating huge numbers of cross connects. Further to this, is there a reason why the locator cannot be split across multiple packets with different Link State ID's to reduce the size of the OSPF packets if this does become necessary? KT> As explained above, a large number of links would not result in growth of the SRv6 Locator TLV size. Since the SRv6 Locator is like an object on the same lines as a Link or a Prefix in OSPFv3, if it were to grow large the protocol mechanism today allows it to grow to the largest IP packet size of 64K (and subject to IP fragmentation). The OSPFv3 level fragmentation is available at an object level - i.e. different LSAs for each individual link or prefix or locator object is possible. If we ever get to a situation where we need to extend this protocol fragmentation capability, we would need to come up with a generic OSPFv3 mechanism to break a single object into multiple parts for all types of objects - not just the SRv6 Locator. IMHO, we don't yet have a case to do so. Thanks, Ketan (I do realise that you could use multiple locators on the same router to split this up - but would argue thats going to create operational nightmares and lead to potentially big problems with admins having to figure out when they are going to hit the limit) Internal All Employees
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
