Re: [Lsr] [Pce] Paul Wouters' No Objection on draft-ietf-lsr-pce-discovery-security-support-12: (with COMMENT)

[Dhruv Dhody]

Hi Paul,

On Tue, Oct 11, 2022 at 6:35 AM Paul Wouters via Datatracker <
nore...@ietf.org> wrote:

> Paul Wouters has entered the following ballot position for
> draft-ietf-lsr-pce-discovery-security-support-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/
>
>
>
> --
> COMMENT:
> --
>
> A receiving entity MUST NOT interpret invalid UTF-8 sequences.
>
> What must it do then, when encountering invalid UTF-8 ?
>
>
>
Ignore them! I can make that explicit in the text!



> In any case, an implementation SHOULD [...]
>
> So not in ANY case then? :-)
>
>
removed "in any case,"!



> nits:
> 1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|  Type = 6 | Length|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|KeyID  | Reserved  |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   Type: 6
>
>   Length: 4
>
>
> Why does it not say "Length = 4" like it says "Type = 6"  ?
>

It is the usual practice in the base documents (see RFC 5088) as well as
most published RFCs for LSR.

Thanks!
Dhruv



>
>
>
> ___
> Pce mailing list
> p...@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] RFC 8362 and LSInfinity

[Peter Psenak]

Aijun,

On 11/10/2022 05:44, Aijun Wang wrote:

Hi, Peter:

Let's focus on OSPF itself then.

In OSPFv2(RFC2328) and OSPFv3(RFC5340), the metric length for the link or 
intra-area prefix is 16 bit; but the metric length for the summary 
LSA/inter-area is 24bit.
There will be no problem to define the LSInfinity for the summary LSA as 
0xFF( although the usages of such definition is doubtful and should be 
revaluatedfor example, is there any real deployment for the mentioned 
possible usages?)

But for OSPFv3(RFC8362), if you still define the LSInifiity as 0xFF, there 
is possible the cost to some prefixes advertised by the ABR reach this value, 
it is unreasonable to consider such prefixes are unreachable.  Then, rely on 
such value of the metric to determine the reachability is problematic.


again, there is no problem. For RFC8362 0xFF already means 
LSInfinity for inter/external prefixes. All we propose is to define the 
same meaning for that metric for intra-area prefixes as it is 24 bits as 
well.


Peter



We should decrease or abandon such unsound reliance.

It is easy for the device to implement such special treatment, it is difficult 
and complex for the operator to run the network based on such special treatment.


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Peter Psenak
Sent: Monday, October 10, 2022 3:56 PM
To: Aijun Wang ; 'Acee Lindem (acee)' 
; 'Ketan Talaulikar' ; 'Peter 
Psenak' 
Cc: lsr@ietf.org
Subject: Re: [Lsr] RFC 8362 and LSInfinity

Aijun,

On 09/10/2022 07:44, Aijun Wang wrote:

Hi, Acee, Peter and Ketan:

I propose we limit the usage of LSInfinity within the network. That is
to say, we should depreciate its usages, not enhance it.

As defined in RFC2328, the sole purpose of LSInfinity is to let the
receiver bypass the SPF calculation for the associated LSA:

a)In case the advertisement of LSA for some special aim.

b)Another is for the premature aging the LSA (which is not encouraged).

There is few application for the a) usage until now, same situation
for
b) usage.


definition of LSInfinity is very exact - it means unreachability.



The reason for the above situations may be the definition within the
RFC2328 is counterintuitivethe maximum value of the metric should
be used for the last resort of the reachability, no other more
meanings. Or else, it will complex the implementation and deployment, for 
example:

a)For OSPFv2, the LSInfinity is defined as 0xff

b)For IS-IS, the equivalent variable is MAX_PATH_METRIC, which is
defined as 0xFE00


you are comparing apples to oranges. These are two different protocols.



c)For OSPFv3, which value will you be defined, especially for the
Intra-Area-Prefix? Considering the metric for the intra-area and
inter-area are all 24-bit long?


OSPFv3 inherits all the constants defined for OSPFv2, it's explicitly mentioned 
in the OSPFv3 RFC. And LSInfinity is 24 bits long.



d)And, for the metric in ”IP Algorithm Prefix Reachability” ,
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.3 
, 
its length is again 32-bit, will you define another LSInfinity value later?


0x seems like a good candidate for the unreachable metric for the IP 
flex-algo.



Won’t you think the above special rule complex the whole situation?


not at all.



I think we should seek other methods to achieve the necessary goals.


I do not see a problem

thanks,
Peter


Best Regards

Aijun Wang

China Telecom

*From:* lsr-boun...@ietf.org  *On Behalf Of
*Acee Lindem (acee)
*Sent:* Saturday, October 8, 2022 4:03 AM
*To:* Ketan Talaulikar ; Peter Psenak

*Cc:* lsr@ietf.org
*Subject:* Re: [Lsr] RFC 8362 and LSInfinity

Hi Peter, Ketan,

We’ll do another WG last call on the updated IP Flex Algo document and
it will update RFC 8362. As you probably surmised, this is useful for
OSPFv3 IP Flex Algorithm when you want don’t want to use the prefix
with the base algorithm.

*From: *Lsr mailto:lsr-boun...@ietf.org>> on
behalf of Ketan Talaulikar mailto:ketant.i...@gmail.com>>
*Date: *Thursday, October 6, 2022 at 3:35 AM
*To: *Peter Psenak mailto:ppsenak=40cisco@dmarc.ietf.org>>
*Cc: *"lsr@ietf.org " mailto:lsr@ietf.org>>
*Subject: *Re: [Lsr] RFC 8362 and LSInfinity

Hi Peter,

I support this "update" - not sure if it qualifies as a "clarification".
Also, this obviously is doable only when the network has migrated to
use only Extended LSAs (i.e., legacy LSAs are removed) as indicated in
https://www.rfc-editor.org/rfc/rfc8362.html#section-6.1


In sparse-mode, the legacy LSAs are used. So if you want a prefix to
be unreachable with the base algorithm, simply omit it from the legacy
Intra-Area-Prefix LSA.

Thanks,
Acee

Thanks,

Ketan

On Wed, Oct 5, 2022 at 3:01 PM Peter Psenak

