Hi Andrew, I understand your point and thanks for your suggestion.
I've just posted an update that reflects this change: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-14 Thanks, Ketan On Thu, Jun 8, 2023 at 4:30 PM Andrew Alston - IETF <[email protected]> wrote: > 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 <[email protected]> > *Date: *Thursday, 8 June 2023 at 13:16 > *To: *Andrew Alston - IETF <[email protected]> > *Cc: *The IESG <[email protected]>, > [email protected] < > [email protected]>, [email protected] < > [email protected]>, [email protected] <[email protected]>, [email protected] < > [email protected]> > *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 < > [email protected]> 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/ > 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/ > > > > ---------------------------------------------------------------------- > 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. > 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. > > > > 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
