Adrian -
To minimize back-and-forth, let me take a stab at addressing your comments as best I can and issue V9. We can then go over remaining outstanding issues. The only issue I can't see a way to resolve is your comments regarding ISO 10589. ISO 10589 does not speak to duplicate TLV handling. The closest it comes is Section 7.3.4.4, when it discusses what may happen if an adjacency advertisement is moved from one LSP to another: <snip> 7.3.4.4 Once a particular adjacency has been assigned to a particular LSP Number, it is desirable that it not be moved to another LSP Number. This is because moving an adjacency from one LSP to another can cause temporary loss of connectivity to that system. This can occur if the new version of the LSP which originally contained information about the adjacency (which now does not contain that information) is propagated before the new version of the other LSP (which now contains the information about the adjacency). NOTE 25 An implementation is recommended to ensure that the number of LSPs generated for a particular system is within approximately 10% of the optimal number which would be required if all LSPs were densely packed with neighbour options. Where possible this should be accomplished by re-using space in LSPs with a lower LSP Number for new adjacencies. If it is necessary to move an adjacency from one LSP to another, the SRMflags (see 7.3.15) for the two new LSPs shall be set as an atomic action.1) <end snip> The current description in Section 4 of the draft is based on implementation experience. Les > -----Original Message----- > From: Adrian Farrel <[email protected]> > Sent: Thursday, February 13, 2025 2:56 PM > To: Les Ginsberg (ginsberg) <[email protected]>; [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: RE: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 > > Good responses. Thanks, Les. > > Cutting down just to a few clarifications. If I left it out, then I am OK > with your > response. I'm not pushing on things where I think it can be worked out from > the text and you prefer to not make any changes. > > Cheers, > Adrian > > > 4. > > > > Pedantically... > > OLD > > In the absence of MP-TLV support, when a router receives an MP-TLV, > > it treats the TLVs as replacements for each other i.e., the receiver > > chooses which TLV will be processed and which TLV will be ignored. > > NEW > > In the absence of MP-TLV support, as specified in [ISO10589], when a > > router receives an MP-TLV, it treats one of the TLVs as a replacement > > for the others, i.e., the receiver chooses which TLV will be > > processed and which TLVs will be ignored. > > END > > > [LES:] ISO 10589 is not relevant here. None of the TLVs defined in ISO 10589 > are candidates for MP. > The potential for MP really came with the introduction of sub-TLVs (RFC > 5305). > So, I prefer to leave text unchanged. > > [AF] Ah, that was not my point. > 1. What document describes how to process a duplicate TLV and specifies the > behaviour you describe? Clearly this document cannot do that because > implementations that don't support this document cannot be controlled by it. > 2. The current text says "replacements for each other" which is a bit > extreme. I > am reminded of "An old farmer had three daughters each more beautiful than > the others." > > > 5. > > > > The contents of a multi-part TLV MUST be processed as if they were > > concatenated. > > > > This is probably the most important sentence in the document! > > Combined with: > > ...and... > > If the internals of the TLV contain key information, > > then replication of the key information MUST be taken to indicate > > that subsequent data MUST be processed as if the subsequent data were > > concatenated after a single copy of the key information. > > ...we can deduce a lot. > > 1. Information placed in component TLVs must be present such that the > > concatenation may be done in any order. That is, you can't just fill > > up the 255 bytes and then start a new TLV. > [LES:] This is explicitly stated in Section 5: > > "The receiving node must then process this as having key information K and > sub-TLVs A, B, C, D, E, F, or, because ordering is irrelevant, sub-TLVs D, E, > F, A, > B, C, or any other permutation." > > [AF] Yes, but. That example doesn't address my point. Perhaps I should have > worded it that the split between component TLVs MUST be done at a sub-TLV > or other unit boundary. > Again, this can be worked out, so it is not critical. > > > 2. If a TLV has a fixed part (which may contain a key) it must be > > present in each component TLV such that the component TLV is > > correctly composed in its own right. > > > [LES:] Section 5 also says: > > "If the internals of the TLV contain key information, then replication of the > key > information MUST be taken to indicate that subsequent data MUST be > processed as if the subsequent data were concatenated after a single copy of > the key information." > > [AF] Yes, but I think that is the flip of what I am asking about. That is, > that > when you extend a TLV into another TLV (i.e., two component TLVs of an MP- > TLV) you MUST replicate the key if there is one present. > > > I looked for this guidance in 8.2, but did not find it. While the text > > is acceptable as it stands (after all, this can be worked out) it would > > not hurt to make it clear by calling out these points explicitly either > > in 5 or 8.2. > [LES:] As I have pointed out, Section 5 already has explicit text on these > points. > 8.2 is talking about "generation". Section 5 and your comments on it are > about receive processing. I do not want to confuse the two. > > I suspect what you are after is that the description of receive processing > implies some requirements on how the originator of the TLV encodes it. This is > "loosely true" i.e., in a perfect world all MP-TLVs would be generated in > strict > accordance with rules (mentioned in 8.2). > But in the spirit of "be strict in what you send/generous in what you receive" > we want receivers to be more forgiving. Sending MP-TLVs when they are not > required (less than 255 bytes of info) is sub-optimal and undesirable, but we > intentionally stop short of declaring this "illegal". > This point was discussed at some length on the list and we (the authors) > were/are firm in our commitment to this approach. > > At this point I am not sure how to address your concerns or if they even need > to be addressed. > I'll think on this some more, but if after reading my response you have a > suggestion, please share. > > [AF] Hmmm, OK. I take your purpose about the purpose of section 5. > So maybe, especially in view of "strict on what you send", a little text in > 8.2. > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