Re: [Lsr] RFC 8362 and LSInfinity

[Aijun Wang]

Hi, Peter:

Let's focus on OSPF itself then. 

In OSPFv2(RFC2328) and OSPFv3(RFC5340), the metric length for the link or 
intra-area prefix is 16 bit; but the metric length for the summary 
LSA/inter-area is 24bit.
There will be no problem to define the LSInfinity for the summary LSA as 
0xFF( although the usages of such definition is doubtful and should be 
revaluatedfor example, is there any real deployment for the mentioned 
possible usages?)

But for OSPFv3(RFC8362), if you still define the LSInifiity as 0xFF, there 
is possible the cost to some prefixes advertised by the ABR reach this value, 
it is unreasonable to consider such prefixes are unreachable.  Then, rely on 
such value of the metric to determine the reachability is problematic.

We should decrease or abandon such unsound reliance.

It is easy for the device to implement such special treatment, it is difficult 
and complex for the operator to run the network based on such special treatment.


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Peter Psenak
Sent: Monday, October 10, 2022 3:56 PM
To: Aijun Wang ; 'Acee Lindem (acee)' 
; 'Ketan Talaulikar' ; 
'Peter Psenak' 
Cc: lsr@ietf.org
Subject: Re: [Lsr] RFC 8362 and LSInfinity

Aijun,

On 09/10/2022 07:44, Aijun Wang wrote:
> Hi, Acee, Peter and Ketan:
> 
> I propose we limit the usage of LSInfinity within the network. That is 
> to say, we should depreciate its usages, not enhance it.
> 
> As defined in RFC2328, the sole purpose of LSInfinity is to let the 
> receiver bypass the SPF calculation for the associated LSA:
> 
> a)In case the advertisement of LSA for some special aim.
> 
> b)Another is for the premature aging the LSA (which is not encouraged).
> 
> There is few application for the a) usage until now, same situation 
> for
> b) usage.

definition of LSInfinity is very exact - it means unreachability.

> 
> The reason for the above situations may be the definition within the
> RFC2328 is counterintuitivethe maximum value of the metric should 
> be used for the last resort of the reachability, no other more 
> meanings. Or else, it will complex the implementation and deployment, for 
> example:
> 
> a)For OSPFv2, the LSInfinity is defined as 0xff
> 
> b)For IS-IS, the equivalent variable is MAX_PATH_METRIC, which is 
> defined as 0xFE00

you are comparing apples to oranges. These are two different protocols.

> 
> c)For OSPFv3, which value will you be defined, especially for the 
> Intra-Area-Prefix? Considering the metric for the intra-area and 
> inter-area are all 24-bit long?

OSPFv3 inherits all the constants defined for OSPFv2, it's explicitly mentioned 
in the OSPFv3 RFC. And LSInfinity is 24 bits long.

> 
> d)And, for the metric in ”IP Algorithm Prefix Reachability” ,
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.3 
> ,
>  its length is again 32-bit, will you define another LSInfinity value later?

0x seems like a good candidate for the unreachable metric for the IP 
flex-algo.

> 
> Won’t you think the above special rule complex the whole situation?

not at all.

> 
> I think we should seek other methods to achieve the necessary goals.

I do not see a problem

thanks,
Peter
> 
> Best Regards
> 
> Aijun Wang
> 
> China Telecom
> 
> *From:* lsr-boun...@ietf.org  *On Behalf Of 
> *Acee Lindem (acee)
> *Sent:* Saturday, October 8, 2022 4:03 AM
> *To:* Ketan Talaulikar ; Peter Psenak 
> 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] RFC 8362 and LSInfinity
> 
> Hi Peter, Ketan,
> 
> We’ll do another WG last call on the updated IP Flex Algo document and 
> it will update RFC 8362. As you probably surmised, this is useful for
> OSPFv3 IP Flex Algorithm when you want don’t want to use the prefix 
> with the base algorithm.
> 
> *From: *Lsr mailto:lsr-boun...@ietf.org>> on 
> behalf of Ketan Talaulikar  >
> *Date: *Thursday, October 6, 2022 at 3:35 AM
> *To: *Peter Psenak  >
> *Cc: *"lsr@ietf.org "  >
> *Subject: *Re: [Lsr] RFC 8362 and LSInfinity
> 
> Hi Peter,
> 
> I support this "update" - not sure if it qualifies as a "clarification". 
> Also, this obviously is doable only when the network has migrated to 
> use only Extended LSAs (i.e., legacy LSAs are removed) as indicated in
> https://www.rfc-editor.org/rfc/rfc8362.html#section-6.1
> 
> 
> In sparse-mode, the legacy LSAs are used. So if you want a prefix to 
> be unreachable with the base algorithm, simply omit it from the legacy 
> Intra-Area-Prefix LSA.
> 
> Thanks,
> Acee
> 
> Thanks,
> 
> Ketan
> 
> On Wed, Oct 5, 2022 at 3:01 PM Peter Psenak 
>  >
> wrote:
> 
> Hi Folks,
> 
> metric of LSInfinity (0xFF) has 

[Lsr] Paul Wouters' No Objection on draft-ietf-lsr-pce-discovery-security-support-12: (with COMMENT)

[Paul Wouters via Datatracker]

Paul Wouters has entered the following ballot position for
draft-ietf-lsr-pce-discovery-security-support-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/



--
COMMENT:
--

A receiving entity MUST NOT interpret invalid UTF-8 sequences.

What must it do then, when encountering invalid UTF-8 ?


In any case, an implementation SHOULD [...]

So not in ANY case then? :-)

nits:
1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 6 | Length|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |KeyID  | Reserved  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Type: 6

  Length: 4


Why does it not say "Length = 4" like it says "Type = 6"  ?



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

