Perhaps, maximum it could be generalized to “Maximum State Depth” with the existing types.
Acee > On Aug 13, 2024, at 05:27, <liu.ya...@zte.com.cn> <liu.ya...@zte.com.cn> > 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 > > > > Original > From: JeffTantsura <jefftant.i...@gmail.com> > To: 刘尧00165286; > Cc: Eric Vyncke (evyncke) <evyn...@cisco.com>;Alexander Vainshtein > <alexander.vainsht...@rbbn.com>;spring <spring@ietf.org>; > Date: 2024年08月13日 04:19 > Subject: [spring] Re: following-up discussion on > draft-liu-spring-aggregate-header-limit-problem > _______________________________________________ > spring mailing list -- spring@ietf.org > To unsubscribe send an email to spring-le...@ietf.org > 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, liu.ya...@zte.com.cn 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>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 -- spring@ietf.org > To unsubscribe send an email to spring-le...@ietf.org
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
