As Les’ example pointed out, what I suggested doesn’t quite capture it correctly. Let me say it differently: the solution is recursive, but strictly hierarchical.
Is that clearer? T > On Feb 21, 2025, at 12:22 PM, Robert Raszuk - robert at raszuk.net > <mailforwa...@cloudmails.net> wrote: > > > > I cannot split this sub-TLV across two TLV 22 advertisements i.e., > > Hmm based on what Tony wrote I read it that you could actually split it as > shown ... I think the draft could improve if the split boundaries were to be > clearly defined. > > > On Fri, Feb 21, 2025 at 7:08 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com > <mailto:ginsb...@cisco.com>> wrote: >> Robert – >> >> >> >> Consider the following example. >> >> >> >> https://www.rfc-editor.org/rfc/rfc8570.html#section-4.2 defines Min/Max >> Unidirectional Link Delay Sub-TLV: >> >> >> >> >> >> 0 1 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | 34 | Len = 8 | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> |A| RESERVED | Min Delay | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | RESERVED | Max Delay | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> I cannot split this sub-TLV across two TLV 22 advertisements i.e., >> >> >> >> In TLV #1: have >> >> >> >> >> >> 0 1 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | 34 | Len = 4 | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> |A| RESERVED | Min Delay | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> And in TLV #2: >> >> >> >> >> >> 0 1 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | 34 | Len = 4 | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | RESERVED | Max Delay | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> (or any other variations you can think of). >> >> >> >> Same applies to any level of sub-TLV. >> >> HTH >> >> >> >> Les >> >> >> >> From: Robert Raszuk <rob...@raszuk.net <mailto:rob...@raszuk.net>> >> Sent: Friday, February 21, 2025 9:25 AM >> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com <mailto:ginsb...@cisco.com>> >> Cc: Tony Li <tony...@tony.li <mailto:tony...@tony.li>>; lsr <lsr@ietf.org >> <mailto:lsr@ietf.org>> >> Subject: Re: [Lsr] [Last-Call] 答复: Re: 【Can you concatenate several pieces >> together without one "explicit key" to identify them belong to the same >> segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 >> >> >> >> Yes this was exactly my doubt ... and I actually thought that such boundary >> must be sub-TLV >> >> >> >> Maybe Tony had in mind sub-TLV which consists of TLVs (sub-sub-TLVs) such >> boundary could also work. >> >> >> >> But this sentence: >> >> >> >> "it cannot be required to have parts of another TLV in order to correctly >> parse any sub-TLV." >> >> >> >> is a bit cryptic. Can you pls provide some real life example(s) ? >> >> >> >> Thx >> >> >> >> On Fri, Feb 21, 2025 at 6:13 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com >> <mailto:ginsb...@cisco.com>> wrote: >> >> Robert/Tony - >> >> I think this relates to a point discussed during Adrian's RTGDIR review. >> Adrian made the point that: >> >> "... that the split between component TLVs MUST be done at a sub-TLV or >> other unit boundary." >> >> I had suggested text (but not actually added it to the latest version of the >> draft): >> >> “Each TLV that is part of an MP-TLV MUST be parsable independent of other >> TLVs in the MP-TLV. >> Breaking of a single sub-TLV or other data unit across TLVs MUST NOT be >> done.” >> >> Perhaps adding that text would help. >> >> Tony, of course, is also correct. He is saying just as we can split a top >> level TLV into multiple TLVs, we can also split any level of sub-TLV into >> multiple TLVs - the restriction being that the splitting MUST be done on a >> parsable boundary i.e., it cannot be required to have parts of another TLV >> in order to correctly parse any sub-TLV. >> >> Les >> >> > -----Original Message----- >> > From: Tony Li <tony1ath...@gmail.com <mailto:tony1ath...@gmail.com>> On >> > Behalf Of Tony Li >> > Sent: Friday, February 21, 2025 8:58 AM >> > To: Robert Raszuk <rob...@raszuk.net <mailto:rob...@raszuk.net>> >> > Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com >> > <mailto:ginsb...@cisco.com>>; lsr <lsr@ietf.org <mailto:lsr@ietf.org>> >> > Subject: Re: [Lsr] [Last-Call] 答复: Re: 【Can you concatenate several pieces >> > together without one "explicit key" to identify them belong to the same >> > segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 >> > >> > >> > Robert, >> > >> > > So it was very clear that we MUST skip what we do not recognize :) I >> > > was not >> > sure if we should at that point bail out from further parsing of a given >> > TLV or >> > trying next sub-TLV. I guess there is no mandate of that in the spec and >> > implementations should/may try to continue to parse. >> > >> > >> > You always continue to parse. Production implementations are not test >> > suites >> > looking for bugs. If there is unrecognized data, then the presumption is >> > that it >> > is new functionality that the implementation does not yet understand. >> > Stopping parsing would break legacy behavior. >> > >> > >> > > Also is my understanding correct that the subject draft does not allow to >> > split sub-TLVs itself ? Meaning that any sub-TLV must fit one part of the >> > TLV. I >> > found some text allowing duplication of sub-TLVs in multiple parts of TLV >> > if >> > sender choose to do such thing - but I assume this says that sub-TLV is >> > still a >> > complete one in each part ? >> > >> > >> > I’m not sure that I can parse that. :-) >> > >> > Sub-TLVs can be split into multiple sub-TLVs. If the parent TLV is full, >> > then parts >> > of the sub-TLV may be carried in separate instances of the parent TLV. >> > >> > In other words, the solution is fully recursive. >> > >> > T >> > >>
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