Re: [Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-ospf-reverse-metric-12: (with COMMENT)

[Murray S. Kucherawy]

Thanks!

On Mon, Oct 10, 2022 at 10:29 AM Ketan Talaulikar 
wrote:

> Hi Murray,
>
> This update includes the changes we discussed below:
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-13
>
> Thanks,
> Ketan
>
>
> On Mon, Oct 10, 2022 at 10:45 PM Ketan Talaulikar 
> wrote:
>
>> Hi Murray,
>>
>> Thanks for your review and please find below responses inline.
>>
>> These changes will be reflected in the upcoming update for the document.
>>
>>
>> On Mon, Oct 10, 2022 at 9:37 PM Murray Kucherawy via Datatracker <
>> nore...@ietf.org> wrote:
>>
>>> Murray Kucherawy has entered the following ballot position for
>>> draft-ietf-lsr-ospf-reverse-metric-12: No Objection
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to
>>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>>> for more information about how to handle DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/
>>>
>>>
>>>
>>> --
>>> COMMENT:
>>> --
>>>
>>> Apologies for being late to the party.  Just a few things to add beyond
>>> the
>>> feedback my colleagues have already provided:
>>>
>>> The first sentence in Section 2.2 uses the phrase "toward the core" three
>>> times.  Seems like it could do with some common factoring.
>>>
>>
>> KT> Updated.
>>
>>
>>>
>>> There's a SHOULD at the bottom of Section 6.  Why's it only a SHOULD?
>>> When
>>> might an implementer legitimately decide to do something else?
>>>
>>
>> KT> Thanks for catching that. Based on discussion with Alvaro, I changed
>> the SHOULD to a qualified MUST earlier in section 6 related to the reverse
>> metric but missed making a similar change for the TE reverse metric.
>>
>>
>>>
>>> In Section 9, I suggest making it explicit that you're talking about the
>>> "Link
>>> Local Signalling TLV Identifiers" registry in the "Open Shortest Path
>>> First
>>> (OSPF) Link Local Signalling (LLS) - Type/Length/Value Identifiers (TLV)"
>>> registry group.
>>>
>>
>> KT> Fixed.
>>
>> Thanks,
>> Ketan
>>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Protocol Action: 'OSPF Reverse Metric' to Proposed Standard (draft-ietf-lsr-ospf-reverse-metric-13.txt)

[The IESG]

The IESG has approved the following document:
- 'OSPF Reverse Metric'
  (draft-ietf-lsr-ospf-reverse-metric-13.txt) as Proposed Standard

This document is the product of the Link State Routing Working Group.

The IESG contact persons are Alvaro Retana, Andrew Alston and John Scudder.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/





Technical Summary

This document provides extensions to OSPF to support dynamic modification of
link metrics by ingress router on the link. In other words, an OSPF router can
request an adjacent OSPF router to advertise a higher link metric.

Working Group Summary

Given that the draft is implementing function already supported for IS-IS with
RFC 8500, there wasn't a lot of excitement over the draft. During the WG last
call, a number of WG members the draft with the only issue being the
predominant use cases. The draft is generally supported.

Document Quality

The document describes a relatively simple OSPF extension and is analogous to
similar function in IS-IS (RFC 8500). It is of high quality and ready for
publication.

Personnel

 Document Shepherd: Acee Lindem
 Responsible AD: John Scudder

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

Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

[John Scudder]

Hi Lars,

There has been considerable discussion about the WG’s reason for structuring 
the document this way, and helpful updates made to the current document. I 
think we can conclude, or at least I conclude, that this was done with 
considered intent and for good reasons.

Do you feel your DISCUSS has been addressed?

Thanks,

—John

> On Sep 30, 2022, at 8:27 AM, Lars Eggert via Datatracker  
> wrote:
> 
> Lars Eggert has entered the following ballot position for
> draft-ietf-lsr-pce-discovery-security-support-11: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt8J-BPa3$
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt2I779yk$
> 
> 
> 
> --
> DISCUSS:
> --
> 
> # GEN AD review of draft-ietf-lsr-pce-discovery-security-support-11
> 
> CC @larseggert
> 
> ## Discuss
> 
> ### Section 4, paragraph 3
> ```
> Section 4 of [RFC5088] states that no new sub-TLVs will be added to
> the PCED TLV, and no new PCE information will be carried in the
> Router Information LSA.  This document updates [RFC5088] by allowing
> the two sub-TLVs defined in this document to be carried in the PCED
> TLV advertised in the Router Information LSA.
> 
> Section 4 of [RFC5089] states that no new sub-TLVs will be added to
> the PCED TLV, and no new PCE information will be carried in the
> Router CAPABLITY TLV.  This document updates [RFC5089] by allowing
> the two sub-TLVs defined in this document to be carried in the PCED
> TLV advertised in the Router CAPABILITY TLV.
> 
> This introduction of additional sub-TLVs should be viewed as an
> exception to the [RFC5088][RFC5089] policy, justified by the
> requirement to discover the PCEP security support prior to
> establishing a PCEP session.  The restrictions defined in
> [RFC5089][RFC5089] should still be considered to be in place.
> ```
> (This is mostly for discussion on the telechat, and I expect to clear
> during the call.)
> 
> Why were 5088/89 so strict on not allowing new sub-TLVs? This seems
> quite unusual for IETF specs. I'm not arguing that this document
> can't update those earlier RFCs to allow these new sub-TLVs, but it
> seems odd to do so and in the same sentence say "the restrictions
> should still be considered in place."
> 
> ### Section 8.2, paragraph 1
> ```
> The PCED sub-TLVs were defined in [RFC5088] and [RFC5089], but they
> did not create a registry for it.  This document requests IANA to
> create a new registry called "PCED sub-TLV type indicators" under the
> "Interior Gateway Protocol (IGP) Parameters" grouping.  The
> registration policy for this registry is "IETF Review" [RFC8126].
> Values in this registry come from the range 0-65535.
> ```
> Should the registration policy not be stricter (e.g., Standards
> Action?) given that 5088/89 didn't even allow any new values?
> 
> 
> --
> COMMENT:
> --
> 
> ## Comments
> 
> ### Inclusive language
> 
> Found terminology that should be reviewed for inclusivity; see
> https://urldefense.com/v3/__https://www.rfc-editor.org/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt1fwrlFS$
>for background and more
> guidance:
> 
> * Term `master`; alternatives might be `active`, `central`, `initiator`,
>   `leader`, `main`, `orchestrator`, `parent`, `primary`, `server`
> * Term `man`; alternatives might be `individual`, `people`, `person`
> 
> ## Nits
> 
> All comments below are about very minor potential issues that you may choose 
> to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via 
> https://urldefense.com/v3/__https://github.com/larseggert/ietf-reviewtool__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjtxqHvOEf$
>   ), so there
> will likely be some false positives. There is no need to let me know what you
> did with these suggestions.
> 
> ### URLs
> 
> These URLs in the document can probably be converted to HTTPS:
> 
> * 
> 

