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 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? (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
