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