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 <acee.i...@gmail.com>
To: 刘尧00165286;
Cc: jefftant.i...@gmail.com <jefftant.i...@gmail.com>;evyn...@cisco.com
<evyn...@cisco.com>;alexander.vainsht...@rbbn.com
<alexander.vainsht...@rbbn.com>;spring@ietf.org <spring@ietf.org>;
Date: 2024年08月13日 22:49
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
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
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
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]
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
