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> 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) > > > > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
