Hi Acee,
Thanks for your quick response. On the point (1), there are actually two
aspects:
a) The name of the capability itself - "MaxLinkMetric support" seems odd to
me since all implementations do support setting this metric value already.
Perhaps "UnreachableLinkMetric support" (or something l
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 observations
>
> "
>
>An OSPF router supporting this specification MUST be able to
Hi Tony,
Thanks for the review.
> On Feb 27, 2024, at 04:51, Tony Przygienda wrote:
>
> Reading the draft quickly, here's bunch of observations
>
> "
>
>An OSPF router supporting this specification MUST be able to
>advertise and interpret at least one 32-bit tag for all type of
>
Hi Ketan,
> On Feb 27, 2024, at 08:16, Ketan Talaulikar wrote:
>
> Hello,
>
> I support the adoption of this document by the WG since it is a useful OSPF
> protocol extension.
>
> I have the following comments for the authors to consider (post adoption):
>
> 1) Suggest to rename the capabil
Hello,
I support the adoption of this document by the WG since it is a useful OSPF
protocol extension.
I have the following comments for the authors to consider (post adoption):
1) Suggest to rename the capability bit to UnreachableLinkMetric to clearly
distinguish it from all previous use of Ma
Reading the draft quickly, here's bunch of observations
"
An OSPF router supporting this specification MUST be able to
advertise and interpret at least one 32-bit tag for all type of
prefixes. An OSPF router supporting this specification MAY be able
to advertise and propagate multipl
Hi WG & Chairs
I support the adoption of this draft.
Best Wishes.
发件人: Lsr mailto:lsr-boun...@ietf.org>> 代表 Yingzhen Qu
发送时间: 2024年2月23日 13:28
收件人: lsr mailto:lsr@ietf.org>>; lsr-chairs
mailto:lsr-cha...@ietf.org>>
主题: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24