Re: [Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-ospf-reverse-metric-12: (with COMMENT)

[Ketan Talaulikar]

Hi Murray,

This update includes the changes we discussed below:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-13

Thanks,
Ketan


On Mon, Oct 10, 2022 at 10:45 PM Ketan Talaulikar 
wrote:

> Hi Murray,
>
> Thanks for your review and please find below responses inline.
>
> These changes will be reflected in the upcoming update for the document.
>
>
> On Mon, Oct 10, 2022 at 9:37 PM Murray Kucherawy via Datatracker <
> nore...@ietf.org> wrote:
>
>> Murray Kucherawy has entered the following ballot position for
>> draft-ietf-lsr-ospf-reverse-metric-12: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to
>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> Apologies for being late to the party.  Just a few things to add beyond
>> the
>> feedback my colleagues have already provided:
>>
>> The first sentence in Section 2.2 uses the phrase "toward the core" three
>> times.  Seems like it could do with some common factoring.
>>
>
> KT> Updated.
>
>
>>
>> There's a SHOULD at the bottom of Section 6.  Why's it only a SHOULD?
>> When
>> might an implementer legitimately decide to do something else?
>>
>
> KT> Thanks for catching that. Based on discussion with Alvaro, I changed
> the SHOULD to a qualified MUST earlier in section 6 related to the reverse
> metric but missed making a similar change for the TE reverse metric.
>
>
>>
>> In Section 9, I suggest making it explicit that you're talking about the
>> "Link
>> Local Signalling TLV Identifiers" registry in the "Open Shortest Path
>> First
>> (OSPF) Link Local Signalling (LLS) - Type/Length/Value Identifiers (TLV)"
>> registry group.
>>
>
> KT> Fixed.
>
> Thanks,
> Ketan
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] I-D Action: draft-ietf-lsr-ospf-reverse-metric-13.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : OSPF Reverse Metric
Authors : Ketan Talaulikar
  Peter Psenak
  Hugh Johnston
  Filename: draft-ietf-lsr-ospf-reverse-metric-13.txt
  Pages   : 13
  Date: 2022-10-10

Abstract:
   This document specifies the extensions to OSPF that enable a router
   to use link-local signaling to signal the metric that receiving OSPF
   neighbor(s) should use for a link to the signaling router.  The
   signaling of this reverse metric, to be used on the link to the
   signaling router, allows a router to influence the amount of traffic
   flowing towards itself and in certain use cases enables routers to
   maintain symmetric metrics on both sides of a link between them.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-reverse-metric-13


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

