On second thought, we have MSD in a YANG model now and these are very hard to change. I now think that we shouldn't overload the current MSD. If we do agree that this aggregate header length (AGL) is necessary then we can come up with something that is more generic and encompasses AGL.
Thanks, Acee > On Aug 14, 2024, at 10:26 AM, Alvaro Retana <[email protected]> wrote: > > Hi! > > IMHO, we don’t need to formally update all those other documents — maybe just > the one that initially defined the term. The important thing here is that it > can be done with a single document: the other documents wouldn’t need to be > republished. > > Alvaro. > > On August 14, 2024 at 5:32:32 AM, [email protected] ([email protected]) > wrote: >> >> >> Hi Acee, >> If the meaning of MSD is expanded to "Maximum State Depth" or something >> else, the existing RFCs(e.g, RFC8664/RFC8491/RFC8476) which already >> interpret MSD as Maximum SID Depth in the text would be effected. >> All of them needs a update if doing so? >> >> Yao >> >> Original >> From: AceeLindem <[email protected]> >> To: 刘尧00165286; >> Cc: [email protected] <[email protected]>;[email protected] >> <[email protected]>;[email protected] >> <[email protected]>;[email protected] <[email protected]>; >> Date: 2024年08月13日 22:49 >> Subject: [spring] Re: following-up discussion on >> draft-liu-spring-aggregate-header-limit-problem >> _______________________________________________ >> spring mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> Perhaps, maximum it could be generalized to “Maximum State Depth” with the >> existing types. >> Acee >> >>> On Aug 13, 2024, at 05:27, <[email protected]> <[email protected]> >>> wrote: >>> >>> Hi Jeff, >>> >>> Yes, strictly speaking, the meaning of some existing MSD types do not fully >>> conform to the original “Maximum SID Depth” definition (but it has to be >>> admitted that all of them are related to the number of SIDs/labels to some >>> extend), and we're using them without misunderstanding. >>> >>> Thanks, >>> Yao >>> >>> >>> _______________________________________________ >>> spring mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >> >> From: JeffTantsura <[email protected]> >> To: 刘尧00165286; >> Cc: Eric Vyncke (evyncke) <[email protected]>;Alexander Vainshtein >> <[email protected]>;spring <[email protected]>; >> Date: 2024年08月13日 04:19 >> Subject: [spring] Re: following-up discussion on >> draft-liu-spring-aggregate-header-limit-problem >> _______________________________________________ >> spring mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> Hi Yao, >> I think as long as the new type name is coherent, MSD could be used as a >> generic acronym without much harm. >> I don’t see any ambiguity with the new MSD-types defined - >> https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-msd-types >> >> Thanks, >> Jeff >> >>> On Aug 1, 2024, at 17:35, [email protected] wrote: >>> >>> Hi Eric, Jeff and Sasha, >>> >>> Thank you all for the interest and comments on >>> draft-liu-spring-aggregate-header-limit-problem during the presentation on >>> last week's SPRING meeting. >>> Here're the following-up responses to the comments and some related >>> information on this work. >>> >>> Comments from Eric: >>> Refering to RFC9098 instead of RFC8883 on aggregate header limit. >>> Response: >>> We've checked RFC9098 after the meeting, but haven't found any formal >>> description on aggregate header limit. So we still have to refer to RFC8883 >>> when it comes to the definition of aggregate header limit. But RFC9098 >>> provides some detailed information on intermediate systems processing Layer >>> 4 information, in this case it needs process the entire IPv6 header chain >>> as well. We'll add RFC9098 as a reference for this scenario. >>> >>> Comments from Jeff&Sasha: >>> MSD(IGP/BGP/YANG) has provided a mechanism for node's processing limit info >>> advertisement and collection, and it is well defined, a new MSD type for >>> AHL or similar mechanism can meet the requirement. >>> Response: >>> In fact, we've already written a draft >>> draft-liu-lsr-aggregate-header-limit, and the basic idea is defining a new >>> MSD type so the existing mechanism for MSD can all be leveraged. >>> It has been discussed on the LSR list and presented in LSR IETF119, but the >>> objection of this approach is that, AHL is a none-routing info, it should >>> not be advertised along with the route advertisement like MSD(although MSD >>> already did that). A suggestion is to leverage the non-routing information >>> signaling mechanism in IGP (draft-ietf-lsr-ospf-transport-instance, >>> RFC6823) for AHL advertisement. >>> You can find the discussion around the this draft in the lsr minutes >>> [https://datatracker.ietf.org/doc/minutes-119-lsr-202403210300/#signaling-aggregate-header-size-limit-via-igp] >>> and the chatlog >>> [https://datatracker.ietf.org/doc/chatlog-119-lsr-202403211300/] on >>> IETF119. >>> >>> >>> Thanks, >>> Yao >>> >>> >>> >>> >> >> >> _______________________________________________ >> spring mailing list -- [email protected] >> To unsubscribe send an email to [email protected] _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
