[spring] Re: following-up discussion on draft-liu-spring-aggregate-header-limit-problem

[[e-mail]]

Hi Acee and Jeff,

Thanks for the comments!
The next step is to take the problem statement to 6MAN following Alvaro's suggestions. Once there's a consensus on the AHL problem in 6MAN, we can focus on promoting the protocol extensions in LSR. 
A new MSD type seems to be the most direct way, but it may cause some confusion since the name and content are not completely consistent. Will work on this and see how to reach a consensus. 

Yao


Original


From: JeffTantsura <[e-mail]>
To: Acee Lindem <[e-mail]>;
Cc: 刘尧00165286;Éric Vyncke <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年08月06日 01:58
Subject: [spring] Re: following-up discussion on draft-liu-spring-aggregate-header-limit-problem

Second what Acee said, and the name indeed could have been better (it seemed fine when we started working on MSD). We already have a framework that spans both IGPs and BGP-LS, defining a new MSD would be a more pragmatic approach.
Cheers,
Jeff

On Aug 2, 2024, at 06:57, Acee Lindem <[e-mail]> wrote:



Speaking as an LSR WG Member:
On Aug 1, 2024, at 20:35, <[e-mail]> <[e-mail]> 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.



I know this was said at the WG meeting but I disagree. We already have MSD signaling in the IGPs and this would be yet another MSD type. Also, I could imagine use cases where it is used for route selection similar to the other MSD types.  The reason (other than our backlog of drafts) that we didn’t do an LSR adopt call was due to the lack of precise definition of AHL as well as the intended use cases.  

Thanks,
Acee





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 -- [e-mail]
To unsubscribe send an email to [e-mail]