Re: [Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-ospf-reverse-metric-12: (with COMMENT)

[Ketan Talaulikar]

Hi Murray,

Thanks for your review and please find below responses inline.

These changes will be reflected in the upcoming update for the document.


On Mon, Oct 10, 2022 at 9:37 PM Murray Kucherawy via Datatracker <
nore...@ietf.org> wrote:

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-lsr-ospf-reverse-metric-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/
>
>
>
> --
> COMMENT:
> --
>
> Apologies for being late to the party.  Just a few things to add beyond the
> feedback my colleagues have already provided:
>
> The first sentence in Section 2.2 uses the phrase "toward the core" three
> times.  Seems like it could do with some common factoring.
>

KT> Updated.


>
> There's a SHOULD at the bottom of Section 6.  Why's it only a SHOULD?  When
> might an implementer legitimately decide to do something else?
>

KT> Thanks for catching that. Based on discussion with Alvaro, I changed
the SHOULD to a qualified MUST earlier in section 6 related to the reverse
metric but missed making a similar change for the TE reverse metric.


>
> In Section 9, I suggest making it explicit that you're talking about the
> "Link
> Local Signalling TLV Identifiers" registry in the "Open Shortest Path First
> (OSPF) Link Local Signalling (LLS) - Type/Length/Value Identifiers (TLV)"
> registry group.
>

KT> Fixed.

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

Re: [Lsr] Murray Kucherawy's Discuss on draft-ietf-lsr-pce-discovery-security-support-12: (with DISCUSS)

[Acee Lindem (acee)]

Hi Murray, 

On 10/10/22, 12:26 PM, "Murray Kucherawy via Datatracker"  
wrote:

Murray Kucherawy has entered the following ballot position for
draft-ietf-lsr-pce-discovery-security-support-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/



--
DISCUSS:
--

This should be simple to resolve, but it has to be clarified:

The shepherd writeup says there were IPR claims made about the document.  
The
question also asks for a summary of the resulting discussion, but the 
shepherd
writeup doesn't provide one.  Can we confirm that the discussion was had, or
some other answer to the question can be provided?

I have updated the Shepherd's report. 

Thanks,
Acee






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

[Lsr] Murray Kucherawy's Discuss on draft-ietf-lsr-pce-discovery-security-support-12: (with DISCUSS)

[Murray Kucherawy via Datatracker]

Murray Kucherawy has entered the following ballot position for
draft-ietf-lsr-pce-discovery-security-support-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/



--
DISCUSS:
--

This should be simple to resolve, but it has to be clarified:

The shepherd writeup says there were IPR claims made about the document.  The
question also asks for a summary of the resulting discussion, but the shepherd
writeup doesn't provide one.  Can we confirm that the discussion was had, or
some other answer to the question can be provided?





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

[Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-ospf-reverse-metric-12: (with COMMENT)

[Murray Kucherawy via Datatracker]

Murray Kucherawy has entered the following ballot position for
draft-ietf-lsr-ospf-reverse-metric-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/



--
COMMENT:
--

Apologies for being late to the party.  Just a few things to add beyond the
feedback my colleagues have already provided:

The first sentence in Section 2.2 uses the phrase "toward the core" three
times.  Seems like it could do with some common factoring.

There's a SHOULD at the bottom of Section 6.  Why's it only a SHOULD?  When
might an implementer legitimately decide to do something else?

In Section 9, I suggest making it explicit that you're talking about the "Link
Local Signalling TLV Identifiers" registry in the "Open Shortest Path First
(OSPF) Link Local Signalling (LLS) - Type/Length/Value Identifiers (TLV)"
registry group.



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

[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ospf-reverse-metric-12: (with COMMENT)

[Robert Wilton via Datatracker]

Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ospf-reverse-metric-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/



--
COMMENT:
--

Discuss cleared.  Thanks for accommodating my concern.



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

Re: [Lsr] Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)

[Ketan Talaulikar]

Thanks Rob.


On Mon, Oct 10, 2022 at 7:23 PM Rob Wilton (rwilton) 
wrote:

> Hi Ketan,
>
>
>
> I’ve cleared my discuss.
>
>
>
> Regards,
>
> Rob
>
>
>
>
>
> *From:* iesg  *On Behalf Of *Ketan Talaulikar
> *Sent:* 10 October 2022 14:34
> *To:* Rob Wilton (rwilton) 
> *Cc:* The IESG ;
> draft-ietf-lsr-ospf-reverse-met...@ietf.org; lsr-cha...@ietf.org;
> lsr@ietf.org; cho...@chopps.org; Acee Lindem (acee) 
> *Subject:* Re: Robert Wilton's Discuss on
> draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)
>
>
>
> Hi Rob,
>
>
>
> Please check inline below for responses with KT2 to the open comments.
>
>
>
> We have also posted an update with the changes as discussed below:
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-12
>
>
>
> On Mon, Oct 10, 2022 at 6:18 PM Rob Wilton (rwilton) 
> wrote:
>
> Hi Ketan,
>
>
>
> Please see inline …
>
>
>
> *From:* Ketan Talaulikar 
> *Sent:* 06 October 2022 12:58
> *To:* Rob Wilton (rwilton) 
> *Cc:* The IESG ;
> draft-ietf-lsr-ospf-reverse-met...@ietf.org; lsr-cha...@ietf.org;
> lsr@ietf.org; cho...@chopps.org; Acee Lindem (acee) 
> *Subject:* Re: Robert Wilton's Discuss on
> draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)
>
>
>
> Hi Rob,
>
>
>
> Thanks for your review and comments/suggestions. Please check inline below
> for responses.
>
>
>
> Will update these changes (and further changes, if required) in the next
> version once we conclude.
>
>
>
> On Thu, Oct 6, 2022 at 4:20 PM Robert Wilton via Datatracker <
> nore...@ietf.org> wrote:
>
> Robert Wilton has entered the following ballot position for
> draft-ietf-lsr-ospf-reverse-metric-09: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/
>
>
>
> --
> DISCUSS:
> --
>
> Thanks for this document.
>
> I support Alvaro's discuss.  Having read Alvaro's discuss after writing my
> ballot comments it seems to be some what closely related, but I am also
> balloting discuss because I find the operational guidelines to be unclear.
>
> (1) p 8, sec 7.  Operational Guidelines
>
>Implementations MUST NOT signal reverse metric to neighbors by
>default and MUST provide a configuration option to enable the
>signaling of reverse metric on specific links.  Implementations
>SHOULD NOT accept the RM from its neighbors by default and SHOULD
>provide a configuration option to enable the acceptance of the RM
>from neighbors on specific links.  This is to safeguard against
>inadvertent use of RM.
>
> I'm not really sure that I properly understand how this feature works from
> a
> manageability perspective.  Particularly for your first use case, when
> considering that the proposal is for per link configuration for the
> acceptance
> of RM from neighbours.  This would seem to suggest that before you can
> make use
> of reverse-metric you have to already have determined the links on the
> affected
> devices to then configure them to accept the reverse-metrics, at which
> point,
> doesn't this partially defeat the use case?
>
>
>
> KT> If the operator is using this feature, then it needs to be enabled
> first. This is a one-time/initial config.
>
>
>
> Sure.   Presumably you mean both on the devices that will transmit the RM
> and also devices that will receive them?
>
>
>
> KT2> Correct.
>
>
>
>
>
> Or is the main goal to simplify
> the coordination of changing the metric at both ends of the link at the
> same
> time?
>
>
>
> KT> Correct. The advertisement of reverse metric is applied/triggered on
> the sending side on-need basis.
>
>
>
>
> Or is the intention that during the maintenance window the operators would
> enable the "allow receipt of reverse-metrics" on all links within, say, an
> area?  If so, would hierarchical device and area specific configuration be
> more
> appropriate?  E.g., allow it to be enabled/disbaled on individual links,
> but
> also allow more coarse grained configuration.
>
>
>
> KT> I would expect the feature enablement (specifically the receiving
> part) to be on multiple hierarchical levels (instance/area/link). The RM
> value config for sending is on the link, but for some use cases, it would
> perhaps be also hierarchical.
>
>
>
> Okay, it is only the feature enablement that I am concerned with, with my
> reading of the text implying that the feature to accept RM values must
> (perhaps only) be configurable on a per interface basis.
>
>
>
> KT2> The "only" part is not 

Re: [Lsr] Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)

[Rob Wilton (rwilton)]

Hi Ketan,

I’ve cleared my discuss.

Regards,
Rob


From: iesg  On Behalf Of Ketan Talaulikar
Sent: 10 October 2022 14:34
To: Rob Wilton (rwilton) 
Cc: The IESG ; draft-ietf-lsr-ospf-reverse-met...@ietf.org; 
lsr-cha...@ietf.org; lsr@ietf.org; cho...@chopps.org; Acee Lindem (acee) 

Subject: Re: Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: 
(with DISCUSS)

Hi Rob,

Please check inline below for responses with KT2 to the open comments.

We have also posted an update with the changes as discussed below: 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-12

On Mon, Oct 10, 2022 at 6:18 PM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Hi Ketan,

Please see inline …

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: 06 October 2022 12:58
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
Cc: The IESG mailto:i...@ietf.org>>; 
draft-ietf-lsr-ospf-reverse-met...@ietf.org;
 lsr-cha...@ietf.org; 
lsr@ietf.org; cho...@chopps.org; 
Acee Lindem (acee) mailto:a...@cisco.com>>
Subject: Re: Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: 
(with DISCUSS)

Hi Rob,

Thanks for your review and comments/suggestions. Please check inline below for 
responses.

Will update these changes (and further changes, if required) in the next 
version once we conclude.

On Thu, Oct 6, 2022 at 4:20 PM Robert Wilton via Datatracker 
mailto:nore...@ietf.org>> wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ospf-reverse-metric-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/



