Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"

[Aijun Wang]

Hi, Ketan:

What I want to say is that the mechanism described in your draft can act also 
upon the LAN interface, take the similar procedures as RFC 8500.

 

RFC 8042 has referred [OSPFV3-EXTENDED-LSA], which is the precedent document of 
RFC8362.  The text in RFC 8042 
(https://datatracker.ietf.org/doc/html/rfc8042#section-3.4) just said the 
followings:

  “Network-to-Router metric advertisement in OSPFv3 Extended Router-LSA

   [OSPFV3-EXTENDED-LSA 
 ] will 
be described in a separate document.”

But I don’t see the so-called “separate document”.

 

And, based on the discussions, I think there is no reason to differentiate the 
solution for IS-IS and OSPF on LAN interface.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org   mailto:lsr-boun...@ietf.org> > On Behalf Of Ketan Talaulikar
Sent: Sunday, April 24, 2022 6:01 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >; 
Acee Lindem (acee) mailto:a...@cisco.com> >; 
draft-ietf-lsr-ospf-reverse-met...@ietf.org 
 ; lsr mailto:lsr@ietf.org> >
Subject: Re: [Lsr] Working Group Last Call for 
draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"

 

Hi Aijun,

 

Perhaps I was not clear enough in my email. My question is - What is the 
significant difference or improvement between what you've described and the 
OSPF Two-Part Metric (RFC8042) apart from the TLV name change?

 

Is it your point that RFC8042 does not cover OSPFv3? If so, it looks like it 
was in that draft and was removed just before publication - perhaps to remove 
the dependency with RFC8362?

 

Thanks,

Ketan

 

 

On Sun, Apr 24, 2022 at 8:49 AM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Ketan:

The aim of OSPF Two-Part Metric[RFC8042] is to solve the situation that one 
router can be reached via different metrics by other routers on the same LAN, 
its application is different from the maintenance purpose(OSPF Reverse Metric) 
on one interface that connected to the LAN.

>From my POV, the possible similar procedures to solve the maintenance purposes 
>on LAN interfaces are the followings:

1. Define and put the “Reverse Metric” sub-TLV within the “Router-Link TLV” 
(  
https://datatracker.ietf.org/doc/html/rfc8362#section-3.2) (Instead of using 
LLS block)

2. The mentioned router(Router A) advertise the Router LSA to DR, with the 
“Reverse Metric” sub-TLV attached within the “Router-Link TLV”

3. The DR/BDR act upon the “Reverse Metric” sub-TLV, using the “W”-bit to 
signal whether only “to the advertising router” is changed, or the metrics to 
all routers on the LAN should be changed.

4. DRothers use the updated neighbor metric to calculate the SPF path to 
the original mentioned router(Router A), push the traffic away to the mentioned 
router(Router A)

 

Similar procedures as RFC8500. Is there any issues? 

 

Best Regards

 

Aijun Wang

China Telecom

 

From:   lsr-boun...@ietf.org < 
 lsr-boun...@ietf.org> On Behalf Of Ketan 
Talaulikar
Sent: Friday, April 22, 2022 10:10 PM
To: Aijun Wang <  wangai...@tsinghua.org.cn>
Cc: Les Ginsberg (ginsberg) <  ginsb...@cisco.com>; 
Acee Lindem (acee) <  a...@cisco.com>;  
 
draft-ietf-lsr-ospf-reverse-met...@ietf.org; lsr <  
lsr@ietf.org>
Subject: Re: [Lsr] Working Group Last Call for 
draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"

 

Hi Aijun,

 

Please check inline below.

 

 

On Fri, Apr 22, 2022 at 8:57 AM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Ketan and Acee:

I have not seen there is any other possible application of the “Reverse Metric” 
mechanism, except that are described in RFC8500.

There is no additional value to repeat to illustrate them, refer to them is 
enough.

 

KT> I am considering this as an editorial comment. As explained by me and also 
confirmed by Acee, there are significant differences in the applicability of 
the use-cases given that the OSPF reverse metric does not apply for the LAN. 
That said, we (authors) will be posting an update next week to address the 
comments received and I believe they will partially incorporate your feedback.

 

 

The “W” bit in RFC8500 is useful in LAN environment and I have said that there 
is no technical issue to apply the “Reverse Metric” mechanism to LAN 
environment. 

>From my POV, such solution is more straightforward than the 2-part metric 
>based solution.

 

KT> The OSPF reverse metric cannot be applied to LAN similar to how it is done 
in ISIS due to some fundamental differences between the 

Re: [Lsr] WG adoption call for draft-fox-lsr-ospf-terminology-01

[Mike Fox]

I am also not aware of any IPR that may apply to this draft.

From: Alvaro Retana 
Date: Monday, April 25, 2022 at 9:58 AM
To: lsr@ietf.org , Christian Hopps 
Cc: draft-fox-lsr-ospf-terminol...@ietf.org 
, cho...@chopps.org 
Subject: [EXTERNAL] Re: WG adoption call for draft-fox-lsr-ospf-terminology-01
HI! I am not aware on any IPR that may apply to this draft. Thanks! Alvaro. On 
April 25, 2022 at 9:50:54 AM, Christian Hopps (cho...@chopps.org) wrote: Hi 
Folks, This begins a 2 week WG Adoption Call for the following draft: ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
HI!

I am not aware on any IPR that may apply to this draft.

Thanks!

Alvaro.


On April 25, 2022 at 9:50:54 AM, Christian Hopps 
(cho...@chopps.org) wrote:
Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-fox-lsr-ospf-terminology/

Please indicate your support or objections by May 9th, 2022.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to these drafts.

Thanks,
Chris.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] The LSR WG has placed draft-fox-lsr-ospf-terminology in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The LSR WG has placed draft-fox-lsr-ospf-terminology in state
Call For Adoption By WG Issued (entered by Christian Hopps)

The document is available at
https://datatracker.ietf.org/doc/draft-fox-lsr-ospf-terminology/


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-fox-lsr-ospf-terminology-01

[Acee Lindem (acee)]

I'm not aware of any IPR. 
Thanks,
Acee

On 4/25/22, 9:51 AM, "Lsr on behalf of Christian Hopps"  wrote:

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-fox-lsr-ospf-terminology/

Please indicate your support or objections by May 9th, 2022.

Authors, please respond to the list indicating whether you are aware of any 
IPR that applies to these drafts.

Thanks,
Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-fox-lsr-ospf-terminology-01

[Alvaro Retana]

HI!

I am not aware on any IPR that may apply to this draft.

Thanks!

Alvaro.


On April 25, 2022 at 9:50:54 AM, Christian Hopps 
(cho...@chopps.org) wrote:

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-fox-lsr-ospf-terminology/

Please indicate your support or objections by May 9th, 2022.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to these drafts.

Thanks,
Chris.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] WG adoption call for draft-fox-lsr-ospf-terminology-01

[Christian Hopps]

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-fox-lsr-ospf-terminology/

Please indicate your support or objections by May 9th, 2022.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to these drafts.

Thanks,
Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr