Hi Jie,
Regarding your point (2), my understanding is that this feature applies to
OSPF cost (i.e., IGP metric) and as an extension is applicable to both the
"base" SPF as well as any SPF computation (including FlexAlgo) that uses
IGP metric. You are right, that the draft should clarify this.
Hi Yingzhen,
I’ve read the latest version of this document and support its adoption. It is
a useful feature in general to exclude some of the links from SPF computation.
I also have some comments for the authors to consider, they can be solved after
the adoption.
1. I’m not sure the
Support the adoption of this draft.
Thanks,
Sandy
Original
From: YingzhenQu
To: lsr ;lsr-chairs ;
Date: 2024年02月23日 13:28
Subject: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link
(02/23/24 - 03/08/24)
___
Lsr mailing list
Hi Liyan,
My email below brings out two aspects. You have responded to (b) but are
silent on (a).
On (b), what the authors are proposing is a change in semantics of an
existing term MaxLinkMetric (as proposed by 6987/8770) and introducing new
term MaxUsableLinkMetric with the same meaning as
Hi WG,
I support the adoption of this draft as co-author.
In some scenarios(For details, see section 2), it is very necessary to
advertise unreachable links in OSPF.
Best Regards,
Ran
Original
From: YingzhenQu
To: lsr ;lsr-chairs ;
Date: 2024年02月23日 13:28
Subject: [Lsr] WG Adoption Call -
Reviewer: Reese Enghardt
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For
Reviewer: Ines Robles
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For
Hi Mike,
> On Feb 28, 2024, at 11:59, Mike Fox wrote:
>
> Section 21.4.2 of RFC 2328 has a couple of seemingly contradictory statements
> I am trying to reconcile.
>
> It says that a network LSA is only originated by the DR if the DR is fully
> adjacent to at least one other router, and
Hi Tony,
> On Feb 28, 2024, at 2:01 AM, Tony Przygienda wrote:
>
> hey Acee, inline
>
>
> On Wed, Feb 28, 2024 at 3:30 AM Acee Lindem wrote:
> Hi Tony,
>
> Thanks for the review.
>
>> On Feb 27, 2024, at 04:51, Tony Przygienda wrote:
>>
>> Reading the draft quickly, here's bunch of
Section 21.4.2 of RFC 2328 has a couple of seemingly contradictory statements I
am trying to reconcile.
It says that a network LSA is only originated by the DR if the DR is fully
adjacent to at least one other router, and it includes itself in the list of
fully adjacent routers.
But it also
Hi Yao,
There is one comment for you to consider.
In the last paragraph of Chapter Four, it discusses whether oversized packets
can be avoided from being discarded or sent to the control plane.
In my view the key point depends on whether this extension is applied to
routing calculations.
Hi Ketan,
Thank you very much for your comments. I39m trying to understand your point.
The core idea is to differentiate between these two values, 0x and 0xfffe.
One represents unreachable, and the other signifies the maximum value (cannot
transmit traffic).
Based on Acee39s
12 matches
Mail list logo