--
DISCUSS:
--

Thanks for this document.

I support Alvaro's discuss.  Having read Alvaro's discuss after writing my
ballot comments it seems to be some what closely related, but I am also
balloting discuss because I find the operational guidelines to be unclear.

(1) p 8, sec 7.  Operational Guidelines

   Implementations MUST NOT signal reverse metric to neighbors by
   default and MUST provide a configuration option to enable the
   signaling of reverse metric on specific links.  Implementations
   SHOULD NOT accept the RM from its neighbors by default and SHOULD
   provide a configuration option to enable the acceptance of the RM
   from neighbors on specific links.  This is to safeguard against
   inadvertent use of RM.

I'm not really sure that I properly understand how this feature works from a
manageability perspective.  Particularly for your first use case, when
considering that the proposal is for per link configuration for the acceptance
of RM from neighbours.  This would seem to suggest that before you can make use
of reverse-metric you have to already have determined the links on the affected
devices to then configure them to accept the reverse-metrics, at which point,
doesn't this partially defeat the use case?

KT> If the operator is using this feature, then it needs to be enabled first. 
This is a one-time/initial config.

Sure.   Presumably you mean both on the devices that will transmit the RM and 
also devices that will receive them?

KT2> Correct.


Or is the main goal to simplify
the coordination of changing the metric at both ends of the link at the same
time?

KT> Correct. The advertisement of reverse metric is applied/triggered on the 
sending side on-need basis.


Or is the intention that during the maintenance window the operators would
enable the "allow receipt of reverse-metrics" on all links within, say, an
area?  If so, would hierarchical device and area specific configuration be more
appropriate?  E.g., allow it to be enabled/disbaled on individual links, but
also allow more coarse grained configuration.

KT> I would expect the feature enablement (specifically the receiving part) to 
be on multiple hierarchical levels (instance/area/link). The RM value config 
for sending is on the link, but for some use cases, it would perhaps be also 
hierarchical.

Okay, it is only the feature enablement that I am concerned with, with my 
reading of the text implying that the feature to accept RM values must (perhaps 
only) be configurable on a per interface basis.

KT2> The "only" part is not there. The point was that the operator needs to 
have an option for control at each link level. It does not preclude 
hierarchical config.

Re: [Lsr] Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)

[Ketan Talaulikar]

Hi Rob,

Please check inline below for responses with KT2 to the open comments.

We have also posted an update with the changes as discussed below:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-12

On Mon, Oct 10, 2022 at 6:18 PM Rob Wilton (rwilton) 
wrote:

> Hi Ketan,
>
>
>
> Please see inline …
>
>
>
> *From:* Ketan Talaulikar 
> *Sent:* 06 October 2022 12:58
> *To:* Rob Wilton (rwilton) 
> *Cc:* The IESG ;
> draft-ietf-lsr-ospf-reverse-met...@ietf.org; lsr-cha...@ietf.org;
> lsr@ietf.org; cho...@chopps.org; Acee Lindem (acee) 
> *Subject:* Re: Robert Wilton's Discuss on
> draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)
>
>
>
> Hi Rob,
>
>
>
> Thanks for your review and comments/suggestions. Please check inline below
> for responses.
>
>
>
> Will update these changes (and further changes, if required) in the next
> version once we conclude.
>
>
>
> On Thu, Oct 6, 2022 at 4:20 PM Robert Wilton via Datatracker <
> nore...@ietf.org> wrote:
>
> Robert Wilton has entered the following ballot position for
> draft-ietf-lsr-ospf-reverse-metric-09: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/
>
>
>
> --
> DISCUSS:
> --
>
> Thanks for this document.
>
> I support Alvaro's discuss.  Having read Alvaro's discuss after writing my
> ballot comments it seems to be some what closely related, but I am also
> balloting discuss because I find the operational guidelines to be unclear.
>
> (1) p 8, sec 7.  Operational Guidelines
>
>Implementations MUST NOT signal reverse metric to neighbors by
>default and MUST provide a configuration option to enable the
>signaling of reverse metric on specific links.  Implementations
>SHOULD NOT accept the RM from its neighbors by default and SHOULD
>provide a configuration option to enable the acceptance of the RM
>from neighbors on specific links.  This is to safeguard against
>inadvertent use of RM.
>
> I'm not really sure that I properly understand how this feature works from
> a
> manageability perspective.  Particularly for your first use case, when
> considering that the proposal is for per link configuration for the
> acceptance
> of RM from neighbours.  This would seem to suggest that before you can
> make use
> of reverse-metric you have to already have determined the links on the
> affected
> devices to then configure them to accept the reverse-metrics, at which
> point,
> doesn't this partially defeat the use case?
>
>
>
> KT> If the operator is using this feature, then it needs to be enabled
> first. This is a one-time/initial config.
>
>
>
> Sure.   Presumably you mean both on the devices that will transmit the RM
> and also devices that will receive them?
>

KT2> Correct.


>
>
> Or is the main goal to simplify
> the coordination of changing the metric at both ends of the link at the
> same
> time?
>
>
>
> KT> Correct. The advertisement of reverse metric is applied/triggered on
> the sending side on-need basis.
>
>
>
>
> Or is the intention that during the maintenance window the operators would
> enable the "allow receipt of reverse-metrics" on all links within, say, an
> area?  If so, would hierarchical device and area specific configuration be
> more
> appropriate?  E.g., allow it to be enabled/disbaled on individual links,
> but
> also allow more coarse grained configuration.
>
>
>
> KT> I would expect the feature enablement (specifically the receiving
> part) to be on multiple hierarchical levels (instance/area/link). The RM
> value config for sending is on the link, but for some use cases, it would
> perhaps be also hierarchical.
>
>
>
> Okay, it is only the feature enablement that I am concerned with, with my
> reading of the text implying that the feature to accept RM values must
> (perhaps only) be configurable on a per interface basis.
>

KT2> The "only" part is not there. The point was that the operator needs to
have an option for control at each link level. It does not preclude
hierarchical config.


>
>
> Specifically, it is this text that I have an issue with:
>
>Implementations MUST
>
>NOT accept the RM from its neighbors by default and MUST provide a
>
>configuration option to enable the acceptance of the RM from
>
>neighbors on specific links.  This is to safeguard against
>
>inadvertent use of RM.
>
>
>
> I think that this text should be changed to explicitly acknowledge or
> 

[Lsr] I-D Action: draft-ietf-lsr-ospf-reverse-metric-12.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : OSPF Reverse Metric
Authors : Ketan Talaulikar
  Peter Psenak
  Hugh Johnston
  Filename: draft-ietf-lsr-ospf-reverse-metric-12.txt
  Pages   : 13
  Date: 2022-10-10

Abstract:
   This document specifies the extensions to OSPF that enable a router
   to use link-local signaling to signal the metric that receiving OSPF
   neighbor(s) should use for a link to the signaling router.  The
   signaling of this reverse metric, to be used on the link to the
   signaling router, allows a router to influence the amount of traffic
   flowing towards itself and in certain use cases enables routers to
   maintain symmetric metrics on both sides of a link between them.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-reverse-metric-12


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

Re: [Lsr] RFC 8362 and LSInfinity

[Ketan Talaulikar]

Hi Acee,

I agree.

I believe we also need to clarify the applicability of LSInfinity for
Intra-Area prefixes in SRv6 Locator TLV as well in
draft-ietf-lsr-ospfv3-srv6-extensions.

Thanks,
Ketan


On Sat, Oct 8, 2022 at 1:33 AM Acee Lindem (acee)  wrote:

> Hi Peter, Ketan,
>
>
>
> We’ll do another WG last call on the updated IP Flex Algo document and it
> will update RFC 8362. As you probably surmised, this is useful for OSPFv3
> IP Flex Algorithm when you want don’t want to use the prefix with the base
> algorithm.
>
>
>
> *From: *Lsr  on behalf of Ketan Talaulikar <
> ketant.i...@gmail.com>
> *Date: *Thursday, October 6, 2022 at 3:35 AM
> *To: *Peter Psenak 
> *Cc: *"lsr@ietf.org" 
> *Subject: *Re: [Lsr] RFC 8362 and LSInfinity
>
>
>
> Hi Peter,
>
>
>
> I support this "update" - not sure if it qualifies as a "clarification".
> Also, this obviously is doable only when the network has migrated to use
> only Extended LSAs (i.e., legacy LSAs are removed) as indicated in
> https://www.rfc-editor.org/rfc/rfc8362.html#section-6.1
>
>
>
> In sparse-mode, the legacy LSAs are used. So if you want a prefix to be
> unreachable with the base algorithm, simply omit it from the legacy
> Intra-Area-Prefix LSA.
>
>
>
> Thanks,
> Acee
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Wed, Oct 5, 2022 at 3:01 PM Peter Psenak  40cisco@dmarc.ietf.org> wrote:
>
> Hi Folks,
>
> metric of LSInfinity (0xFF) has been defined in RFC2328:
>
> LSInfinity
>  The metric value indicating that the destination described by an
>  LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as
>  an alternative to premature aging (see Section 14.1). It is
>  defined to be the 24-bit binary value of all ones: 0xff.
>
> RFC5340 inherited it from RFC2328:
>
> Appendix B.  Architectural Constants
>
> Architectural constants for the OSPF protocol are defined in Appendix
> B of [OSPFV2].  The only difference for OSPF for IPv6 is that
> DefaultDestination is encoded as a prefix with length 0 (see
> Appendix A.4.1).
>
> Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix
> reachability, so the LSInfinity was not applicable for intra-area prefixes.
>
> RFC8362 defines 24-bit metric for all prefix reachability TLVs -
> Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV.
> Although it is silent about the LSInfinity as such, it is assumed that
> such metric means unreachability for Inter-Area-Prefix TLV and
> External-Prefix TLV. Given that Intra-Area-Prefix TLV now has 24 bits
> metric as well, it would make sense to define the LSInfinity as
> unreachable for Intra-Area-Prefix TLV as well.
>
> Would anyone object such a clarification in RFC8362?
>
> thanks,
> Peter
>
> ___
> 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] Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)

[Rob Wilton (rwilton)]

Hi Ketan,

Please see inline …

From: Ketan Talaulikar 
Sent: 06 October 2022 12:58
To: Rob Wilton (rwilton) 
Cc: The IESG ; draft-ietf-lsr-ospf-reverse-met...@ietf.org; 
lsr-cha...@ietf.org; lsr@ietf.org; cho...@chopps.org; Acee Lindem (acee) 

Subject: Re: Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: 
(with DISCUSS)

Hi Rob,

Thanks for your review and comments/suggestions. Please check inline below for 
responses.

Will update these changes (and further changes, if required) in the next 
version once we conclude.

On Thu, Oct 6, 2022 at 4:20 PM Robert Wilton via Datatracker 
mailto:nore...@ietf.org>> wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ospf-reverse-metric-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/



--
DISCUSS:
--

Thanks for this document.

I support Alvaro's discuss.  Having read Alvaro's discuss after writing my
ballot comments it seems to be some what closely related, but I am also
balloting discuss because I find the operational guidelines to be unclear.

(1) p 8, sec 7.  Operational Guidelines

   Implementations MUST NOT signal reverse metric to neighbors by
   default and MUST provide a configuration option to enable the
   signaling of reverse metric on specific links.  Implementations
   SHOULD NOT accept the RM from its neighbors by default and SHOULD
   provide a configuration option to enable the acceptance of the RM
   from neighbors on specific links.  This is to safeguard against
   inadvertent use of RM.

I'm not really sure that I properly understand how this feature works from a
manageability perspective.  Particularly for your first use case, when
considering that the proposal is for per link configuration for the acceptance
of RM from neighbours.  This would seem to suggest that before you can make use
of reverse-metric you have to already have determined the links on the affected
devices to then configure them to accept the reverse-metrics, at which point,
doesn't this partially defeat the use case?

KT> If the operator is using this feature, then it needs to be enabled first. 
This is a one-time/initial config.

Sure.   Presumably you mean both on the devices that will transmit the RM and 
also devices that will receive them?

Or is the main goal to simplify
the coordination of changing the metric at both ends of the link at the same
time?

KT> Correct. The advertisement of reverse metric is applied/triggered on the 
sending side on-need basis.


Or is the intention that during the maintenance window the operators would
enable the "allow receipt of reverse-metrics" on all links within, say, an
area?  If so, would hierarchical device and area specific configuration be more
appropriate?  E.g., allow it to be enabled/disbaled on individual links, but
also allow more coarse grained configuration.

KT> I would expect the feature enablement (specifically the receiving part) to 
be on multiple hierarchical levels (instance/area/link). The RM value config 
for sending is on the link, but for some use cases, it would perhaps be also 
hierarchical.

Okay, it is only the feature enablement that I am concerned with, with my 
reading of the text implying that the feature to accept RM values must (perhaps 
only) be configurable on a per interface basis.

Specifically, it is this text that I have an issue with:

   Implementations MUST
   NOT accept the RM from its neighbors by default and MUST provide a
   configuration option to enable the acceptance of the RM from
   neighbors on specific links.  This is to safeguard against
   inadvertent use of RM.

I think that this text should be changed to explicitly acknowledge or allow 
hierarchical configuration.  E.g., something along the lines of:


 Implementations MUST NOT accept the RM from neighbors by default.

  Implementations MAY provide configuration to accept the RM globally on the 
device, or per area, but
  Implementations MUST support configuration to enable/disable acceptance of 
the RM from neighbors on specific links.
  This is to safeguard against inadvertent use of RM.






Not as an update for this document, but I am assuming that the LSR working
group with eventually update or augment the OSPF YANG module with standard
configuration to support this feature.

KT> Ack. Will include the same reference and text that we have discussed for 
the OSPF L2 bundles draft.

Sounds good.  

Re: [Lsr] RFC 8362 and LSInfinity

[Peter Psenak]

Aijun,

On 09/10/2022 07:44, Aijun Wang wrote:

Hi, Acee, Peter and Ketan:

I propose we limit the usage of LSInfinity within the network. That is 
to say, we should depreciate its usages, not enhance it.


As defined in RFC2328, the sole purpose of LSInfinity is to let the 
receiver bypass the SPF calculation for the associated LSA:


a)In case the advertisement of LSA for some special aim.

b)Another is for the premature aging the LSA (which is not encouraged).

There is few application for the a) usage until now, same situation for 
b) usage.


definition of LSInfinity is very exact - it means unreachability.



The reason for the above situations may be the definition within the 
RFC2328 is counterintuitivethe maximum value of the metric should be 
used for the last resort of the reachability, no other more meanings. Or 
else, it will complex the implementation and deployment, for example:


a)For OSPFv2, the LSInfinity is defined as 0xff

b)For IS-IS, the equivalent variable is MAX_PATH_METRIC, which is 
defined as 0xFE00


you are comparing apples to oranges. These are two different protocols.



c)For OSPFv3, which value will you be defined, especially for the 
Intra-Area-Prefix? Considering the metric for the intra-area and 
inter-area are all 24-bit long?


OSPFv3 inherits all the constants defined for OSPFv2, it's explicitly 
mentioned in the OSPFv3 RFC. And LSInfinity is 24 bits long.




d)And, for the metric in ”IP Algorithm Prefix Reachability” , 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.3 , its length is again 32-bit, will you define another LSInfinity value later?


0x seems like a good candidate for the unreachable metric for 
the IP flex-algo.




Won’t you think the above special rule complex the whole situation?


not at all.



I think we should seek other methods to achieve the necessary goals.


I do not see a problem

thanks,
Peter


Best Regards

Aijun Wang

China Telecom

*From:* lsr-boun...@ietf.org  *On Behalf Of *Acee 
Lindem (acee)

*Sent:* Saturday, October 8, 2022 4:03 AM
*To:* Ketan Talaulikar ; Peter Psenak 


*Cc:* lsr@ietf.org
*Subject:* Re: [Lsr] RFC 8362 and LSInfinity

Hi Peter, Ketan,

We’ll do another WG last call on the updated IP Flex Algo document and 
it will update RFC 8362. As you probably surmised, this is useful for 
OSPFv3 IP Flex Algorithm when you want don’t want to use the prefix with 
the base algorithm.


*From: *Lsr mailto:lsr-boun...@ietf.org>> on 
behalf of Ketan Talaulikar >

*Date: *Thursday, October 6, 2022 at 3:35 AM
*To: *Peter Psenak >
*Cc: *"lsr@ietf.org " >

*Subject: *Re: [Lsr] RFC 8362 and LSInfinity

Hi Peter,

I support this "update" - not sure if it qualifies as a "clarification". 
Also, this obviously is doable only when the network has migrated to use 
only Extended LSAs (i.e., legacy LSAs are removed) as indicated in 
https://www.rfc-editor.org/rfc/rfc8362.html#section-6.1 



In sparse-mode, the legacy LSAs are used. So if you want a prefix to be 
unreachable with the base algorithm, simply omit it from the legacy 
Intra-Area-Prefix LSA.


Thanks,
Acee

Thanks,

Ketan

On Wed, Oct 5, 2022 at 3:01 PM Peter Psenak 
mailto:40cisco@dmarc.ietf.org>> 
wrote:


Hi Folks,

metric of LSInfinity (0xFF) has been defined in RFC2328:

LSInfinity
          The metric value indicating that the destination described
by an
          LSA is unreachable. Used in summary-LSAs and
AS-external-LSAs as
          an alternative to premature aging (see Section 14.1). It is
          defined to be the 24-bit binary value of all ones: 0xff.

RFC5340 inherited it from RFC2328:

Appendix B.  Architectural Constants

     Architectural constants for the OSPF protocol are defined in
Appendix
     B of [OSPFV2].  The only difference for OSPF for IPv6 is that
     DefaultDestination is encoded as a prefix with length 0 (see
     Appendix A.4.1).

Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix
reachability, so the LSInfinity was not applicable for intra-area
prefixes.

RFC8362 defines 24-bit metric for all prefix reachability TLVs -
Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV.
Although it is silent about the LSInfinity as such, it is assumed that
such metric means unreachability for Inter-Area-Prefix TLV and
External-Prefix TLV. Given that Intra-Area-Prefix TLV now has 24 bits
metric as well, it would make sense to define the LSInfinity as
unreachable for Intra-Area-Prefix TLV as well.

Would anyone object such a clarification in RFC8362?

thanks,
Peter