Re: [Lsr] WG Adoption Call for "IS-IS Optimal Distributed Flooding for Dense Topologies" - draft-white-lsr-distoptflood-03

[Acee Lindem (acee)]

Authors,

The working group adoption call has completed and we will adopt the subject 
document as an informational document. We can continue to discuss whether it is 
experimental or informational. Please republish as 
draft-ietf-lsr-distoptflood-00.

There was one substantive discussion with Les Ginsberg and I believe updates 
were discussed. Please continue this discussion with the working group version 
of the document.

Thanks,
Acee

From: Acee Lindem (acee) 
Date: Tuesday, November 22, 2022 at 3:01 PM
To: lsr@ietf.org 
Subject: WG Adoption Call for "IS-IS Optimal Distributed Flooding for Dense 
Topologies" - draft-white-lsr-distoptflood-03
LSR WG,

This begins a 2 week WG adoption call for the following draft:

https://datatracker.ietf.org/doc/draft-white-lsr-distoptflood/

The draft would be adopted on the Informational or Experimental track.

Please indicate your support or objection by December 7th, 2022.
Also indicate whether you believe it should be Informational or Experimental 
track.

Thanks,
Acee


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

Re: [Lsr] Identifying an instance

[Acee Lindem (acee)]

RFC 8349 uses an unbounded string for control-plane-protocol so this definition 
would be consistent. However, we've been putting bounds on strings that are 
encoded in packets and this is probably something we should do for all strings. 

container control-plane-protocols {
 description
   "Support for control-plane protocol instances.";
 list control-plane-protocol {
   key "type name";
   description
 "Each entry contains a control-plane protocol instance.";
   leaf type {
 type identityref {
   base control-plane-protocol;
 }
 description
   "Type of the control-plane protocol -- an identity
derived from the 'control-plane-protocol'
base identity.";
   }
   leaf name {
 type string;
 description
   "An arbitrary name of the control-plane protocol
instance.";
   }

Thanks,
Acee

Thanks,
Acee

On 12/12/22, 7:09 AM, "Lsr on behalf of tom petch" mailto:lsr-boun...@ietf.org> on behalf of ie...@btconnect.com 
> wrote:


What is the recommended way of identifying an instance of the routing protocol 
I S I S within a node?
draft-ietf-opsawg-service-assurance-yang proposes (Appendix B.5) an 
unrestricted string, ie almost any Unicode character up to a length of 
18446744073709551615 characters long (my favourite number).


Is this the recommended way of doing it?


Tom Petch
___
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 Last Call for draft-ietf-lsr-rfc8920bis-00

[Acee Lindem (acee)]

Speaking as a contributor and WG member: 

I am not aware of any IPR. I support publication. 

Thanks,
Acee

On 12/7/22, 9:07 AM, "Christian Hopps" mailto:cho...@chopps.org>> wrote:




This begins a 2 week WG Last Call, ending Dec 21, 2022, for:


https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8920bis/ 



Authors,


Please indicate to the list, your knowledge of any IPR related to this work.


Thanks,
Chris.





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

Re: [Lsr] WG Last Call for draft-ietf-lsr-rfc8919bis-00

[Acee Lindem (acee)]

Speaking as WG member:

I support publication. 

Thanks,
Acee

On 12/7/22, 9:05 AM, "Christian Hopps" mailto:cho...@chopps.org>> wrote:




This begins a 2 week WG Last Call, ending Dec 21, 2022, for:


https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8919bis/ 



Authors,


Please indicate to the list, your knowledge of any IPR related to this work.


Thanks,
Chris.





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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-02.txt

[Acee Lindem (acee)]

Speaking as WG member.

See one inline.

From: Lsr  on behalf of Tony Li 
Date: Tuesday, December 6, 2022 at 6:23 PM
To: "Les Ginsberg (ginsberg)" 
Cc: Bruno Decraene , lsr 
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-02.txt


Bruno, Les,

Some responses inline – speaking only for myself – not necessarily for all of 
the co-authors…


Likewise.




1.
“Network operators should not enable Multi-part TLVs until ensuring
   that all implementations that will receive the Multi-part TLVs are
   capable of interpreting them correctly.”

I would rather call for a « must not ».

From a manageability standpoint, since the burden is now on the network 
operators to ensure that this will work/not break the network, for existing 
TLV, this seem to call:
[LES:] There was never a choice here – the burden is on network operators – and 
would be even if an advertisement of MP support were provided. Why? Because 
there is no safe way for implementations to react to changes in the network 
state regarding MP support without risking flooding storms.
And, repeating a point I have made in the past, suppressing advertisement of 
MP-TLVs when the current configuration requires sending them does not result in 
a working network.
I don’t think it is a productive discussion to try to determine which condition 
is worse:

a)To send MP-TLVs in the presence of one or nodes which are unable to process 
them or
b)To suppress sending of some information required by the existing configuration

Either way, the network will not be working as expected.


I disagree with Les, I don’t see how flooding storms can ensue, and never have. 
 But we’ve been over that point and I see no point in beating a dead horse. 
There was really no reason to bring it up again.

More specifically, I don’t see that “MUST NOT” buys us anything over “should 
not”.  What are we going to do if the operator chooses not to comply? Write a 
ticket? Wag our finger at them? If it was a protocol implementation feature, we 
would shrug our shoulders and say “bad implementation”. Since this is 
operational, and the consequences will impact the operator, I don’t think we 
would have any impact, especially after the fact.



-  for a MUST implement knob to enable/disable (MAY/SHOULD on a per TLV 
basis?). And possibly a SHOULD NOT be enabled by default. Current text says 
RECOMMENDED and I don’t feel that this is enough given that this involves an 
interop issue, and that some vendors/implementers tends to only implements MUST.

[LES:] I am fine either way. But as you are trying to apply normative language 
to a behavior which is not reflected “on the wire”, it is hard to see that 
there is any ability to enforce this.
SHOULD/RECOMMENDED seems appropriate to me.


I concur with Les here. This is not meant to be a BCP about how to run the 
network.


 - a CLI and I would also suggest the document to specify a YANG extension to 
allow network operators to know whether a given implementation support this or 
not (on a per TLV basis?)

[LES:] This makes sense to me.


I can get behind saying that there should be a CLI output and a YANG model 
extension/augmentation.  If you’re asking us to actually propose the YANG 
augmentation, I would be very hesitant due to the OpenConfig/IETF split.  
Anything that we would do here seems like a total waste of time and effort.


Since we’d like to complete this document swiftly, let’s defer YANG 
augmentations to 
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-yang-augmentation-v1/

Thanks,
Acee


 2)

“the key information MUST

   be replicated in additional TLV instances so that all contents

   specific to that key can be identified”


Are we all certain that for all TLVs and sub-TLVs, everyone/implementation will 
agree on what the key is? (especially if the key were to be spread over 
multiple fields or if a sub-TLV were to contain both a key and non-key data).
In order to err on the safe side, I would prefer that this doc specifies the 
key for all existing TLVs.


e.g. 
“4.1.
  Example: Extended IS Reachability”

“Optionally one or more of the following identifiers:



  -  IPv4 interface address and IPv4 neighbor address as specified

 in [RFC5305]



  -  IPv6 interface address and IPv6 neighbor address as specified

 in [RFC6119] »



If multiple (N) IPv6 interface addresses are advertised, these N sub-TLVs are 
part of the key and must be advertised in all instances./part? Or is a single 
common

ID enough to be used as a key of the interface?



[LES:] Initially, we did not target this draft to serve as “closing the gap” as 
regards existing TLVs where the relevant RFC is not explicit

regarding MP support. However, I think the discussion in the WG has highlighted 
that some codepoints have 

[Lsr] FW: I-D Action: draft-ietf-lsr-ospf-admin-tags-07.txt

[Acee Lindem (acee)]

This version includes Ketan Talauikar's comments including clarification of 
BGP-LS advertisement. 

Thanks,
Acee

On 11/28/22, 3:14 PM, "Lsr on behalf of internet-dra...@ietf.org" 
 wrote:


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   : Extensions to OSPF for Advertising Prefix 
Administrative Tags
Authors : Acee Lindem
  Peter Psenak
  Yingzhen Qu
  Filename: draft-ietf-lsr-ospf-admin-tags-07.txt
  Pages   : 19
  Date: 2022-11-28

Abstract:
   It is useful for routers in OSPFv2 and OSPFv3 routing domains to be
   able to associate tags with prefixes.  Previously, OSPFv2 and OSPFv3
   were relegated to a single tag and only for AS External and Not-So-
   Stubby-Area (NSSA) prefixes.  With the flexible encodings provided by
   OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs,
   multiple administrative tags may be advertised for all types of
   prefixes.  These administrative tags can be used for many
   applications including route redistribution policy, selective prefix
   prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection,
   and many others.

   The ISIS protocol supports a similar mechanism that is described in
   RFC 5130.


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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-admin-tags-07.html

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


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

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

[Lsr] WG Adoption Call for "IS-IS Optimal Distributed Flooding for Dense Topologies" - draft-white-lsr-distoptflood-03

[Acee Lindem (acee)]

LSR WG,

This begins a 2 week WG adoption call for the following draft:

https://datatracker.ietf.org/doc/draft-white-lsr-distoptflood/

The draft would be adopted on the Informational or Experimental track.

Please indicate your support or objection by December 7th, 2022.
Also indicate whether you believe it should be Informational or Experimental 
track.

Thanks,
Acee


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

[Lsr] IPR Poll for "IS-IS Optimal Distributed Flooding for Dense Topologies" - draft-white-lsr-distoptflood-03

[Acee Lindem (acee)]

Authors,

Are you aware of any IPR that applies to draft-white-lsr-distoptflood-03.txt?

The following IPR declarations have been disclosed:

https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-white-lsr-distoptflood

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

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

[Lsr] NomCom Feedback Requested for IESG and IAB Candidates

[Acee Lindem (acee)]

All,

The NomCom is tasked with selecting the IETF leadership, like the IESG and the 
IAB. For the NomCom to be able to make an informed decision, they need feedback 
from the wider IETF community.

Please, allocate some time to provide feedback on people that you interacted 
with to help the NomCom with their important task.
The deadline for this feedback is Nov 28.
https://datatracker.ietf.org/nomcom/2022/feedback/

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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Acee Lindem (acee)]

Hi Robert,

From: Robert Raszuk 
Date: Thursday, November 10, 2022 at 10:51 AM
To: Acee Lindem 
Cc: Peter Psenak , Bruno Decraene 
, David Lamparter , 
"lsr@ietf.org" 
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS 
semantics

> But BGP service PIC is the use case this draft is targeting?

For many emails on LSR and beyond I got point from authors against using BGP 
for such signalling as "BGP may not be running there at all".

So if the draft works *only* with service provided by BGP let's please state it 
clearly in the document. This is not my current assumption.

I think the point of this was that it could be other applications where an 
ephemeral unreachability notification is useful. For this type of notification, 
recursive route resolution is the primary application. However, I’ll defer to 
the authors.

Thanks,
Acee


Many thx,
R.



On Thu, Nov 10, 2022 at 11:47 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,

From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Thursday, November 10, 2022 at 9:41 AM
To: Peter Psenak 
mailto:40cisco@dmarc.ietf.org>>
Cc: Bruno Decraene 
mailto:bruno.decra...@orange.com>>, David Lamparter 
mailto:equi...@diac24.net>>, Acee Lindem 
mailto:a...@cisco.com>>, "lsr@ietf.org<mailto:lsr@ietf.org>" 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS 
semantics

Peter,

> But:
> - that is nonetheless a change which is non backward compatible with people 
> currently using such high metric without the intention to mean UPA
> - to differentiate different usages (e.g. your UPA, my other usage such as 
> "graceful shutdown" (still reachable but will disappear soon), endpoint CPU 
> load is 80%...) one

well, the question is whether it would not make sense to trigger UPA for
the above mentioned usages as well. Because eventually the destination
is becoming unreachable anyway and I would want my services to reroute
to alternate egress node. But seems like folks want to have a way to
differentiate, so I'm not going to argue against it.

I think You are right if there is a hierarchical service above it.

But consider flat routing - where there is no BGP service on top. Example - 
some DCs do use flat routing.

With that I am afraid UPA triggers may not work well (or at all) ... especially 
considering that they are history after the timeout irrespective of the remote 
prefix state.

But BGP service PIC is the use case this draft is targeting? For example, there 
is no intent to install negative routes throughout the domain.

Thanks,
Acee


Cheers,
R.








thanks,
Peter

> would need to use different metric values that would need to be at least 
> locally registered. So why not have the IANA register a flag and avoid each 
> network operator to do that job?
>
> In all cases, I don't see a reason for UPA to change the meaning of all the 
> metric values >0xFE00. You can pick a single value (e.g. 0xFE01) and 
> that would equally work for your use case.
>
> Regards,
> --Bruno
>
>
>
>
>>
>>>
>>> I vaguely remember several years back we did indeed implement something
>>> (seriously no memory on details) that resulted in the creation of a new
>>> prefix reachability TLV with some experimental/local sub-TLVs.  These
>>> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
>>> what the operational reality is on the existence of such things, but I
>>> know that /some/ code exists that does this.
>>>
>>> To boil this down into the core of the essence and be explicit,
>>>
>>> - you can create an IS-IS prefix reachability for some arbitrary prefix,
>>> and stick > 0xfe00 into the metric, and that won't have any effect
>>> on the existing IS-IS domain
>>> - this has in fact been done to carry custom bits of information that
>>> for one reason or another were decided to be routing-related and thus
>>> make sense to put there
>>> - the assumption for the use case is that there are indeed less specific
>>> covering prefixes around, providing actual reachability
>>> - any setup doing that would now suddenly have fresh "unreachable"
>>> semantics attached to something that didn't have them before, which
>>> breaks things (or rather: prevents enabling/deployment of the UPA
>>> feature)
>>
>> and why that would be a problem? Such prefix would never be used to for
>> resolution of the BGP prefix. So the presence of such unreachable prefix
>> would never trigger any action even of the UPA processing was enabled on
&g

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Acee Lindem (acee)]

Hi Robert,

From: Robert Raszuk 
Date: Thursday, November 10, 2022 at 9:41 AM
To: Peter Psenak 
Cc: Bruno Decraene , David Lamparter 
, Acee Lindem , "lsr@ietf.org" 

Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS 
semantics

Peter,

> But:
> - that is nonetheless a change which is non backward compatible with people 
> currently using such high metric without the intention to mean UPA
> - to differentiate different usages (e.g. your UPA, my other usage such as 
> "graceful shutdown" (still reachable but will disappear soon), endpoint CPU 
> load is 80%...) one

well, the question is whether it would not make sense to trigger UPA for
the above mentioned usages as well. Because eventually the destination
is becoming unreachable anyway and I would want my services to reroute
to alternate egress node. But seems like folks want to have a way to
differentiate, so I'm not going to argue against it.

I think You are right if there is a hierarchical service above it.

But consider flat routing - where there is no BGP service on top. Example - 
some DCs do use flat routing.

With that I am afraid UPA triggers may not work well (or at all) ... especially 
considering that they are history after the timeout irrespective of the remote 
prefix state.

But BGP service PIC is the use case this draft is targeting? For example, there 
is no intent to install negative routes throughout the domain.

Thanks,
Acee


Cheers,
R.








thanks,
Peter

> would need to use different metric values that would need to be at least 
> locally registered. So why not have the IANA register a flag and avoid each 
> network operator to do that job?
>
> In all cases, I don't see a reason for UPA to change the meaning of all the 
> metric values >0xFE00. You can pick a single value (e.g. 0xFE01) and 
> that would equally work for your use case.
>
> Regards,
> --Bruno
>
>
>
>
>>
>>>
>>> I vaguely remember several years back we did indeed implement something
>>> (seriously no memory on details) that resulted in the creation of a new
>>> prefix reachability TLV with some experimental/local sub-TLVs.  These
>>> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
>>> what the operational reality is on the existence of such things, but I
>>> know that /some/ code exists that does this.
>>>
>>> To boil this down into the core of the essence and be explicit,
>>>
>>> - you can create an IS-IS prefix reachability for some arbitrary prefix,
>>> and stick > 0xfe00 into the metric, and that won't have any effect
>>> on the existing IS-IS domain
>>> - this has in fact been done to carry custom bits of information that
>>> for one reason or another were decided to be routing-related and thus
>>> make sense to put there
>>> - the assumption for the use case is that there are indeed less specific
>>> covering prefixes around, providing actual reachability
>>> - any setup doing that would now suddenly have fresh "unreachable"
>>> semantics attached to something that didn't have them before, which
>>> breaks things (or rather: prevents enabling/deployment of the UPA
>>> feature)
>>
>> and why that would be a problem? Such prefix would never be used to for
>> resolution of the BGP prefix. So the presence of such unreachable prefix
>> would never trigger any action even of the UPA processing was enabled on
>> the receiver. I don't see a problem.
>>
>>> - (if those extra prefixes are created with 0x metric, a
>>> configurable >= limit for UPA does not help either.)
>>
>> again, what is the problem?
>>
>>>
>>> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
>>> (IMHO) not a significant cost, and completely eliminates this issue.
>>> The only reason against it (that I can think of) is that the
>>> advertisement might be a little bit larger;  a new sub-TLV or flag bit
>>> should be completely invisible to existing implementations (= I don't
>>> see how this would create compatibility or rollout problems.)
>>
>> I'm afraid, you forgot to consider an operational aspect of the solution.
>>
>> thanks,
>> Peter
>>
>>>
>>> Cheers,
>>>
>>>
>>> -David
>>>
>>
>
> Orange Restricted
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisatio

Re: [Lsr] OSPF-GT

[Acee Lindem (acee)]

Hi Robert,

From: Robert Raszuk 
Date: Wednesday, November 9, 2022 at 10:37 AM
To: Acee Lindem , lsr 
Subject: OSPF-GT

Hi Acee,

The point of sparse GT makes it much more attractive.

With that I have two questions/suggestions to make it even more useful.

#1 Would you consider adding reflection function to spares mode GT ?

Within a flooding scope (e.g., area) , reflection is inherent in the flooding 
algorithm. One thing that applications will need to specify is whether or not 
information is re-originated outside the flooding scope (e.g., does the ABR 
re-originate application LSAs into other areas).


#2 If you do #1 would you considet pub-sub model ?

I wouldn’t change basic OSPF flooding. So, one could support pub-sub but 
everyone in the OSPF application routing domain would receive a superset of 
subscribed information (or the application would have to do something unnatural 
from an OSPF standpoint to limit the neighbors receiving the information, e.g., 
dynamically assign areas for unique subscriptions). I think other protocols are 
better suited to pub-sub.

Thanks,
Acee

Then this could be used for lot's of current use cases ... some of them even 
discussed today :)

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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Acee Lindem (acee)]

Speaking as WG Participant:

Hi Bruno, David, 

I guess I'd like to understand what one would accomplish with further 
specification of prefix reachable? What
 requirement would this satisfy? For the use case UPA is designed to handle 
(triggering BGP PIC or other local
action) , I can't see that there would be any case where you wouldn’t want to 
take this action for an unreachable
prefix. 

Thanks,
Acee

On 11/9/22, 10:56 AM, "Lsr on behalf of bruno.decra...@orange.com" 
 wrote:

> From: Lsr  On Behalf Of David Lamparter
> Sent: Wednesday, November 9, 2022 10:45 AM
> Hi Peter, hi all,
> 
> 
> to iterate on the comment I made on the mic a few minutes ago, I
> apparently have a rather different understanding of existing IS-IS
> behaviour.  Reading 5305/5308,
> 
> ... "if a prefix is advertised with a metric larger
   > than MAX_V6_PATH_METRIC (0xFE00), this prefix MUST not be
   > considered during the normal Shortest Path First (SPF)
   > computation."
> 
> A prefix that is "not considered" is not an unreachable prefix.  It's a
> prefix that is in the DB but ignored entirely, as if it wasn't there at
> all.  A less specific prefix may cover it, and I would expect that to
> work normally.

+1

> The UPA draft is changing this such that now some values may mean that
> the prefix is in fact unreachable. 

+1


> I'd rather not do that and just add
> a sub-TLV for it.

I'm fine to use max_prefix as per RFC 5305 (prefix not considered during 
SPF) as this allow for incremental deployment.
But in my opinion, advertising the unreachability semantic requires an 
additional explicit signaling. (I'm proposing a prefix flag, but that seem like 
a detail at this point)

Thanks,
--Bruno

> 
> (Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
> the only one to read it that way and that's a pretty important
> errata?!?)
> 
> Cheers,
> 
> 
> -David
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

Orange Restricted


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and 
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
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] I-D Action: draft-ietf-lsr-ip-flexalgo-07.txt

[Acee Lindem (acee)]

All,

Based on the WG Last Call discussion, section 6.4 has been added to clarify 
base algorithm exclusion in OSPFv3 E-Intra-Area-Prefix-LSAs. Please provide any 
additional comment before Nov 5, 2022. 

Thanks,
Acee

On 10/21/22, 4:20 AM, "Lsr on behalf of internet-dra...@ietf.org" 
 wrote:


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   : IGP Flexible Algorithms (Flex-Algorithm) In IP 
Networks
Authors : William Britto
  Shraddha Hegde
  Parag Kaneriya
  Rejesh Shetty
  Ron Bonica
  Peter Psenak
  Filename: draft-ietf-lsr-ip-flexalgo-07.txt
  Pages   : 21
  Date: 2022-10-21

Abstract:
   An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute
   constraint-based paths.  The base IGP Flex-Algorithm specification
   describes how it is used with Segment Routing (SR) data planes - SR
   MPLS and SRv6.

   This document extends IGP Flex-Algorithm, so that it can be used with
   regular IPv4 and IPv6 forwarding.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ip-flexalgo-07


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

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

Re: [Lsr] [IANA #1241047] Protocol Action: 'IGP extension for PCEP security capability support in PCE discovery' to Proposed Standard (draft-ietf-lsr-pce-discovery-security-support-13.txt)

[Acee Lindem (acee)]

This looks good to me though I'll defer final approval to the authors.  
Thanks,
Acee

On 10/21/22, 1:38 PM, "Sabrina Tanamal via RT"  
wrote:

Dear Authors:

ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED 

We've completed the registry actions for the following RFC-to-be:

draft-ietf-lsr-pce-discovery-security-support-13

ACTION 1: 

We've moved the following registry to the Interior Gateway Protocol (IGP) 
Parameters grouping at https://www.iana.org/assignments/igp-parameters. In 
addition, we've listed this document as a reference for the registry and left a 
pointer to the new page in the former location at 
https://www.iana.org/assignments/ospfv2-parameters. 

- Path Computation Element (PCE) Capability Flags

ACTION 2: 

We've added the following entries to the Path Computation Element (PCE) 
Capability Flags registry: 

17  TCP-AO Support  [RFC-ietf-lsr-pce-discovery-security-support-13]
18  PCEP over TLS support   [RFC-ietf-lsr-pce-discovery-security-support-13]

Please see
https://www.iana.org/assignments/igp-parameters

ACTION 3: 

We've created the following registry under the "Interior Gateway Protocol 
(IGP) Parameters" heading: 

PCED sub-TLV Type Indicators
Registration Procedure(s): Standards Action
Reference: [RFC-ietf-lsr-pce-discovery-security-support-13]

Value   Description Reference 
0   Reserved
[RFC-ietf-lsr-pce-discovery-security-support-13][RFC5088]
1   PCE-ADDRESS 
[RFC-ietf-lsr-pce-discovery-security-support-13][RFC5088]
2   PATH-SCOPE  
[RFC-ietf-lsr-pce-discovery-security-support-13][RFC5088]
3   PCE-DOMAIN  
[RFC-ietf-lsr-pce-discovery-security-support-13][RFC5088]
4   NEIG-PCE-DOMAIN 
[RFC-ietf-lsr-pce-discovery-security-support-13][RFC5088]
5   PCE-CAP-FLAGS   
[RFC-ietf-lsr-pce-discovery-security-support-13][RFC5088]
6   KEY-ID  [RFC-ietf-lsr-pce-discovery-security-support-13]
7   KEY-CHAIN-NAME  [RFC-ietf-lsr-pce-discovery-security-support-13]
8-65535 Unassigned

Please see
https://www.iana.org/assignments/igp-parameters

Please let us know whether this document's registry actions have been 
completed correctly. Once we receive your confirmation, we'll notify the RFC 
Editor that the actions are complete. If a team of authors is responsible for 
the document, and the actions have been performed correctly, please send a 
single confirmation message.

We'll update any references to this document in the registries when the RFC 
Editor notifies us that they've assigned an RFC number.

Best regards,

Sabrina Tanamal
Lead IANA Services Specialist


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

[Lsr] NomCom Seeking Nominations

[Acee Lindem (acee)]

In case you didn’t see the NomCom announcement.

Thanks,
Acee



The IETF Nomination Committee (NomCom) for 2022-2023 is seeking nominations 
from now until October 24.

The list of open positions can be found at the NomCom home page:
https://datatracker.ietf.org/nomcom/2022/
This also includes the list of those incumbents who have said they are seeking 
to be renominated.

To nominate someone, please click on the "Nominate" link at the top of the home 
page, or go there directly: https://datatracker.ietf.org/nomcom/2022/nominate/

Please include a brief description why you are nominating them. The "Candidate 
phone" is optional. If you do not click the "Share nominator name" box at the 
top of the page, then your nomination will be confidential and the nominee will 
not be told who you are.

Self nominations are welcome! To nominate the same person (including yourself) 
for more than one position, please use the form multiple times.

All nominees will be required to complete a questionnaire specific to the 
position for which they are nominated. The questionnaires will be available 
soon (at the NomCom page) and will also be mailed to the nominees directly.

The current (slightly tentative) timeline is posted at the NomCom page.

The list of nominees will be made available, and an opportunity for community 
feedback will be made after the nominations are closed. All feedback will be 
kept confidential to the committee, and all committee discussions and votes are 
also confidential.

Remember that it is easier to refuse a nomination, or decline later, than it is 
to nominate (or be nominated) later on.

We look forward to seeing a wide range of nominations! This is one of the key 
factors in the future success of the IETF.


-Rich Salz, 2022-2023 NomCom Chair

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

Re: [Lsr] Slot request for LSR meeting at IETF 115

[Acee Lindem (acee)]

Hi Yingzhen,

Please allocate a 10 minute slot for OSPF-GT (Generalized Transport).

Thanks,
Acee

From: Yingzhen Qu 
Date: Wednesday, October 12, 2022 at 7:40 PM
To: lsr-chairs , lsr 
Subject: Slot request for LSR meeting at IETF 115
Resent-From: 
Resent-To: Christian Hopps , Acee Lindem , 
Yingzhen Qu 
Resent-Date: Wednesday, October 12, 2022 at 7:40 PM

Dear LSR WG:

The preliminary agenda of IETF 115 has been released, and the LSR session is 
scheduled on Wednesday Session I (9:30-11:30).

Please send your presentation request to LSR WG chairs 
(lsr-cha...@ietf.org) with the following info:
· draft to be presented
· presented
· estimated time needed, including Q&A
If there is any question, please let me know.

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

Re: [Lsr] RFC 8362 and LSInfinity

[Acee Lindem (acee)]

Hi Aijun, 

On 10/13/22, 6:53 AM, "Aijun Wang"  wrote:

Hi, Acee and Peter:

I think you all misunderstood the intent of his scenario.
The correct understanding are the followings:
1) When aggregate route is configured in the ABR, the specified detail 
route should be withdrawn.
2) ABR can withdraw the advertised LSA that describes the specific detail 
route, via premature mechanism(MaxAge or LSInfinity, the former is preferred 
according to RFC2328)
3) But, withdrawn such specific LSA doesn’t mean the corresponding detail 
route unreachable——This destination can be reached via the aggregate route 
advertised by ABR instead.

This is the original usage of LSInfinity defined in RFC2327. It should be 
expanded further.

How to apply it in RFC8362 is another issue, as indicated my responses in 
another thread.

In summary, again, we should constrain or depreciate the confusion usages 
of LSInfinity.

The lack of visibility into the another area due to summarization is 
independent of any usage of LSInfinity within that area. This is also 
independent of the WG discussions of new drafts to signal unreachability 
outside the area. 

Thanks,
Acee

Aijun Wang
China Telecom

> On Oct 13, 2022, at 18:07, Acee Lindem (acee) 
 wrote:
> 
> Hi Zhibo, 
> 
> On 10/13/22, 2:26 AM, "Lsr on behalf of Huzhibo"  wrote:
> 
>Hi LSR:
> 
>LSInfinity
>The metric value indicating that the destination described by an
>LSA is unreachable. Used in summary-LSAs and AS-external-LSAs
> 
>I want to clarify the meaning of unreachable in LSifinity, 
>Assume that a node advertise specific route of 1.1.1.1/32, and an 
aggregate route 1.1.0.0/16 is configured.
>This node should premature aging of the 1.1.1.1/32 LSA.
>If this node using LSInfinity metric instead of prematuring aging, 
route 1.1.1.1/32 is still reachable.
>Therefore, the "unreachable" described by LSifinity is not really 
unreachable.
> 
> If your OSPF implementation includes unreachable LSAs in the summary cost 
computation, it is indeed broken.
> 
> Thanks,
> Acee
> 
>Thanks
>Zhibo hu
> 
>> -Original Message-
>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>> Sent: Wednesday, October 5, 2022 5:32 PM
>> To: lsr@ietf.org
>> Subject: [Lsr] RFC 8362 and LSInfinity
>> 
>> 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.
>> Al


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

[Lsr] FW: Directorate Early Reviews

[Acee Lindem (acee)]

Note that for LSR, we usually do this anyway so this really isn’t a change of 
policy. At least as a document shepherd, I always try and remember.

Thanks,
Acee

From: Andrew Alston - IETF 
Date: Wednesday, October 12, 2022 at 3:30 AM
To: "rtg-cha...@ietf.org" 
Subject: Directorate Early Reviews
Resent-From: 
Resent-To: , , Daniele Ceccarelli 
, , 
, Yingzhen Qu , 
, , Gunter Van de Velde 
, , 
, Jie Dong , Alvaro Retana 
, Jeff Haas , , 
Acee Lindem , , "Joel M. Halpern" 
, Christian Hopps , Sam Aldrin 
, , , 
, John Scudder , , 
, , , 
, János Farkas , Luis 
Contreras , , 
, Jeff Tantsura , Stewart 
Bryant , , , 
, , Loa Andersson 
, Tarek Saad , 
, , , 
, Nic Leymann , Jeffrey 
Zhang , , , 
Mach Chen , , 
, , 
, , Keyur Patel , 
Russ White , Bruno Decraene , 
, , 
Resent-Date: Wednesday, October 12, 2022 at 3:29 AM

Hi All,

Following the helpful feedback received during chair’s meeting and further 
discussion between the routing AD’s, we would like to propose the following:


1.)We will require early directorate reviews before documents come to the 
AD’s to enter the publication queue

2.)We suggest that these reviews are done either in parallel with the 
working group last call or between the working group last call and publication 
request

a.   In the case of the early directorate review being done in parallel 
with the last call, it is suggested to use this approach only if there is 
indication that the document is stable, since we ask that the early review is 
done on the version of the document that will be received by the AD’s at the 
time of requested publication.

3.)While we require early review from the routing directorate, it is in the 
chair’s discretion if they wish to request early review from other 
directorates.  As a guideline, we recommend a security directorate review in 
addition to the routing area directorate.

We are still discussing all the feedback (and there was a lot of substantive 
feedback), so expect more from us in the coming weeks regarding the rest of the 
feedback.

Thanks

Andrew Alston (On Behalf of the Routing AD’s)




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

Re: [Lsr] RFC 8362 and LSInfinity

[Acee Lindem (acee)]

Hi Zhibo, 

On 10/13/22, 2:26 AM, "Lsr on behalf of Huzhibo"  wrote:

Hi LSR:

LSInfinity
The metric value indicating that the destination described by an
LSA is unreachable. Used in summary-LSAs and AS-external-LSAs

I want to clarify the meaning of unreachable in LSifinity, 
Assume that a node advertise specific route of 1.1.1.1/32, and an aggregate 
route 1.1.0.0/16 is configured.
This node should premature aging of the 1.1.1.1/32 LSA.
If this node using LSInfinity metric instead of prematuring aging, route 
1.1.1.1/32 is still reachable.
Therefore, the "unreachable" described by LSifinity is not really 
unreachable.

If your OSPF implementation includes unreachable LSAs in the summary cost 
computation, it is indeed broken.

Thanks,
Acee

Thanks
Zhibo hu

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Wednesday, October 5, 2022 5:32 PM
> To: lsr@ietf.org
> Subject: [Lsr] RFC 8362 and LSInfinity
> 
> 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

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

Re: [Lsr] RFC 8362 and LSInfinity

[Acee Lindem (acee)]

Hi Aijun, 

On 10/12/22, 9:58 AM, "Aijun Wang"  wrote:

Hi, Acee:

Let me give you one more concrete example:

The metric of one prefix P is set to 0xFE(not LSInfinity, it can also 
be other large value), and this prefix is attached at one router that has the 
link cost 1 to ABR, what the value for the ABR to advertise for this Prefixes P 
into other attached area as one summary prefix?

It's obvious you wouldn’t configure metrics that large unless you were trying 
to accomplish some prefix reachability scoping (which I wouldn't recommend by 
the way).
 
Acee

Aijun Wang
China Telecom

> On Oct 12, 2022, at 18:22, Acee Lindem (acee) 
 wrote:
> 
> 
> 
> On 10/12/22, 2:31 AM, "Lsr on behalf of Aijun Wang"  wrote:
> 
>Hi, Acee:
> 
>Let me state some points more clearly:
>1) The LSInfinity is defined almost 30 years, but it is not 
applied/deployed within the network about 30 years, why to deprecate it?
>2) RFC8362 say nothing about LSInifinity, only RFC5340 says it 
inherits the definition from RFC2328.
>3) It is problematic to define again the LSInifinity within RFC8362, 
as the value of 0xff, because the metric of the normal summary prefixes 
advertised by ABR may reach this predefined value.
> 
> This is not problematic. Only unreachable prefixes for an algorithm will 
have a metric of LSInfinity and will, hence, be unreachable and will not 
contribute to the cost of any summary prefixes. 
> 
> Thanks,
> Acee 
> 
>The most important point is that there is reasonable/sound reason to 
define such value for its special handling.
> 
>Best Regards
> 
>Aijun Wang
>China Telecom
    > 
    > 
>-Original Message-
>From: lsr-boun...@ietf.org  On Behalf Of Acee 
Lindem (acee)
>Sent: Tuesday, October 11, 2022 11:20 PM
>To: Peter Psenak (ppsenak) ; Aijun Wang 
; 'Ketan Talaulikar' 
>Cc: lsr@ietf.org
>Subject: Re: [Lsr] RFC 8362 and LSInfinity
> 
>Hi Aijun,
> 
>After almost 30 years, we're not going to deprecate OSPF LSInfinity 
based on your opinion. 
> 
>Please be specific as to what you feel is problematic with usage in 
the 24-bit metric in the E-Intra-Area-Prefix LSA.
> 
>Thanks,
>Acee
> 
>On 10/11/22, 12:09 AM, "Peter Psenak"  wrote:
> 
>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, 

Re: [Lsr] RFC 8362 and LSInfinity

[Acee Lindem (acee)]

On 10/12/22, 2:31 AM, "Lsr on behalf of Aijun Wang"  wrote:

Hi, Acee:

Let me state some points more clearly:
1) The LSInfinity is defined almost 30 years, but it is not 
applied/deployed within the network about 30 years, why to deprecate it?
2) RFC8362 say nothing about LSInifinity, only RFC5340 says it inherits the 
definition from RFC2328.
3) It is problematic to define again the LSInifinity within RFC8362, as the 
value of 0xff, because the metric of the normal summary prefixes advertised 
by ABR may reach this predefined value.

This is not problematic. Only unreachable prefixes for an algorithm will have a 
metric of LSInfinity and will, hence, be unreachable and will not contribute to 
the cost of any summary prefixes. 

Thanks,
Acee 

The most important point is that there is reasonable/sound reason to define 
such value for its special handling.

Best Regards

Aijun Wang
China Telecom


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

Hi Aijun,

After almost 30 years, we're not going to deprecate OSPF LSInfinity based 
on your opinion. 

Please be specific as to what you feel is problematic with usage in the 
24-bit metric in the E-Intra-Area-Prefix LSA.

Thanks,
Acee

On 10/11/22, 12:09 AM, "Peter Psenak"  wrote:

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
>>

Re: [Lsr] RFC 8362 and LSInfinity

[Acee Lindem (acee)]

Hi Aijun,

After almost 30 years, we're not going to deprecate OSPF LSInfinity based on 
your opinion. 

Please be specific as to what you feel is problematic with usage in the 24-bit 
metric in the E-Intra-Area-Prefix LSA.

Thanks,
Acee

On 10/11/22, 12:09 AM, "Peter Psenak"  wrote:

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 
<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...@iet

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

Re: [Lsr] RFC 8362 and LSInfinity

[Acee Lindem (acee)]

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 

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

___
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] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Acee Lindem (acee)]

Hi Tony,


From: Lsr  on behalf of Tony Li 
Date: Friday, October 7, 2022 at 11:21 AM
To: "Les Ginsberg (ginsberg)" 
Cc: Christian Hopps , "Peter Psenak (ppsenak)" 
, Robert Raszuk , Henk Smit 
, "lsr@ietf.org" 
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt


Les,


On Oct 7, 2022, at 8:16 AM, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
 wrote:

What I am trying to highlight is that the existing implementations of MP-TLVs 
for the "implicit" cases should not be penalized for sending MP-TLVs that are 
encoded consistent with how MP-TLVs for the "explicit" cases have been done. 
They are actually doing the right thing.

If we are in agreement on that - great!


I have no wish to penalize anyone.


You realize the latest version still has the statement:

   If all routers in an area advertise the Multi-part TLV Capability a
   node MAY advertise multi-part TLVs to increase space for payload
   values, unless otherwise specified by the TLV.

At a minimum, the draft should specify a configuration parameter dictating 
whether advertisement of the capability by all area IS-IS routers is required 
for advertisement. With this new parameter, my preference would be to then 
leave it to implementations as to the default value, i.e., beyond the scope of 
the document.

Thanks,
Acee


T

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

[Lsr] LSR Interim Meeting Minutes

[Acee Lindem (acee)]

All,

Please see the attached minutes from the LSR Interim on 9/21/2022 as long as 
the Meetecho chat log. Thanks to Yingzhen Qu for taking them.


  
https://datatracker.ietf.org/meeting/interim-2022-lsr-01/materials/minutes-interim-2022-lsr-01-202209211000-00.txt

Here are the complete meeting materials:

https://datatracker.ietf.org/meeting/interim-2022-lsr-01/session/lsr

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

Re: [Lsr] Martin Duke's Discuss on draft-ietf-lsr-ospf-reverse-metric-08: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

Hi Ketan, Alvaro,

From: Ketan Talaulikar 
Date: Thursday, October 6, 2022 at 8:10 AM
To: Alvaro Retana 
Cc: Martin Duke , "lsr@ietf.org" , 
Christian Hopps , Acee Lindem , 
"lsr-cha...@ietf.org" , The IESG , 
"draft-ietf-lsr-ospf-reverse-met...@ietf.org" 

Subject: Re: [Lsr] Martin Duke's Discuss on 
draft-ietf-lsr-ospf-reverse-metric-08: (with DISCUSS and COMMENT)

Hi Alvaro,

Please check inline below for response with KT2.

On Thu, Oct 6, 2022 at 4:42 PM Alvaro Retana 
mailto:aretana.i...@gmail.com>> wrote:
On October 6, 2022 at 5:44:57 AM, Ketan Talaulikar wrote:


Ketan:

Hi!


...
> KT> Added text in the security considerations that cover this issue as well
> as a proposed mitigation. Please let us know if that works.

This is the text that you added:

   A router that is misbehaving or misconfigured, may end up signaling
   varying values of reserve metrics or toggle the state of reserve
   metric.  This can result in a neighbor router having to frequently
   update its Router LSA causing network churn and instability despite
   the LSA rate-limiting behavior in the OSPF protocol.  It is
   RECOMMENDED that implementations support the detection of frequent
   changes in reverse metric signaling and ignore the reserve metric
   (i.e., revert to using their provisioned metric value) during such
   conditions.


Monitoring the changes is the right mitigation.  But the description
of how it would be done is not specific -- for a normative
recommendation.

As I think about this, it occurs to me that even though the originator
of the RM is not sending an LSA, this is an "IGP event", as described
in rfc8405.  Receiving the RM should trigger an SPF and the updated
Router LSA should also trigger SPF events elsewhere.

   IGP event: The reception or origination of an IGP LSDB change
   requiring a new routing table computation.  Some examples are a
   topology change, a prefix change, and a metric change on a link or
   prefix.  Note that locally triggering a routing table computation is
   not considered an IGP event since other IGP routers are unaware of
   this occurrence.


The same back-off mechanism from rfc8405 should be required in this case.

KT2> Indeed I was referencing RFC8405 but indirectly. Let us get into the 
details. The reception of RM changes the operational value of its local link 
metric. However, this MUST NOT be seen as an IGP Event that directly triggers 
the SPF on the neighbor. What needs to happen is that this metric change should 
trigger an update of the Router LSA (which is subject to rate-limiting - 
MinLSInterval). This Router LSA change would then be the one that triggers the 
SPF event subject to the back-off and details in RFC8405. This is the base 
protocol behavior - we are not changing anything here. Directly triggering 
local SPF on RM changes can result in aggravating microloops.

I agree with Ketan. This behavior doesn’t need to be respecified and explicit 
specification is most likely missing from existing RFCs for protocols 
mechanisms modify LSAs.

Thanks,
Acee

KT2> The recommendation was to ignore RM - i.e., suspend the RM feature during 
instability and revert to using the provisioned metric.

Thanks,
Ketan



Thanks!

Alvaro.
___
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)

[Acee Lindem (acee)]

Hi Dhruv,
Thanks for the quick turnaround. It looks good to me. One nit, I believe a 
period was added to “However, as noted in [RFC6952].,” by mistake.
Thanks,
Acee

From: Lsr  on behalf of Dhruv Dhody 
Date: Wednesday, October 5, 2022 at 9:06 AM
To: Lars Eggert 
Cc: The IESG , 
"draft-ietf-lsr-pce-discovery-security-supp...@ietf.org" 
, "lsr-cha...@ietf.org" 
, "lsr@ietf.org" , Acee Lindem 
, "p...@ietf.org" , "Les Ginsberg (ginsberg)" 
, Adrian Farrel , John Scudder 
, Roman Danyliw 
Subject: Re: [Lsr] Lars Eggert's Discuss on 
draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

Hi all,

I have incorporated changes suggested by Les and Acee in the working copy 
maintained at -

TXT - 
https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-lsr-pce-discovery-security-support-12.txt
DIFF - 
https://www.ietf.org/rfcdiff?url1=draft-ietf-lsr-pce-discovery-security-support-11&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-lsr-pce-discovery-security-support-12.txt

Also, see inline...


On Fri, Sep 30, 2022 at 5:57 PM Lars Eggert via Datatracker 
mailto:nore...@ietf.org>> 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://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:
--

# 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?

Dhruv: Updated to Standards Action.



--
COMMENT:
--

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `master`; alternatives might be `active`, `central`, `initiator`,
   `leader`, `main`, `orchestrator`, `parent`, `primary`, `server`

Dhruv: The term appears in reference to an existing term defined in another RFC.

  KeyID: The one octet Key ID as per [RFC5925] to uniquely identify
  the Master Key Tuple (MKT).

Not sure how I can avoid using the term.


 * Term `man`; alternatives might be `individual`, `people`, `person`

Dhruv: Updated (as also suggested by Roman)


## Nits

All comments below are about very minor potential issues that you may choose to
addres

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: (with COMMENT)

[Acee Lindem (acee)]

Hi John, 

On 10/5/22, 11:18 AM, "Lsr on behalf of John Scudder"  wrote:

Hi Acee,

> On Oct 4, 2022, at 12:57 PM, Acee Lindem (acee) 
 wrote:
> 
>> From: "Rob Wilton (rwilton)" 
...
>> Is there somewhere for these new config knobs are being tracked - so 
that they don’t get forgotten?
>  
> We have the Datatracker for that…

I don’t follow — what datatracker feature are you thinking of using to keep 
track of the fact that draft-ietf-lsr-ospf-l2bundles said “hey this should be 
configurable with YANG” but didn’t actually specify the YANG? 

I mean we have the new RFCs in the data tracker - one would still need to do a 
gap analysis when updating the augmentations. First order of business is to 
publish the base drafts... 

Thanks,
Acee



Thanks,

—John
___
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] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

That would be good for me as well. Given the discussion that is going on 
regarding YANG string lengths in NETMOD, it might also be good to limit the 
key-chain name to 255 characters as we did for the dynamic hostname in RFC 5301 
and RFC 5642. 

Thanks,
Acee

On 10/5/22, 4:13 AM, "Adrian Farrel"  wrote:

Yeah, I like that suggestion.
A

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: 04 October 2022 20:43
To: John Scudder 
    Cc: Acee Lindem (acee) ; Lars Eggert ; The 
IESG ; draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; 
lsr-cha...@ietf.org; lsr ; p...@ietf.org; Hannes Gredler 
; JP Vasseur (jvasseur) ; 
meral.shirazip...@polymtl.ca; Adrian Farrel 
Subject: RE: [Lsr] Lars Eggert's Discuss on 
draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

John -

So you are suggesting that Section 4 of the draft be modified to say:

"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.
If in the future new advertisements are required, alternative mechanisms 
such as using [RFC6823] or 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/ should 
be considered."

(or similar...)

I am fine with that.

   Les


> -Original Message-
> From: John Scudder 
> Sent: Tuesday, October 4, 2022 12:31 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Acee Lindem (acee) ; Lars Eggert ;
> The IESG ; draft-ietf-lsr-pce-discovery-security-
> supp...@ietf.org; lsr-cha...@ietf.org; lsr ; p...@ietf.org;
> Hannes Gredler ; JP Vasseur (jvasseur)
> ; meral.shirazip...@polymtl.ca; Adrian Farrel
> 
> Subject: Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-
> security-support-11: (with DISCUSS and COMMENT)
> 
> Hi Les,
> 
> Thanks, that’s helpful. One comment, regarding
> 
> > Hard for me to justify modifying RFC 5088/5089 simply to add a pointer 
to
> GENINFO/OSPF-GT even if such an addition might be relevant.
> 
> what I was actually suggesting was that the paragraph in 
draft-ietf-lsr-pce-
> discovery-security-support could be updated to add the pointer. Since 
draft-
> ietf-lsr-pce-discovery-security-support formally updates RFCs 5088/5089,
> that would establish at least some mechanism less unreliable than trolling
> through old mailing lists, to help a new implementor find this old 
history,
> while still not requiring us to do the heavy lift of bis’ing 5088/5089 
(which I
> agree would be crazy to do just for this).
> 
> —John
> 
> > On Oct 4, 2022, at 3:24 PM, Les Ginsberg (ginsberg) 
> wrote:
> >
> > John -
> >
> > Thanx for finding the old email thread.
> > Folks also might want to look at this thread:
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr/Nhe
> zQqKwIvHK_9dDUmW0iuhyjDA/__;!!NEt6yMaO-gk!BsexV0igrfCC6797R-
> 5WEj654ycPt6DwvDJJ9cKMToAWSjm6GzCfKem3ylr0c4DezgdzY3N-mB2epg$
> >
> > In summary, I raised these points when the draft was adopted - but
> eventually agreed to allow the draft to go forward.
> >
> > The intent of the restrictions in RFC5088/5089 is to discourage carrying
> additional "non-routing" information in the IGPs.
> > The practical matter in this case is that trying to advertise the 
additional
> information using some other mechanism is quite costly and awkward. The
> fact that the additional information are sub-sub-TLVs of the PCED sub-TLV
> speaks to the coupling of the new information with the existing 
information.
> >
> > I think we want to keep restrictions in place so as to discourage new
> advertisements, but recognize that we compromise when it seems practical.
> This isn’t ideal - and I understand why Lars would want to discuss this - 
but I
> don't have a cleaner solution.
> > The fact that we introduced PCE advertisements into the IGPs in the 
first
> place makes it difficult to adhere to the restrictions for PCE related
> advertisements.
> >
> > Section 4 of the draft states:
> >
> > "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 def

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

[Acee Lindem (acee)]

Speaking as long-time LSR/OSPF WG Member and Co-author of RFC 4970 and RFC 
7770: 

When RFC 5088 was being standardized, there was concern over both advertising 
non-routing information in OSPF and exceeding the maximum size of an OSPF 
Router Information LSA which was limited to a single LSA instance per OSPF 
router (RFC 4970).  The controversial statement below was added to assuage 
these concerns. With the publication of RFC 7770, an OSPF router can advertise 
multiple Router Instance LSAs with different instance IDs. At the same time, we 
have evolved to using Router Instance LSAs for limited capability information 
associated with routing applications (e.g., PCE). For non-routing information 
or advertising more information without impacting unicast routing, I'd 
recommend OSPF-GT 
(https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/).  

Thanks,
Acee

On 10/4/22, 1:29 PM, "John Scudder"  wrote:

Hi Everyone,

+Adrian since he appears to have been the shepherd for RFC 5088, which is 
the root of Lars’ DISCUSS.
+Hannes, Les, JP, Meral as people who may have more context on the question

Since I haven’t seen any replies to this DISCUSS yet I did a little 
digging. The text in question:

   No additional sub-TLVs will be added to the PCED TLV in the future.
   If a future application requires the advertisement of additional PCE
   information in OSPF, this will not be carried in the Router
   Information LSA.

Was introduced in draft-ietf-pce-disco-proto-ospf-07, September 2007. 
Checking in the archives, I see one relevant mail thread: 
https://mailarchive.ietf.org/arch/msg/pce/UERk8vF5e7cFQoblkDAVA74Ojh0/ is the 
beginning, but then it seems to have been indexed wrong so you should continue 
from here: 
https://mailarchive.ietf.org/arch/msg/isis-wg/BpUVKsjr46ha9kbF3jwgKyymEBo/ to 
pick up Les’s reply as well. There are four relevant messages in total, from 
Meral Shirazipour, JP Vasseur, Hannes Gredler, and Les Ginsberg.

Rather than try to summarize I’m going to ask people to go look at the 
short mail thread for themselves. Perhaps this will jog people’s memories 
enough to allow a discussion on why we’re opening a registry for new code 
points that was explicitly defined as being closed.

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? Th

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: (with COMMENT)

[Acee Lindem (acee)]

Hi Rob,

From: "Rob Wilton (rwilton)" 
Date: Tuesday, October 4, 2022 at 11:51 AM
To: Acee Lindem , Ketan Talaulikar 
Cc: The IESG , "draft-ietf-lsr-ospf-l2bund...@ietf.org" 
, "lsr-cha...@ietf.org" 
, "lsr@ietf.org" , Christian Hopps 

Subject: RE: Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: 
(with COMMENT)

Hi Acee, Ketan,

One other alternative could be to add an Informative reference to the base OSPF 
YANG module (that is about to be an RFC), and indicate that the configuration 
is expected to be an update or augmentation to that base OSPF YANG module?

That would be better.

Is there somewhere for these new config knobs are being tracked - so that they 
don’t get forgotten?

We have the Datatracker for that…

Thanks,
Acee

Thanks,
Rob



From: Acee Lindem (acee) 
Sent: 04 October 2022 16:13
To: Ketan Talaulikar 
Cc: Rob Wilton (rwilton) ; The IESG ; 
draft-ietf-lsr-ospf-l2bund...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; 
cho...@chopps.org
Subject: Re: Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: 
(with COMMENT)

Hi Ketan,

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Tuesday, October 4, 2022 at 10:44 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "Rob Wilton (rwilton)" mailto:rwil...@cisco.com>>, The 
IESG mailto:i...@ietf.org>>, 
"draft-ietf-lsr-ospf-l2bund...@ietf.org<mailto:draft-ietf-lsr-ospf-l2bund...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-l2bund...@ietf.org>>,
 "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
Christian Hopps mailto:cho...@chopps.org>>
Subject: Re: Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: 
(with COMMENT)
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, Christian Hopps 
mailto:cho...@chopps.org>>, Acee Lindem 
mailto:a...@cisco.com>>
Resent-Date: Tuesday, October 4, 2022 at 10:44 AM

Hi Acee,

Thanks for your quick response.

My question was : Can we put an informative reference to  
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/  (of 
which you are co-author) in the OSPF L2 Bundles draft?

This assumes that an upcoming version of this augmentation-v1 draft will cover 
the configuration/enablement of this feature.

We also would need to update the Link State Database for the advertisement of 
the individual links. I think you can just say a future YANG draft as the 
reference Is not mandatory.

Thanks,
Acee



Thanks.
Ketan


On Tue, Oct 4, 2022 at 8:07 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Ketan,

See inlie.

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Tuesday, October 4, 2022 at 10:23 AM
To: "Rob Wilton (rwilton)" mailto:rwil...@cisco.com>>
Cc: The IESG mailto:i...@ietf.org>>, 
"draft-ietf-lsr-ospf-l2bund...@ietf.org<mailto:draft-ietf-lsr-ospf-l2bund...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-l2bund...@ietf.org>>,
 "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
Christian Hopps mailto:cho...@chopps.org>>, Acee Lindem 
mailto:a...@cisco.com>>
Subject: Re: Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: 
(with COMMENT)

Hi Rob,

Thanks for your review and please check inline below for responses.

The updates as discussed below will be included in the next update.


On Tue, Oct 4, 2022 at 3:14 PM Robert Wilton via Datatracker 
mailto:nore...@ietf.org>> wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ospf-l2bundles-06: 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-l2bundles/



--
COMMENT:
--

Hi,

I support Lars's discuss.

I don't really object to publishing this document, although I don't really like
the fact that the LAG member information that is being propagated isn't of any
relevance to OSPF routing itself, and OSPF is being used only as a generic
information propagation mechanism.  However, I acknowledge that horse has
probably bolted long ago.

KT> What

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: (with COMMENT)

[Acee Lindem (acee)]

Hi Ketan,

From: Ketan Talaulikar 
Date: Tuesday, October 4, 2022 at 10:44 AM
To: Acee Lindem 
Cc: "Rob Wilton (rwilton)" , The IESG , 
"draft-ietf-lsr-ospf-l2bund...@ietf.org" 
, "lsr-cha...@ietf.org" 
, "lsr@ietf.org" , Christian Hopps 

Subject: Re: Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: 
(with COMMENT)
Resent-From: 
Resent-To: Yingzhen Qu , Christian Hopps 
, Acee Lindem 
Resent-Date: Tuesday, October 4, 2022 at 10:44 AM

Hi Acee,

Thanks for your quick response.

My question was : Can we put an informative reference to  
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/  (of 
which you are co-author) in the OSPF L2 Bundles draft?

This assumes that an upcoming version of this augmentation-v1 draft will cover 
the configuration/enablement of this feature.

We also would need to update the Link State Database for the advertisement of 
the individual links. I think you can just say a future YANG draft as the 
reference Is not mandatory.

Thanks,
Acee



Thanks.
Ketan


On Tue, Oct 4, 2022 at 8:07 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Ketan,

See inlie.

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Tuesday, October 4, 2022 at 10:23 AM
To: "Rob Wilton (rwilton)" mailto:rwil...@cisco.com>>
Cc: The IESG mailto:i...@ietf.org>>, 
"draft-ietf-lsr-ospf-l2bund...@ietf.org<mailto:draft-ietf-lsr-ospf-l2bund...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-l2bund...@ietf.org>>,
 "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
Christian Hopps mailto:cho...@chopps.org>>, Acee Lindem 
mailto:a...@cisco.com>>
Subject: Re: Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: 
(with COMMENT)

Hi Rob,

Thanks for your review and please check inline below for responses.

The updates as discussed below will be included in the next update.


On Tue, Oct 4, 2022 at 3:14 PM Robert Wilton via Datatracker 
mailto:nore...@ietf.org>> wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ospf-l2bundles-06: 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-l2bundles/



--
COMMENT:
--

Hi,

I support Lars's discuss.

I don't really object to publishing this document, although I don't really like
the fact that the LAG member information that is being propagated isn't of any
relevance to OSPF routing itself, and OSPF is being used only as a generic
information propagation mechanism.  However, I acknowledge that horse has
probably bolted long ago.

KT> What we are doing here is adding more information for use in the TE-DB that 
is related to OSPF adjacencies. Originally, Opaque LSAs were introduced in OSPF 
for carrying additional info for TE-DB - even though that info was not really 
consumed by OSPF protocol. I can understand that "the line" may be blurred in 
this respect.


One point that is not clear to me, is the configuration/management of this
feature:  Is the expectation that OSPF implementations that support this RFC
would automatically propagate bundle member information? Or would this be
disabled by default and need to be enabled through configuration?

KT> There should not be automatic enablement. It needs to be enabled via 
configuration. We will add an Operational Considerations section to clarify 
this with the following text added:


Implementations MUST NOT enable the advertisement of Layer 2 bundle member 
links and their attributes in OSPF LSAs by default and MUST provide a 
configuration option to enable their advertisement on specific links.


 If there is
configuration associated with this feature then would it be part of a updated
version of the standard OSPF YANG model, or is it via YANG module augmentation
to the base OSPF YANG module?

KT> I would expect the enablement to be an augmentation to the base OSPF YANG 
model.

If this is configurable then having an
informational reference to how/where this OSPF feature can be configured would
likely be helpful.

KT> We do not currently have this covered. I believe this can be added in 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/ - 
however, this is not somethi

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: (with COMMENT)

[Acee Lindem (acee)]

Hi Ketan,

See inlie.

From: Ketan Talaulikar 
Date: Tuesday, October 4, 2022 at 10:23 AM
To: "Rob Wilton (rwilton)" 
Cc: The IESG , "draft-ietf-lsr-ospf-l2bund...@ietf.org" 
, "lsr-cha...@ietf.org" 
, "lsr@ietf.org" , Christian Hopps 
, Acee Lindem 
Subject: Re: Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: 
(with COMMENT)

Hi Rob,

Thanks for your review and please check inline below for responses.

The updates as discussed below will be included in the next update.


On Tue, Oct 4, 2022 at 3:14 PM Robert Wilton via Datatracker 
mailto:nore...@ietf.org>> wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ospf-l2bundles-06: 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-l2bundles/



--
COMMENT:
--

Hi,

I support Lars's discuss.

I don't really object to publishing this document, although I don't really like
the fact that the LAG member information that is being propagated isn't of any
relevance to OSPF routing itself, and OSPF is being used only as a generic
information propagation mechanism.  However, I acknowledge that horse has
probably bolted long ago.

KT> What we are doing here is adding more information for use in the TE-DB that 
is related to OSPF adjacencies. Originally, Opaque LSAs were introduced in OSPF 
for carrying additional info for TE-DB - even though that info was not really 
consumed by OSPF protocol. I can understand that "the line" may be blurred in 
this respect.


One point that is not clear to me, is the configuration/management of this
feature:  Is the expectation that OSPF implementations that support this RFC
would automatically propagate bundle member information? Or would this be
disabled by default and need to be enabled through configuration?

KT> There should not be automatic enablement. It needs to be enabled via 
configuration. We will add an Operational Considerations section to clarify 
this with the following text added:


Implementations MUST NOT enable the advertisement of Layer 2 bundle member 
links and their attributes in OSPF LSAs by default and MUST provide a 
configuration option to enable their advertisement on specific links.


 If there is
configuration associated with this feature then would it be part of a updated
version of the standard OSPF YANG model, or is it via YANG module augmentation
to the base OSPF YANG module?

KT> I would expect the enablement to be an augmentation to the base OSPF YANG 
model.

If this is configurable then having an
informational reference to how/where this OSPF feature can be configured would
likely be helpful.

KT> We do not currently have this covered. I believe this can be added in 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/ - 
however, this is not something that has been discussed in the WG or with the 
authors of this document.

Acee/Yingzhen, if you agree that the OSPF YANG augmentation draft can cover 
this, then we can add a reference in this document.

The OSPF YANG model (as has been the case with all the protocol YANG models) 
has been a moving target for years in terms of features, YANG types, and YANG 
conventions. At this point, it will soon be published as RFC 9129. New features 
will be included in follow-on drafts including 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/ 
which would be a better reference.

Thanks,
Acee


Thanks,
Ketan


Regards,
Rob


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

Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-ospf-l2bundles-06: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

Hi Ketan, et al,

From: Ketan Talaulikar 
Date: Tuesday, October 4, 2022 at 4:34 AM
To: Lars Eggert 
Cc: The IESG , "draft-ietf-lsr-ospf-l2bund...@ietf.org" 
, "lsr-cha...@ietf.org" 
, "lsr@ietf.org" , Christian Hopps 
, Acee Lindem , John Scudder 

Subject: Re: Lars Eggert's Discuss on draft-ietf-lsr-ospf-l2bundles-06: (with 
DISCUSS and COMMENT)
Resent-From: 
Resent-To: Yingzhen Qu , Acee Lindem , 
Christian Hopps 
Resent-Date: Tuesday, October 4, 2022 at 4:34 AM

Hi Lars,

Thanks for your confirmation.

Acee/John, I haven't received any response (objection or support) from the WG 
on this change. I believe this may be a good interim step until the WG 
considers any IANA registry reorganization. Can you please share your views as 
shepherd and AD respectively?

The text below looks good to me.

Thanks,
Acee

Thanks,
Ketan


On Mon, Oct 3, 2022 at 6:31 PM Lars Eggert 
mailto:l...@eggert.org>> wrote:
Hi,

On 2022-9-30, at 16:37, Ketan Talaulikar 
mailto:ketant.i...@gmail.com>> wrote:
> In brief, the proposal was to introduce the following text in the IANA 
> considerations:
>
> 
>This document updates the guidance to IANA for further allocations
>from the "OSPFv2 Extended Link TLV Sub-TLVs" [1] and the
>"OSPFv3 Extended LSA Sub-TLVs" [2] registries and requests the addition
>of this document as a reference to those registries. It requires
>that any document requesting allocation of code point from these
>two registries need to indicate the applicability of the introduced
>sub-TLV to the L2 Bundle Member TLV in that document.

something along those lines would work for me.

Thanks,
Lars

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

Re: [Lsr] ietf-o...@2019-10-17.yang: questions

[Acee Lindem (acee)]

Hi Renato,

From: Renato Westphal 
Date: Friday, September 30, 2022 at 10:34 AM
To: Acee Lindem 
Cc: "draft-ietf-ospf-y...@ietf.org" , 
"lsr@ietf.org" 
Subject: Re: ietf-o...@2019-10-17.yang: questions



Em sex., 30 de set. de 2022 às 11:21, Acee Lindem (acee) 
mailto:a...@cisco.com>> escreveu:
Hi Renato,

Thanks - see inline.

On 9/30/22, 10:14 AM, "Renato Westphal" 
mailto:renatowestp...@gmail.com>> wrote:

Hi Acee,

Em sex., 30 de set. de 2022 às 09:32, Acee Lindem (acee) 
mailto:a...@cisco.com>>
escreveu:

> Hi Renato,
>
>
>
> *From: *Renato Westphal 
mailto:renatowestp...@gmail.com>>
> *Date: *Thursday, September 29, 2022 at 7:56 PM
> *To: *Acee Lindem mailto:a...@cisco.com>>
> *Cc: 
*"draft-ietf-ospf-y...@ietf.org<mailto:draft-ietf-ospf-y...@ietf.org>" 
mailto:draft-ietf-ospf-y...@ietf.org>>, "
> lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
> *Subject: *Re: ietf-o...@2019-10-17.yang: questions
>
>
>
> Hi Acee,
    >
> Thanks for your response. Please see my inline comments below.
>
>
>
> Em qua., 7 de set. de 2022 às 18:05, Acee Lindem (acee) 
mailto:a...@cisco.com>>
> escreveu:
>
> Thanks for you comments. However, at this point in the cycle, we’re not
> going to make any additions to the model since it is has already been
> through the complete review cycle. We will however fix things that are
> broken.
>
>
>
> Understood. I only have a couple of additional comments for things that
> might be worth fixing before the RFC is released:
>
>
> 1.
> 
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/areas/area/interfaces/interface/interface-id
>
> This leaf's type should be u32 and not u16.
>
>
>
> Ack.
>
>
>
> 2.
> 
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/database/as-scope-lsa-type/as-scope-lsas/as-scope-lsa/ospfv3/body/intra-area-prefix/prefixes/prefix/metric
>
> This leaf's type should be u16 and not "ospf-metric" (u32).
>
>
>
> No – ospf-metric type is correct with the range limiting the metric to 24
> bits.
>

While uint32 isn't a problem per-se, using uint16 would be more precise
since the Metric field of Intra-Area-Prefix LSAs is 16-bits wide. The
"metric" leaf of Router-LSAs uses uint16 for instance. Only Summary and
External LSAs need 24-bit wide metrics. But I think it's ok to leave it as
it is.

See https://www.rfc-editor.org/rfc/rfc5340.html#appendix-A.4.5

I was referring to Intra (and not Inter) Area-Prefix-LSAs (section A.4.10). I 
found this problem using a strongly-typed programming language that doesn't 
accept implicit type conversions.

Ok – I see it now.

Thanks,
Acee




>
>
> 3. While the "lls" feature is present in the model, the
> "ospfv2-lsa-option" base identity is missing an identity for the L-Bit
> specified by RFC 5613. While that could be added via augmentation, I think
> it would make sense to have an "l-bit" identity as part of the base model


Also, I'm considering the next-hop list change to keyless you suggested.  If it 
is not too late as I thought of a case where next-hop address is not unique. 
That case being parallel equal-cost unnumbered links between two OSPF routers 
where the routers use the same borrowed loopback address for all the parallel 
links, Sigh...

Indeed. If it's not too late I think it would be a good change.

Best Regards,
--
Renato Westphal
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] ietf-o...@2019-10-17.yang: questions

[Acee Lindem (acee)]

Hi Renato, 

Thanks - see inline. 

On 9/30/22, 10:14 AM, "Renato Westphal"  wrote:

Hi Acee,

Em sex., 30 de set. de 2022 às 09:32, Acee Lindem (acee) 
escreveu:

> Hi Renato,
>
>
>
> *From: *Renato Westphal 
> *Date: *Thursday, September 29, 2022 at 7:56 PM
> *To: *Acee Lindem 
> *Cc: *"draft-ietf-ospf-y...@ietf.org" , "
> lsr@ietf.org" 
> *Subject: *Re: ietf-o...@2019-10-17.yang: questions
>
>
>
> Hi Acee,
>
> Thanks for your response. Please see my inline comments below.
>
>
>
> Em qua., 7 de set. de 2022 às 18:05, Acee Lindem (acee) 
> escreveu:
>
> Thanks for you comments. However, at this point in the cycle, we’re not
> going to make any additions to the model since it is has already been
> through the complete review cycle. We will however fix things that are
> broken.
>
>
>
> Understood. I only have a couple of additional comments for things that
> might be worth fixing before the RFC is released:
>
>
> 1.
> 
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/areas/area/interfaces/interface/interface-id
>
> This leaf's type should be u32 and not u16.
>
>
>
> Ack.
>
>
>
> 2.
> 
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/database/as-scope-lsa-type/as-scope-lsas/as-scope-lsa/ospfv3/body/intra-area-prefix/prefixes/prefix/metric
>
> This leaf's type should be u16 and not "ospf-metric" (u32).
>
>
>
> No – ospf-metric type is correct with the range limiting the metric to 24
> bits.
>

While uint32 isn't a problem per-se, using uint16 would be more precise
since the Metric field of Intra-Area-Prefix LSAs is 16-bits wide. The
"metric" leaf of Router-LSAs uses uint16 for instance. Only Summary and
External LSAs need 24-bit wide metrics. But I think it's ok to leave it as
it is.

See https://www.rfc-editor.org/rfc/rfc5340.html#appendix-A.4.5



>
>
> 3. While the "lls" feature is present in the model, the
> "ospfv2-lsa-option" base identity is missing an identity for the L-Bit
> specified by RFC 5613. While that could be added via augmentation, I think
> it would make sense to have an "l-bit" identity as part of the base model


Also, I'm considering the next-hop list change to keyless you suggested.  If it 
is not too late as I thought of a case where next-hop address is not unique. 
That case being parallel equal-cost unnumbered links between two OSPF routers 
where the routers use the same borrowed loopback address for all the parallel 
links, Sigh... 

Thanks,
Acee




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

Re: [Lsr] ietf-o...@2019-10-17.yang: questions

[Acee Lindem (acee)]

Hi Renato,

From: Renato Westphal 
Date: Thursday, September 29, 2022 at 7:56 PM
To: Acee Lindem 
Cc: "draft-ietf-ospf-y...@ietf.org" , 
"lsr@ietf.org" 
Subject: Re: ietf-o...@2019-10-17.yang: questions

Hi Acee,

Thanks for your response. Please see my inline comments below.

Em qua., 7 de set. de 2022 às 18:05, Acee Lindem (acee) 
mailto:a...@cisco.com>> escreveu:
Thanks for you comments. However, at this point in the cycle, we’re not going 
to make any additions to the model since it is has already been through the 
complete review cycle. We will however fix things that are broken.

Understood. I only have a couple of additional comments for things that might 
be worth fixing before the RFC is released:

1. 
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/areas/area/interfaces/interface/interface-id

This leaf's type should be u32 and not u16.

Ack.


2. 
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/database/as-scope-lsa-type/as-scope-lsas/as-scope-lsa/ospfv3/body/intra-area-prefix/prefixes/prefix/metric

This leaf's type should be u16 and not "ospf-metric" (u32).

No – ospf-metric type is correct with the range limiting the metric to 24 bits.


3. While the "lls" feature is present in the model, the "ospfv2-lsa-option" 
base identity is missing an identity for the L-Bit specified by RFC 5613. While 
that could be added via augmentation, I think it would make sense to have an 
"l-bit" identity as part of the base model.

The L-bit is never set in an LSA so it is not needed.

https://www.rfc-editor.org/rfc/rfc5613.html#section-2.1

Should we ever add operational state with the options received, it would be 
needed and could be added in that augmentation.



4. 
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/areas/area/interfaces/interface/neighbors/neighbor/cost

Shouldn't the description be updated to include NBMA networks in addition to 
p2mp and hybrid networks?

No. You only have a single cost for an NBMA network.

5. 
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/local-rib/route/next-hops/next-hop

This list is keyed by the `next-hop` leaf, which is an IP address. Given that 
directly connected routes don't have an IP address, shouldn't this be a keyless 
list instead?

Since the local RIB only contains OSPF routes, they always have a next-hop.

I was referring to the local RIB, where OSPF connected routes are calculated as 
a "byproduct" of the SPF algorithm. Example: https://pastebin.com/raw/zyDASfm2 
(the connected routes are the ones without nexthops).

In any case, section 16.1.1 of RFC 2328 says that nexthop addresses aren't 
required for point-to-point interfaces. So I'm still wondering whether a 
keyless list wouldn't be a better option.

A next-hop of zero is used in those cases.

Thanks,
Acee

Best Regards,
--
Renato Westphal
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Last Call: (IS-IS Flood Reflection) to Experimental RFC

[Acee Lindem (acee)]

Hi Tom, 

On 9/28/22, 5:41 AM, "tom petch"  wrote:

On 26/09/2022 18:02, The IESG wrote:
>
> The IESG has received a request from the Link State Routing WG (lsr) to
> consider the following document: - 'IS-IS Flood Reflection'
> as Experimental RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits 
final
> comments on this action. Please send substantive comments to the
> last-c...@ietf.org mailing lists by 2022-10-10. Exceptionally, comments 
may
> be sent to i...@ietf.org instead. In either case, please retain the 
beginning
> of the Subject line to allow automated sorting.

I am confused by s.8.3 as introduced at AD Review for IANA Considerations.

It specifies a new registry with a name that starts 'Sub-sub TLVs for 
Flood''under the "IS-IS TLV Codepoints" Grouping.

Here is the grouping of related registries. Maybe the confusion is that since 
it is multiple registries, it doesn't show up as a link in 
https://www.iana.org/protocols

https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#tlv-codepoints

Thanks,
Acee

Grouping is not a term I recognise.  IANA have just responded to a Last 
Call comment on dnsop-dnssec-bcp to clarify that the preferred 
terminology is registry and registry group; I cannot recall seeing 
'grouping' being used.

Further, I cannot see IS-IS TLV Codepoints in any form.

IS-IS is one of those rare protocols whose IANA registry are all 
together under a group with an obvious name so while this I-D does not 
mention the group name, it is one of those rare cases when that should 
not be a problem.

Second, there are several existing registry of Sub-Sub TLVs so Sub-Sub 
would seem better - I do note that RFC8401 which created Sub-Sub-TLVs 
for BIER uses sub-sub!

But the significant point is that I do not understand the reference in 
the Registration Procedures to common expert review guidance for the 
grouping since I do not know what is meant by a grouping.

Tom Petch



















>
> Abstract
>
>
> This document describes a backward-compatible, optional IS-IS
> extension that allows the creation of IS-IS flood reflection
> topologies.  Flood reflection permits topologies in which L1 areas
> provide transit forwarding for L2 using all available L1 nodes
> internally.  It accomplishes this by creating L2 flood reflection
> adjacencies within each L1 area.  Those adjacencies are used to flood
> L2 LSPDUs and are used in the L2 SPF computation.  However, they are
> not ordinarily utilized for forwarding within the flood reflection
> cluster.  This arrangement gives the L2 topology significantly better
> scaling properties than traditionally used flat designs.  As an
> additional benefit, only those routers directly participating in
> flood reflection are required to support the feature.  This allows
> for incremental deployment of scalable L1 transit areas in an
> existing, previously flat network design, without the necessity of
> upgrading all routers in the network.
>
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reflection/
>
>
> The following IPR Declarations may be related to this I-D:
>
> https://datatracker.ietf.org/ipr/4186/
> https://datatracker.ietf.org/ipr/5807/
>
>
>
>
>
>
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>

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

Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-lsr-isis-rfc5316bis-04: (with DISCUSS)

[Acee Lindem (acee)]

Hi Les, 

On 9/24/22, 5:59 PM, "Les Ginsberg (ginsberg)"  wrote:

Acee -

Thanx for the quick review/suggestions.

Note that I used the name of the TLV as shown in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#tlv-codepoints
 - which differs from what is in the text of RFC 5308.

There seems to be inconsistency in the registry with respect to abbreviating 
"Interface" with "Intf." and "Address" with "Addr." I'd avoid the abbreviations 
in future documents. 

Happy to replace "global IPv6 Interface Address" with "non-link-local IPv6 
address" - but let's wait for Alvaro's response in case he wants further 
changes.
Sure.

Thanks,
Acee

   Les


> -Original Message-
> From: Acee Lindem (acee) 
> Sent: Saturday, September 24, 2022 2:36 PM
> To: Les Ginsberg (ginsberg) ; Alvaro Retana
> ; The IESG 
> Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr-cha...@ietf.org; 
lsr@ietf.org;
> cho...@chopps.org; t...@ietf.org; Rob Wilton (rwilton)
> ; Eric Vyncke (evyncke) ; Lars
> Eggert ; Paul Wouters 
> Subject: Re: Alvaro Retana's Discuss on 
draft-ietf-lsr-isis-rfc5316bis-04: (with
> DISCUSS)
> 
> Hi Les,
> 
> Looks good. See one suggestion.
> 
> On 9/24/22, 5:23 PM, "Les Ginsberg (ginsberg)" 
> wrote:
> 
> Alvaro -
> 
> I have given your comments regarding clearer guidance on what value to
> use for router id more thought and tried to address this in V5 of the
> document (recently posted).
> 
> I introduced a new sub-section "Choosing the TE Router ID Value",
> discussing how to choose the value for IPv4 and IPv6.
> 
> Consistent with the terminology in RFC 5308, I'd use " IPv6 Interface 
Address
> TLV" and " non-link-local IPv6 address" in the second paragraph.
> 
> Thanks,
> Acee
> 
> Subsequent sections now refer to this section.
> 
> Note that V5 also addresses comments from:
> 
> Rob Wilton
> Eric Vyncke
> Lars Eggert
> Paul Wouters
> 
> Let me know if you still have concerns.
> 
> Les
> 
> > -Original Message-
> > From: Les Ginsberg (ginsberg) 
> > Sent: Tuesday, September 20, 2022 9:30 PM
> > To: Alvaro Retana ; The IESG 
> > Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr-cha...@ietf.org; 
lsr@ietf.org;
> > cho...@chopps.org; t...@ietf.org
> > Subject: RE: Alvaro Retana's Discuss on 
draft-ietf-lsr-isis-rfc5316bis-04:
> (with
> > DISCUSS)
> >
> > Alvaro -
> >
> > Please see inline.
> >
> > > -Original Message-
> > > From: Alvaro Retana via Datatracker 
> > > Sent: Thursday, September 15, 2022 6:06 AM
> > > To: The IESG 
> > > Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr-cha...@ietf.org;
> lsr@ietf.org;
> > > cho...@chopps.org; t...@ietf.org
> > > Subject: Alvaro Retana's Discuss on 
draft-ietf-lsr-isis-rfc5316bis-04:
> (with
> > > DISCUSS)
> > >
> > > Alvaro Retana has entered the following ballot position for
> > > draft-ietf-lsr-isis-rfc5316bis-04: 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-isis-rfc5316bis/
> > >
> > >
> > >
> > > 
--
> > > DISCUSS:
> > > 
--
> > >
> > > I am balloting DISCUSS because I

Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-lsr-isis-rfc5316bis-04: (with DISCUSS)

[Acee Lindem (acee)]

Hi Les,

Looks good. See one suggestion. 

On 9/24/22, 5:23 PM, "Les Ginsberg (ginsberg)"  wrote:

Alvaro -

I have given your comments regarding clearer guidance on what value to use 
for router id more thought and tried to address this in V5 of the document 
(recently posted).

I introduced a new sub-section "Choosing the TE Router ID Value", 
discussing how to choose the value for IPv4 and IPv6.

Consistent with the terminology in RFC 5308, I'd use " IPv6 Interface Address 
TLV" and " non-link-local IPv6 address" in the second paragraph.

Thanks,
Acee

Subsequent sections now refer to this section.

Note that V5 also addresses comments from:

Rob Wilton
Eric Vyncke
Lars Eggert
Paul Wouters

Let me know if you still have concerns.

Les

> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Tuesday, September 20, 2022 9:30 PM
> To: Alvaro Retana ; The IESG 
> Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr-cha...@ietf.org; 
lsr@ietf.org;
> cho...@chopps.org; t...@ietf.org
> Subject: RE: Alvaro Retana's Discuss on 
draft-ietf-lsr-isis-rfc5316bis-04: (with
> DISCUSS)
> 
> Alvaro -
> 
> Please see inline.
> 
> > -Original Message-
> > From: Alvaro Retana via Datatracker 
> > Sent: Thursday, September 15, 2022 6:06 AM
> > To: The IESG 
> > Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr-cha...@ietf.org; 
lsr@ietf.org;
> > cho...@chopps.org; t...@ietf.org
> > Subject: Alvaro Retana's Discuss on draft-ietf-lsr-isis-rfc5316bis-04: 
(with
> > DISCUSS)
> >
> > Alvaro Retana has entered the following ballot position for
> > draft-ietf-lsr-isis-rfc5316bis-04: 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-isis-rfc5316bis/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > I am balloting DISCUSS because I believe the specification is not clear
> enough.
> >
> > (1) The document recommends (5 separate times) that an ID "SHOULD be
> > identical
> > to the value advertised" in an existing TLV.
> >
> > If the other TLV is advertised, when is it ok for the values not to be 
the
> > same?  Why is this action recommended and not required?
> >
> [LES:] The new text in Section 3.1 introduces a couple of new (as compared
> to the original RFC 5316 text) possibilities:
> 
> 1)The non-zero value could be identical to what is advertised in TLV 134 
or it
> could be identical to what is advertised in TLV 132 (IP Interface 
Address).
> This allows for cases where a Router ID is not configured but a stable 
unique
> IPv4 address is still advertised for the node.
> 
> 2)The Router ID is 0.0.0.0 because we are dealing with an IPv6 only
> deployment.
> 
> Now, I suppose we could say the Router ID field SHOULD/MUST be identical
> to TLV 134 except when TLV 134 isn't advertised (which is perfectly legal
> BTW) - but I find such text awkward at best - and (as per my reply to Tom 
et
> al) a MUST here is overly restrictive.
> Does this help address your concern?
> 
> > Should the receiver of these TLVs take any action if the values are not
> > identical?
> 
> [LES:] No.
> 
> >
> > (2) §3.1: The requirement for the Router ID to be unique within the
> flooding
> > scope of the LSP has been removed.
> 
> [LES:] We are not changing anything about TLV 134 (AKA TE Router ID ) . 
But
> given the multiple ways the field in the inter AS TLV can be filled in, 
it no
> longer seemed appropriate to make this statement.
> The need for uniqueness of the TE Router ID still exists - but it is the 
province
> of RFC 5305.
> 
>Les
> 
> >
> > Please help me understand why this change is ok.  If the Router ID can 
be
> > used
> > to identify "the router who generates the inter-AS reachability TLV", 
not
> > requiring unique values seems to go counter to that idea.
> >
> >
> >
> >


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

[Lsr] LSR Interim WG Meeting Reminder

[Acee Lindem (acee)]

We will have an interim working group meeting tomorrow (Sept 21st, 2022) from 
14:00 UTC to 16:00 UTC.

Here is the official information link: 
https://datatracker.ietf.org/meeting/interim-2022-lsr-01/session/lsr

Themes for this interim are IGP flex algorithm and SRv6 advertisement. 
Additionally, apparently the trend of shortages has hit LSR as we have a couple 
of proposals to address the shortage of bits for SRv6 Flex Algo advertisement. 
However, you can be assured that there is no paucity of a new LSR proposals. 
I’m sure you’ll all want to attend.

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

Re: [Lsr] rtgdir review of draft-ietf-lsr-ospfv3-srv6-extensions-08

[Acee Lindem (acee)]

Thanks Martin - Thanks for the Routing Directorate review!!


On 9/16/22, 12:49 PM, "Lsr on behalf of Martin Vigoureux" 
 wrote:

Hi,

I apologize for providing this review way past the deadline.
The document is of very good quality and clearly the result of careful 
work, which makes it hard to find anything to say.
Fortunately, I think I've found something :-)


Types in the range 45056-65535 are not to be assigned at this time.
Before any assignments can be made in the 33024-65535 range, there
MUST be an IETF specification that specifies IANA Considerations that
cover the range being assigned.
I think you mean 45056-65535 rather than 33024-65535 because part of it 
(33024-45055) is covered as FCFS.

Agreed. 

Also, this appears twice: Section 13.5 and 13.6

Agreed that it needs to be changed here as well. These are separate registries. 

Beyond that, the document looks ready to me.

As a side note, I'm not sure why segments is between double quotes in 
the Abstract.

Agreed. 

Thanks,
Acee


-m

___
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] Éric Vyncke's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)

[Acee Lindem (acee)]

Hi John, Eric, 

On 9/16/22, 9:36 AM, "Eric Vyncke (evyncke)"  wrote:

John

Thanks for your reply, it made me dig further... and I am afraid that I 
mixed up OSPF and IS-IS... (hey, I am just an INT AD ;-) )

I.e., AFAIK the router ID in OSPF is indeed a 32-bit value that must be 
unique (and is often simply an IPv4 address) used in LSA; while in the TE case, 
the router I-D is *NOT* is not really identifying the router for normal IS-IS 
computation but is 'only' a TLV for traffic engineering...

And to make matters more confusing, many people refer to the OSPF TE Router 
Address [RFC3630] and OSPFv3 TE Router Address [RFC5329] as the OSPF TE Router 
ID. This value must be a routable address and is analysis to the IS-IS Router 
ID. 

Thanks,
Acee

Let's put my mix-up on being Friday ;-)

Authors, if the above is correct, then please ignore my comments on section 
3.1.

Regards

-éric


On 16/09/2022, 15:13, "John Scudder"  wrote:

Hi Éric,

A few comments below.

> On Sep 16, 2022, at 4:27 AM, Éric Vyncke via Datatracker 
 wrote:
> 
> ## COMMENTS
> 
> ### Section 3.1
> 
> ```
>   The Router ID field of the inter-AS reachability TLV is 4 octets in
>   length, which contains the IPv4 Router ID of the router who 
generates
>   the inter-AS reachability TLV.  The Router ID SHOULD be identical to
>   the value advertised in the Traffic Engineering Router ID TLV
>   [RFC5305].  If no Traffic Engineering Router ID is assigned, the
>   Router ID SHOULD be identical to an IP Interface Address [RFC1195]
>   advertised by the originating IS.
> ```
> 
> AFAIK, the router ID is 'just' a 32-bit value that it is protocol 
version
> agnostic. So, s/IPv4 Router ID/Router ID/ ?
> 
> Suggest: s/IP Interface Address [RFC1195]/IPv4 Interface Address 
[RFC1195]/ ?

I wondered about this too when I was reviewing the document, and indeed 
RFC 5305 just calls the TE Router ID a 4-octet value. But then RFC 6119 says,

   The TE Router ID TLV contains a stable IPv4 address that is routable,
   regardless of the state of each interface.

   Similarly, for IPv6, it is useful to have a stable IPv6 address
   identifying a TE node.  The IPv6 TE Router ID TLV is defined in
   Section 4.1.

So even though it was after the fact, I suppose calling the former the 
“IPv4 Router ID” makes sense and just codifies what is apparently already the 
practice. The existence of the IPv6 TE Router ID, so named, is “the exception 
that proves the rule”. 

$0.02. The authors might have additional comments of course.

> ### Section 7
> 
> While Les was not an author of RFC 5316, he is an author of this I-D, 
so no
> more need to acknowledge him ;-)

I did make this point during my review and the authors chose to clarify 
that the supplied acknowledgments are a verbatim copy of what was in RFC 5316. 
So although this is a little unusual, it was a deliberate choice.

FYI, FWIW,

—John


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

Re: [Lsr] Request for early allocation for pending IANA allocation for draft-ietf-lsr-ospfv3-srv6-extensions

[Acee Lindem (acee)]

IANA,

Please add the AC-Bit as documented in Section 13.3 to the early codepoint 
allocations associated with this draft.

Thanks,
Acee

From: Ketan Talaulikar 
Date: Tuesday, August 30, 2022 at 11:54 AM
To: Acee Lindem 
Cc: Acee Lindem , lsr , 
"draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 

Subject: Request for early allocation for pending IANA allocation for 
draft-ietf-lsr-ospfv3-srv6-extensions

Hi Acee/Chris,

Now that the WGLC is done for this document, would it be a good time to request 
for early allocation for the pending item (OSPFv3 PrefixOption)?

Please refer: 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-07#section-13.3

Thanks,
Ketan

On Wed, Aug 24, 2022 at 12:11 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
The Working Group Last Call (WGLC) has completed. There is more than sufficient 
support for publication. As result of the WGLC discussion, there have been some 
changes and these reflected in the -07 version.


https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-07

Please review the changes resulting from the WGLC discussion. Note that the 
locator TLV will now use the PrefixOptions field common to other OSPFv3 LSAs 
advertising prefixes and will contain the Anycast (AC-bit). This change is 
reflected in sections 6 and 7.1.

Thanks,
Acee


From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
"Acee Lindem (acee)" 
mailto:40cisco@dmarc.ietf.org>>
Date: Friday, July 29, 2022 at 1:18 PM
To: lsr mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>"
 
mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>>
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

Re: [Lsr] AD review of draft-ietf-lsr-flex-algo-20

[Acee Lindem (acee)]

Thanks John - I the changes in -21 and -22 improve the specification. 
Acee

On 9/12/22, 8:41 AM, "Lsr on behalf of John Scudder"  wrote:

Hi Peter,

Thanks. I’ve requested IETF LC.

—John

> On Sep 12, 2022, at 7:36 AM, Peter Psenak  wrote:
> 
> 
> Hi John,
> 
> please see inline (##PP2)
> 
> On 09/09/2022 17:29, John Scudder wrote:
>> Hi Peter,
>> 
>> Thanks for your reply and for the ping.
>> 
>> Where necessary I’ve replied in line below. I’ve snipped any points that
>> are agreed and don’t need further discussion. I’ve also reviewed the -21
>> diffs, basically LGTM. It looks like you missed a few of the nits, I
>> don’t know if this was by choice or oversight. I’ve attached an edited
>> version of -21 that captures the remaining ones, plus a few new ones I
>> noticed. You can diff if you want to pick those up for inclusion in -22.
> 
> ##PP2
> I fixed all nits, hopefully.
> 
>> 
>>> On Aug 31, 2022, at 10:23 AM, Peter Psenak 
 wrote:
>>> 
>>> [External Email. Be cautious of content]
>>> 
>>> 
>>> Hi John,
>>> 
>>> thanks a lot for the thorough review.
>>> 
>>> I incorporated all your edits and almost all of your comments.
>>> 
>>> For the few that I have not, please see inline (loop for ##PP):
>> 
>> [snip]
>> 
  Any change in the Flex-Algorithm definition may result in 
temporary
  disruption of traffic that is forwarded based on such 
Flex-Algorithm
  paths.  The impact is similar to any other event that requires
  network-wide convergence.
 +
 +jgs: IMO this would merit discussion in the Operational Considerations
 +section.  In particular, is there any advice regarding how to
 +stage/sequence FAD config changes in order to minimize disruption?
>>> 
>>> ##PP
>>> I don't really see much to add here. FAD changes the constraints used
>>> during the algo specific SPF and as such any change in it requires all
>>> routers to recompute the entire topology. In terms of the order of
>>> changes, I don't see why that would be significant and why someone would
>>> not want to advertise all changes at once if there are any multiple
>>> changes in the FAD.
>> 
>> I take your point, thanks. I guess about the most that you could say in
>> Operational Considerations would be something like
>> 
>> ---
>> 15.X  FAD Changes
>> 
>> As [Section 5.3] notes, a change in the Flex-Algorithm definition may
>> require network-wide SPF recomputation and network reconvergence. This
>> potential for disruption should be taken into consideration when
>> planning and making changes to the FAD.
> 
> ##PP2
> Added above to the Operational Consideration section.
> 
>> ---
>> 
>> Obvs, re-word as appropriate. IMHO it's worth elevating in the O.C.
>> section even if only briefly, but I don’t insist.
>> 
>> [snip]
>> 
 +jgs: Are "sender" and "receiver" sufficiently clear to OSPF 
practitioners
 +that there would be no ambiguity? I can think of two different ways
 +to read them -- one is that the "sender" is the router that
 +originates the LSA, and the "receiver" is any router that processes
 +the LSA. I think that's what you mean. The other, pedantic, reading,
 +is the "sender" is any router that puts the LSA on the wire, and the
 +"receiver" is any router that takes the LSA from the wire, so anyone
 +participating in flooding would be both a "sender" and a "receiver"
 +at times.
 +
 +If this is how people write OSPF specs and talk about OSPF, fine.
 +But if there are more precise terms than "sender" and "receiver" in
 +use, it would be nice to use them.
>>> 
>>> ##PP
>>> send/receive is the standard term used, e.g
>>> 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8665*section-5__;Iw!!NEt6yMaO-gk!HAdyT2s3c5I_fktGSY3YPuQdVeF95m5Yb-utZWsGn9214bNEm1SkQ1dDgtbTL2tEJz4kJBwXudGrWyHF3P9zB8IEVqDz$
>> 

>>> 
>>> I can replace sender with originator, if you prefer, but receiver would
>>> remain.
>> 
>> As you prefer. It’s not a big deal. I agree, by the way, that receiver
>> is unambiguous.
> 
> ##PP
> replaced sender with originator.
> 
>> 
>> [snip]
>> 
 
 @@ -1194,15 +1258,36 @@
|   
|
+-TLVs 
-+
| 

Re: [Lsr] [Editorial Errata Reported] RFC3277 (7127)

[Acee Lindem (acee)]

Hi John, 
Agree - this can go straight to verified. 
Thanks,
Acee

On 9/12/22, 8:54 AM, "Lsr on behalf of RFC Errata System" 
 wrote:

The following errata report has been submitted for RFC3277,
"Intermediate System to Intermediate System (IS-IS) Transient Blackhole 
Avoidance".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7127

--
Type: Editorial
Reported by: John Scudder 

Section: 2

Original Text
-
   As such, it is recommended that each time a router establishes an
   adjacency, it will update its LSP and flood it immediately, even
   before beginning database synchronization.  This will allow for the
   Overload bit setting to propagate immediately, and remove the
   potential for an older version of the reloaded routers LSP to be
   used.


Corrected Text
--
   As such, it is recommended that each time a router establishes an
   adjacency, it will update its LSP and flood it immediately, even
   before beginning database synchronization.  This will allow for the
   Overload bit setting to propagate immediately, and remove the
   potential for an older version of the reloaded router's LSP to be
   used.


Notes
-
"reloaded router's" should be possessive singular.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC3277 (draft-ietf-isis-transient-02)
--
Title   : Intermediate System to Intermediate System (IS-IS) 
Transient Blackhole Avoidance
Publication Date: April 2002
Author(s)   : D. McPherson
Category: INFORMATIONAL
Source  : IS-IS for IP Internets
Area: Routing
Stream  : IETF
Verifying Party : IESG

___
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] ietf-o...@2019-10-17.yang: questions

[Acee Lindem (acee)]

Hi Chris,

From: Christian Hopps 
Date: Thursday, September 8, 2022 at 6:02 AM
To: "Acee Lindem (acee)" 
Cc: Christian Hopps , Renato Westphal 
, "draft-ietf-ospf-y...@ietf.org" 
, "lsr@ietf.org" 
Subject: Re: [Lsr] ietf-o...@2019-10-17.yang: questions
Resent-From: 
Resent-To: , Derek Yeung , Jeffrey 
Zhang , Acee Lindem , 

Resent-Date: Thursday, September 8, 2022 at 6:02 AM




On Sep 7, 2022, at 17:05, Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>> wrote:

Hi Renato,

Thanks for you comments. However, at this point in the cycle, we’re not going 
to make any additions to the model since it is has already been through the 
complete review cycle. We will however fix things that are broken.


See inline responses below.

From: Renato Westphal 
mailto:renatowestp...@gmail.com>>
Date: Thursday, September 1, 2022 at 2:31 PM
To: "draft-ietf-ospf-y...@ietf.org<mailto:draft-ietf-ospf-y...@ietf.org>" 
mailto:draft-ietf-ospf-y...@ietf.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: ietf-o...@2019-10-17.yang<mailto:ietf-o...@2019-10-17.yang>: questions
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: mailto:yingzhen...@futurewei.com>>, Derek 
Yeung mailto:de...@arrcus.com>>, 
mailto:ingwherc...@mitre.org>>, Jeffrey Zhang 
mailto:zzh...@juniper.net>>, Acee Lindem 
mailto:a...@cisco.com>>
Resent-Date: Thursday, September 1, 2022 at 2:30 PM

Hi all,

I have a few questions about the OSPF YANG module. I apologize if some of these 
questions were already asked before, but I couldn't find anything in the 
mailing list archives.

I also listed a few improvement suggestions, but I'm not sure if the draft can 
be updated at this point (it's status is listed as "RFC Ed Queue").


1. 
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/areas/area/interfaces

OSPFv3 is known to run a per-link basis whereas OSPFv2 runs on a per-IP-subnet 
basis. So what does it mean to configure an interface for OSPFv2 operation? 
Should OSPFv2 run only on the interface primary address, or run separate OSPFv2 
instances for each one of the interface addresses? The latter option doesn't 
seem viable since interfaces live under OSPF instances in the YANG hierarchy, 
but I'd like to hear what others think about this.

We’re really only supporting the per-link configuration for both OSPFv2 and 
OSPFv3 since this is what the vendors support. Per-subnet configuration could 
be added via augmentation.

More than a couple vendors support range based configuration (for OSPFv2) 
probably stemming from a pretty old cisco i.e.,

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/command/iro-cr-book/m_ospf-i1.html#wp2261032279
https://docs.frrouting.org/en/latest/ospfd.html#clicmd-network-A.B.C.D-M-area-A.B.C.D
maybe: 
https://www.arista.com/en/um-eos/eos-open-shortest-path-first-version-2#xx1153530
...

Vendors that didn't pattern themselves from original IOS configuration probably 
lack this configuration, though. If that's the case, perhaps it would be best 
to associate any augmentation with a feature (unless it's a standalone module I 
guess)?

In the case of Cisco, it only applies to the primary address on the interface 
so it is essentially an indirect way to configure interfaces. GateD used to 
support subnet-based OSPFv2 configuration – I’m not sure if there are any 
vendors that started with GateD and retrained this behavior.

Thanks,
Acee

Thanks,
Chris.
[as wg member]


[...]

Thanks,
Acee

Best Regards,
--
Renato Westphal


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

Re: [Lsr] ietf-o...@2019-10-17.yang: questions

[Acee Lindem (acee)]

Hi Renato,

Thanks for you comments. However, at this point in the cycle, we’re not going 
to make any additions to the model since it is has already been through the 
complete review cycle. We will however fix things that are broken.


See inline responses below.

From: Renato Westphal 
Date: Thursday, September 1, 2022 at 2:31 PM
To: "draft-ietf-ospf-y...@ietf.org" , 
"lsr@ietf.org" 
Subject: ietf-o...@2019-10-17.yang: questions
Resent-From: 
Resent-To: , Derek Yeung , 
, Jeffrey Zhang , Acee Lindem 

Resent-Date: Thursday, September 1, 2022 at 2:30 PM

Hi all,

I have a few questions about the OSPF YANG module. I apologize if some of these 
questions were already asked before, but I couldn't find anything in the 
mailing list archives.

I also listed a few improvement suggestions, but I'm not sure if the draft can 
be updated at this point (it's status is listed as "RFC Ed Queue").


1. 
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/areas/area/interfaces

OSPFv3 is known to run a per-link basis whereas OSPFv2 runs on a per-IP-subnet 
basis. So what does it mean to configure an interface for OSPFv2 operation? 
Should OSPFv2 run only on the interface primary address, or run separate OSPFv2 
instances for each one of the interface addresses? The latter option doesn't 
seem viable since interfaces live under OSPF instances in the YANG hierarchy, 
but I'd like to hear what others think about this.

We’re really only supporting the per-link configuration for both OSPFv2 and 
OSPFv3 since this is what the vendors support. Per-subnet configuration could 
be added via augmentation.


2. 
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/address-family

Given how OSPFv2 doesn't support multiple address families, wouldn't it be a 
good idea to constrain this leaf to OSPFv3 instances only (e.g. using a `when` 
statement)?

I’ll consider this as long as there aren’t other ramifications.


3. 
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/areas/area/interfaces/interface/instance-id

Based on the range of accepted values (`0 .. 31`), one must assume that this is 
a relative Instance-ID (based on RFC5838's address-family Instance-ID ranges). 
I think it would be useful to have that clear in the node description.

The range will be removed.


4. 
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/local-rib/route

I see this routing table lists destination networks only. Shouldn't there be a 
separate list for routes to border routers?

Many implementations (at least the efficient ones) store these in a separate 
table. This could be added via an augmentation.


5. 
/ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/local-rib/route/next-hops/next-hop

This list is keyed by the `next-hop` leaf, which is an IP address. Given that 
directly connected routes don't have an IP address, shouldn't this be a keyless 
list instead?

Since the local RIB only contains OSPF routes, they always have a next-hop.


6. /ietf-ospf:clear-database

I think the description of this RPC could benefit from a more detailed 
explanation. In addition to clearing the OSPF database, I assume all 
adjacencies need to be reset as well (in order to resync the LSDB). Could 
someone clarify what would be the expected behavior here?

I agree and will clarify.


7. How should route redistribution be configured? I see ietf-rip.yang has a 
separate container for that purpose, but ietf-ospf.yang (and other IGP modules) 
don't do the same. I also noticed the BGP model is using definition from 
ietf-routing-policy.yang.

Different vendors handle redistribution in different ways. This could be added 
with an augmentation if there were agreement.


8. Two standard configuration parameters (or "Configurable Constants") seem to 
be missing in the YANG module: RFC1583Compatibility (RFC 2328) and 
LinkLSASuppression (RFC 5340). Was that intentional?

These could be added via augmentation. I don’t believe LinkLSASuppression is 
implemented by anyone.



9. RFC 8405 specifies the following:

   If this SPF Back-Off algorithm is enabled by default, then in order
   to have consistent SPF delays between implementations with default
   configuration, the following default values SHOULD be implemented:

  INITIAL_SPF_DELAY 50 ms
  SHORT_SPF_DELAY  200 ms
  LONG_SPF_DELAY  5000 ms
  TIME_TO_LEARN_INTERVAL   500 ms
  HOLDDOWN_INTERVAL  1 ms

The OSPF YANG module, however, doesn't have those default values. Shouldn't 
they be added?

We deliberately left defaults out of the model so that implementations could 
provide their own defaults for hello-interval, etc.  I remember we had a long 
discussion and ended up with “SHOULD” in RFC 8407.



10. RFC 7949 defines a mechanism to use IPv4 to transport OSPFv3 packets. 
Shouldn't there be a configuration lea

Re: [Lsr] Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD review of draft-ietf-lsr-ospf-l2bundles-04]

[Acee Lindem (acee)]

Speaking as WG Member and primary author of RFC 8362: 

Hi John, 

On 9/6/22, 1:17 PM, "John Scudder"  wrote:

Hi Acee,

> On Sep 5, 2022, at 1:23 PM, Acee Lindem (acee)  wrote:
> 
> First of all, I think this IANA OSPFv3 Extended-LSA Sub-TLV 
specification, if it is to be done at all, should be done in a separate draft.

I guess by “specification” you mean “registry reorganization”, right? I’m 
OK with that, though I think I will wait a little longer to see if other WG 
contributors want to weigh in.

[ACEE] Actually, it is much more than "reorganization" as it is adding lots of 
additional information, i.e., additional "specification". 


> When we originally created the registry for RFC 8362, the purpose was 
avoid Sub-TLV code point collisions while affording maximum reuse of Sub-TLV 
definitions. It was NOT to avoid reading the specifications in order to 
determine everywhere a Sub-TLV is allowed.

I agree that reading all the RFCs is (or should be) sufficient. My thoughts 
are as I mentioned in my earlier reply to Ketan — organizing the registry to 
reflect the restrictions imposed by the RFCs serves two possibly-useful 
purposes. First, it gathers the information in one place for quick reference. 
Second and more important, it reduces the chance that the author of a future 
spec might overlook the need to carefully specify where their sub-TLV can and 
can’t be used.

[ACEE] There are a lot of IETF work items that would provide value. However, 
there is only a limited amount of resource and time to complete them. This 
draft has already gone through working group last call and I think this 
additional IANA specification would require more work and reviews than the 
original draft. 

> In fact, I don’t believe IS-IS had yet adopted this IANA practice when 
this became a WG document in 2007. OSPFv3 Extended LSAs took some time to 
standardize as we held it until there were implementations and there weren’t 
implementations until Segment Routing offered a strong incentive. 
>  
> If this information is to be represented in the IANA registry, I’d stay 
away from columns with Y’s and N’s. Note that Sub-TLVs can nested so 
conceivably a given Sub-TLV could be used by other Sub-TLVs.

Are there existing restrictions on the use of one sub-TLV within other 
sub-TLVs that would need to be captured, or are you just mentioning that for 
completeness? (Completeness is good of course.) If the latter, maybe one option 
could be a catch-all column, called something like “other restrictions on use” 
that can list other restrictions either in line or in a footnote with 
sub-bullets as you suggest.

[ACEE] I don't believe there are any nested Sub-TLVs today but we certainly 
don't want the IANA specification/organization to make adding them unwieldy. 

> Rather, one could list the Sub-TLVs with the individual usages and 
references (if different from the creation reference) as sub-bullets.

I can’t comment because I can’t quite picture what you’re describing, and 
how the registry would look?

[ACEE] As it does today except with indented lines as to the usage of the 
Sub-TLVs. The exact formatting would be for the new draft. 

I guess if we do decide to either abandon the reorganization suggestion 
altogether, or to pursue it as a separate draft, then 
draft-ietf-lsr-ospf-l2bundles should just stick to its existing approach of 
listing restrictions in their own subsections of the main spec, do you agree? 
Recall that we got here (in part) because it seemed strange to me to update the 
registry to list some restrictions, but not all of them.

[ACEE] This would be my choice except I wouldn't add the "L2 Member Bundle 
Attributes" restriction to the IANA registry unless we do it for all the 
Sub-TLVs as you suggest. 

Thanks,
Acee

Thanks,

—John

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

Re: [Lsr] Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD review of draft-ietf-lsr-ospf-l2bundles-04]

[Acee Lindem (acee)]

Hi Ketan, John,

First of all, I think this IANA OSPFv3 Extended-LSA Sub-TLV specification, if 
it is to be done at all, should be done in a separate draft.

When we originally created the registry for RFC 8362, the purpose was avoid 
Sub-TLV code point collisions while affording maximum reuse of Sub-TLV 
definitions. It was NOT to avoid reading the specifications in order to 
determine everywhere a Sub-TLV is allowed. In fact, I don’t believe IS-IS had 
yet adopted this IANA practice when this became a WG document in 2007. OSPFv3 
Extended LSAs took some time to standardize as we held it until there were 
implementations and there weren’t implementations until Segment Routing offered 
a strong incentive.

If this information is to be represented in the IANA registry, I’d stay away 
from columns with Y’s and N’s. Note that Sub-TLVs can nested so conceivably a 
given Sub-TLV could be used by other Sub-TLVs. Rather, one could list the 
Sub-TLVs with the individual usages and references (if different from the 
creation reference) as sub-bullets.

Thanks,
Acee



From: Ketan Talaulikar 
Date: Monday, September 5, 2022 at 11:26 AM
To: John Scudder 
Cc: "lsr@ietf.org" , "draft-ietf-lsr-ospf-l2bund...@ietf.org" 
, Acee Lindem 
Subject: Re: Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD 
review of draft-ietf-lsr-ospf-l2bundles-04]

Hi John,

Please check inline below with KT for a quick clarification.


On Mon, Sep 5, 2022 at 8:39 PM John Scudder 
mailto:j...@juniper.net>> wrote:
Hi Ketan,

Seems like a good plan. Comments below.

> On Sep 5, 2022, at 3:31 AM, Ketan Talaulikar 
> mailto:ketant.i...@gmail.com>> wrote:
>
> I am personally OK with adopting the "boy scout" approach here - even if it 
> might be seen as a scope creep.
>
> Following is a proposal for feedback from you and the WG:
>
> We'll first need 9 columns in the "OSPFv3 Extended-LSAs Sub-TLVs" registry at 
> this point to indicate the applicability of each sub-TLV to its parent 
> TLV(s). More may be required as we go along and new TLVs are added.
>
> 1) Router Link (RL)
> 2) Attached Routers (AR)
> 3) Inter-Area Prefix (IeAP)
> 4) Inter-Area Router (IAR)
> 5) External Prefix (EP)
> 6) Intra-Area Prefix (IaAP)
> 7) IPv6 Link-Local Address (6LL)
> 8 IPv4 Link-Local Address (4LL)
> 9) Extended Prefix Range (EPR)
>
> Then we will need the 10th column to indicate applicability to the L2 Bundle 
> Member Attribute (L2BM) Sub-TLV.
>
> These columns may become very complicated and not sure how they would look in 
> the IANA registry.

When you say “very complicated” do you simply mean that the table would be 
wide? Because all I’m envisioning is ten additional columns in the registry, 
with each cell containing either “Y” or “N”; this doesn’t seem inherently 
complex to me. This approach is familiar from some of the IS-IS registries, 
consider 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-neighbor-information
 for example. Only six columns in that one, not ten, but the idea is the same.

KT> The complication is when more/further TLVs are defined - it may get 
unwieldy. This is a little different from IS-IS in that sense.



> I am not aware of discussions (if any) that took place during RFC8362 on this 
> sharing of sub-TLV space. Perhaps the authors of RFC8362 and chairs can also 
> share their inputs. The other (more cleaner and traditional approach IMHO) 
> might have been to have separate spaces for each TLV.

True, the WG could decide to reorganize it to give each type its own space in 
its own registry, where the first 32 code points in each space just happen to 
be the same. I guess the downside would be, for any sub-TLV that’s applicable 
to more than one type, you’d have to do multiple registrations — but you have 
to specify applicability for the multiple types in the unified registry anyway, 
so it all works out to the same thing. (I think we did this kind of 
reorganization for BMP, if I recall correctly.)

If the sub-TLV number space were small, there would be a stronger motivation to 
reorganize into multiple registries, to conserve space, but with a 2^16 space 
it doesn’t seem like a real concern. So AFAICT it comes down to a matter of 
taste.

KT> Agree and just to clarify, I don't have anything against the share sub-TLV 
space that we have currently.


> In any case, I think we should wait for WG's input before making such 
> (feature creep) changes.

Agreed. To raise visibility and hopefully elicit more input, I’ve updated the 
subject line and explicitly cc’d Acee (in his capacity as shepherd). Probably 
there will be more engagement after the U.S. Labor Day holiday is over.

KT> Ack.

Thanks,
Ketan



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

Re: [Lsr] [Editorial Errata Reported] RFC2328 (7112)

[Acee Lindem (acee)]

Agreed. This is clearly documented section 10.6 on page 100.
Thanks,
Acee

On 9/1/22, 4:52 PM, "Lsr on behalf of John Scudder"  wrote:

This looks right. If there are any objections to verifying it, please let 
me know.

—John

> On Sep 1, 2022, at 2:39 PM, RFC Errata System  
wrote:
> 
> 
> The following errata report has been submitted for RFC2328,
> "OSPF Version 2".
> 
> --
> You may review the report below and at:
> 
https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7112__;!!NEt6yMaO-gk!FJynD-y4c4yWDb91yTvFViobefnoM7wxDCIcBMiV4r0jFG8WE4jsCzW7xMBABvx2TwtPDHYBucjBuYoTMPupgw$
> 
> --
> Type: Editorial
> Reported by: Renato Westphal 
> 
> Section: 10.2
> 
> Original Text
> -
>NegotiationDone
>The Master/Slave relationship has been negotiated, and DD
>sequence numbers have been exchanged.  This signals the
>start of the sending/receiving of Database Description
>packets.  For more information on the generation of this
>event, consult Section 10.8.
> 
> Corrected Text
> --
>NegotiationDone
>The Master/Slave relationship has been negotiated, and DD
>sequence numbers have been exchanged.  This signals the
>start of the sending/receiving of Database Description
>packets.  For more information on the generation of this
>event, consult Section 10.6.
> 
> Notes
> -
> The generation of the NegotiationDone event is specified in Section 10.6 
(not Section 10.8).
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --
> RFC2328 (no draft string recorded)
> --
> Title   : OSPF Version 2
> Publication Date: April 1998
> Author(s)   : J. Moy
> Category: INTERNET STANDARD
> Source  : Open Shortest Path First IGP
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG

___
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] AD review of draft-ietf-lsr-pce-discovery-security-support-09

[Acee Lindem (acee)]

Hi Les, John, Authors,

I agree with Les that we should not pad in IS-IS and should have separate 
encodings.  I’m not sure why I didn’t notice this when I did the shepherd 
review.

Thanks,
Acee

From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 

Date: Friday, August 26, 2022 at 3:05 PM
To: John Scudder , 
"draft-ietf-lsr-pce-discovery-security-supp...@ietf.org" 
, "lsr@ietf.org" 

Subject: Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

Folks –

John makes a very good point below in regards to the sub-TLV format for 
KEY-CHAIN-NAME Sub-TLV.

IS-IS never pads – because it is pointless and wastes space.
But more importantly, the “length” field of any TLV/sub-TLV is used to find 
your way to the start of the next TLV/sub-TLV.
The notion that the actual space of the sub-TLV is potentially longer than the 
length field simply never occurs in IS-IS – and I would not want to introduce 
an exception just for this case.

Rather than do what John suggests below (have two lengths in the encoding), 
please define distinct formats for each protocol.
This should be done for the KEY-ID sub-TLV as well.
This is not only consistent with the behavior of each protocol, it is 
consistent with what has been done in RFCs 5088/5089.

Using the same sub-TLV code point across both protocols is fine since we 
constrain it to sub-TLVs under the PCED advertisement – but please - protocol 
specific sub-TLV format definitions always.

Thanx.

   Les



+Next question, what does the Length field indicate, exactly?  Is it the
+length of the string?  Presumably so, since there is no termination
+character.  Please say so, and say what the units are (e.g., "Length:
+length of the Key Name field, in octets").
+
+Finally, at the end of the description of the Key Name field, you say
+"The sub-TLV MUST be zero-padded so that the sub-TLV is 4-octet aligned."
+Since we've already established that the Length field must indicate the
+Key Name field length, what tells the parser how many bytes of padding
+are present? Is it just supposed to know, based on whether the Key Name
+field falls on a word boundary or not? Because, the Length field isn't
+going to tell it.
+
+Perhaps all OSPF and IS-IS TLV parsers are robust to this kind of format;
+if so let's discuss. But Occam's Razor suggests that the format documented
+here isn't quite right, and that it should be something more like:
+
+   Type: 7
+   Length: Variable
+   Key Name:
+   String Length: one octet whose value is the number of octets
+  in the Key Name
+   String: zero or more characters of (whatever the supported
+   alphabet is).
+   Padding: 0-3 octets of padding, such that the sub-TLV is 4-octet
+aligned.
+
+So there are two length fields: one is the usual TLV length field, that
+tells you the size of the value portion. The other is the string length,
+and it's needed because you're going to add 0-3 bytes of padding. If you
+didn't use the padding, you could get away with a single length field,
+but since you do have padding, you need both fields, it seems.
+
+That obviously isn't a finished description but it gives you the idea.


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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Acee Lindem (acee)]

I agree that retaining the option and using it for debugging would be a good 
thing. However, given that multi-part TLVs are already in use, the absence of 
the advertisement doesn’t necessarily mean that the IS-IS router doesn’t 
support multi-part TLVs. Rather, it presence would mean that beyond a shadow of 
a doubt, they are supported.

Similarly, for backward compatibility,  an IS-IS router would not be required 
to strictly enforce the requirement that all IS-IS routers within the scope of 
the Multi-Part TLV advertise the capability.

Thanks,
Acee

From: Lsr  on behalf of Robert Raszuk 
Date: Thursday, August 25, 2022 at 12:18 PM
To: "Acee Lindem (acee)" 
Cc: Gunter Van de Velde , Tony Li 
, lsr 
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt

All,

I am actually finding this capability useful. If for nothing else then to help 
the operator to see what is going on in the area. On any node simple show 
command will clearly show who is willing and capable to receive MP-TLVs and who 
is not.

Analogy to including hostnames Tony brought here as an example is spot on and 
along the same lines.

Of course how node uses that info could be discussed further. I would also not 
object to put that capability into a separate document.

Thx,
R.





On Thu, Aug 25, 2022 at 6:06 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as WG member:

Hi Gunder, Tony, Les,

I'm also not a fan of the Multi-Part TLV Capability flag. While the intent of 
the draft is to encourage multi-part TLV advertisement and usage, the addition 
of this flag and the requirement for advertisement will most likely have the 
opposite effect. Given that IS-IS implementations are already advertising 
multi-part TLVs but none are advertising the proposed capability flag, 
implementation of the draft as currently written would inhibit Multi-Part TLV 
usage and be a step backwards. Of course, we know implementations that are 
already advertising these multi-part TLVs will most likely ignore the 
recommendation and continue to advertise them even when not all IS-IS routers 
within the scope of the Multi-Part TLV advertise the capability.

Rather, I propose that the draft eliminates the capability flag and introduces 
a recommended configuration parameter that would allow Multi-Part TLVs to be 
suppressed. The recommended default would be FALSE. This would provide an out 
if these Multi-Part TLVs did, in fact, have dire consequences.

Thanks,
Acee

On 8/25/22, 6:53 AM, "Lsr on behalf of Van De Velde, Gunter (Nokia - 
BE/Antwerp)" mailto:lsr-boun...@ietf.org> on behalf of 
gunter.van_de_ve...@nokia.com<mailto:gunter.van_de_ve...@nokia.com>> wrote:

Inline: GV>

From: Tony Li mailto:tony1ath...@gmail.com>> On 
Behalf Of Tony Li
Sent: Wednesday, August 24, 2022 5:26 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: lsr mailto:lsr@ietf.org>>
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt


Hi Gunter,

I am having troubles understanding the value of ‘The Multi-part TLV 
Capability’ flag.
What would break if ‘Multi-part TLV Capability’ flag would not exist?


A system that supported MP-TLVs would not be able to determine that there 
were other systems in the area that did not support MP-TLVs.  The system might 
then advertise MP-TLVs and they would be misinterpreted or cause system crashes 
in the systems that did not support them.

GV> crashes? I really hope that is not happening.
GV> When a legacy router receives MP-TLVs from another system and legacy 
router has no support for handling MP-TLV, then yes, things get misinterpreted. 
There is nothing wrong with that, is there? Do you have an example where things 
go wrong?

If we want to introduce MP-TLVs, that change would warrant the existence of 
the flag.

GV> I am not convinced yet how a MP-TLV catch-all flag would make ISIS 
behave better

I dispute that a binary flag warrants the word ‘complexity’.

GV>  living without binary flag is simpler and less complex then dealing 
with a binary flag. (i.e. what, when, how, why, who sets this flag?)

Note: thoughts about the flag: What if a system by accident sends 
flip-flopping (set/unset/set/unset/etc) of this flag?

Then other systems might misinterpret the results and generate inconsistent 
TLVs.  That would be bad.

GV> correct, no good at all.

What if an advertising system support multi-tlv for TLV ‘A’ but not for TLV 
‘B’?

We are not allowing that level of granularity.  A system that is going to 
support MP-TLVs should take care to operate correctly for ALL TLVs before 
advertising that it supports them.

GV> I suspect that 'ALL TLVs' is a reference to  ALL TLVs supported by the 
local system. This means that e.g. when new TL

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Acee Lindem (acee)]

Speaking as WG member:

Hi Gunder, Tony, Les, 

I'm also not a fan of the Multi-Part TLV Capability flag. While the intent of 
the draft is to encourage multi-part TLV advertisement and usage, the addition 
of this flag and the requirement for advertisement will most likely have the 
opposite effect. Given that IS-IS implementations are already advertising 
multi-part TLVs but none are advertising the proposed capability flag, 
implementation of the draft as currently written would inhibit Multi-Part TLV 
usage and be a step backwards. Of course, we know implementations that are 
already advertising these multi-part TLVs will most likely ignore the 
recommendation and continue to advertise them even when not all IS-IS routers 
within the scope of the Multi-Part TLV advertise the capability. 

Rather, I propose that the draft eliminates the capability flag and introduces 
a recommended configuration parameter that would allow Multi-Part TLVs to be 
suppressed. The recommended default would be FALSE. This would provide an out 
if these Multi-Part TLVs did, in fact, have dire consequences. 

Thanks,
Acee

On 8/25/22, 6:53 AM, "Lsr on behalf of Van De Velde, Gunter (Nokia - 
BE/Antwerp)"  
wrote:

Inline: GV>

From: Tony Li  On Behalf Of Tony Li
Sent: Wednesday, August 24, 2022 5:26 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 

Cc: lsr 
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt


Hi Gunter,

I am having troubles understanding the value of ‘The Multi-part TLV 
Capability’ flag.
What would break if ‘Multi-part TLV Capability’ flag would not exist? 


A system that supported MP-TLVs would not be able to determine that there 
were other systems in the area that did not support MP-TLVs.  The system might 
then advertise MP-TLVs and they would be misinterpreted or cause system crashes 
in the systems that did not support them.

GV> crashes? I really hope that is not happening.
GV> When a legacy router receives MP-TLVs from another system and legacy 
router has no support for handling MP-TLV, then yes, things get misinterpreted. 
There is nothing wrong with that, is there? Do you have an example where things 
go wrong? 

If we want to introduce MP-TLVs, that change would warrant the existence of 
the flag.  

GV> I am not convinced yet how a MP-TLV catch-all flag would make ISIS 
behave better

I dispute that a binary flag warrants the word ‘complexity’.

GV>  living without binary flag is simpler and less complex then dealing 
with a binary flag. (i.e. what, when, how, why, who sets this flag?)

Note: thoughts about the flag: What if a system by accident sends 
flip-flopping (set/unset/set/unset/etc) of this flag? 

Then other systems might misinterpret the results and generate inconsistent 
TLVs.  That would be bad.

GV> correct, no good at all.

What if an advertising system support multi-tlv for TLV ‘A’ but not for TLV 
‘B’?

We are not allowing that level of granularity.  A system that is going to 
support MP-TLVs should take care to operate correctly for ALL TLVs before 
advertising that it supports them.

GV> I suspect that 'ALL TLVs' is a reference to  ALL TLVs supported by the 
local system. This means that e.g. when new TLVs would be supported after a 
system upgrade, that the operator has to be aware and correct the flag during 
each single upgrade. 

GV> Unfortunately I remain to have troubles understanding the value 
"Multi-part TLV Capability’ flag brings to an ISIS network. 
  * Without flag it is indeed uncertain if area wide mp-tlv is supported 
(sub-optimal). 
  * but with catch all MP-TLV flag I am not sure we improve ISIS operation: 
  ** Who guarantees that the flag is set correctly on all systems at all 
times
  ** Maybe all systems falls back to advertise single TLV because another 
(legacy?) system advertise a wrong flag  (sub-optimal)
  ** Legacy system with MP-TLV support gets upgraded and now supports 
additional TLVs but not with MP-TLV...  ?manual intervention? (sub-optimal)
  ** what, when, how, why, who sets the MP-TLV flag? What with flapping of 
MP-TLV flag (undefined)

G/

Tony



___
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] AD review of draft-ietf-lsr-pce-discovery-security-support-09

[Acee Lindem (acee)]

Speaking as document shepherd and WG member:

Hi John, Qin, and Dhruv,

See a couple inlines.

From: Lsr  on behalf of Dhruv Dhody 
Date: Thursday, August 25, 2022 at 7:02 AM
To: Qin Wu 
Cc: John Scudder , 
"draft-ietf-lsr-pce-discovery-security-supp...@ietf.org" 
, "lsr@ietf.org" 

Subject: Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

Hi Qin, John,

I have added my comments for two issues, please see inline (look for Dhruv:)


On Thu, Aug 25, 2022 at 2:52 PM Qin Wu 
mailto:40huawei@dmarc.ietf.org>> wrote:
Hi, John:
Thanks for your valuable AD review. We have incorporate your comments into 
draft-ietf-lsr-pce-discovery-security-support-10.
Regarding the issues your raised below, please reply inline below.

-Qin (on behalf of authors)
发件人: John Scudder [mailto:j...@juniper.net]
发送时间: 2022年8月18日 8:41
收件人: 
draft-ietf-lsr-pce-discovery-security-supp...@ietf.org;
 lsr@ietf.org
主题: AD review of draft-ietf-lsr-pce-discovery-security-support-09

Dear Authors,

Thanks for you patience as this document sat in my queue for too long. :-( 
Here’s my review.

I’ve supplied my comments in the form of an edited copy of the draft. Minor 
editorial suggestions I’ve made in place without further comment, more 
substantive comments are done in-line and prefixed with “jgs:”. You can use 
your favorite diff tool to review them; I’ve attached a PDF of the iddiff 
output for your convenience if you’d like to use it. I’ve also pasted a 
traditional diff below in case you want to use it for in-line reply. I’d 
appreciate feedback regarding whether you found this a useful way to receive my 
comments as compared to a more traditional numbered list of comments with 
selective quotation from the draft.

Thanks,

—John


--- draft-ietf-lsr-pce-discovery-security-support-09.txt2022-08-17 
15:35:47.0 -0400
+++ draft-ietf-lsr-pce-discovery-security-support-09-jgs-comments.txt   
2022-08-17 20:37:48.0 -0400
@@ -13,14 +13,14 @@
   21 August 2021


-IGP extension for PCEP security capability support in the PCE discovery
+IGP extension for PCEP security capability support in PCE discovery
 draft-ietf-lsr-pce-discovery-security-support-09

 Abstract

When a Path Computation Element (PCE) is a Label Switching Router
(LSR) participating in the Interior Gateway Protocol (IGP), or even a
-   server participating in IGP, its presence and path computation
+   server participating in the IGP, its presence and path computation
capabilities can be advertised using IGP flooding.  The IGP
extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
to advertise path computation capabilities using IGP flooding for
@@ -28,10 +28,10 @@
method to advertise PCEP security (e.g., Transport Layer Security
(TLS), TCP Authentication Option (TCP-AO)) support capability.

-   This document defines capability flag bits for PCE-CAP-FLAGS sub-TLV
+   This document defines capability flag bits for the PCE-CAP-FLAGS sub-TLV
that can be announced as an attribute in the IGP advertisement to
distribute PCEP security support information.  In addition, this
-   document updates RFC 5088 and RFC 5089 to allow advertisement of Key
+   document updates RFC 5088 and RFC 5089 to allow advertisement of a Key
ID or Key Chain Name Sub-TLV to support TCP-AO security capability.
RFC 8231, RFC 8306, and RFC 8623 are also updated to reflect the
movement of the IANA "PCE Capability Flags" registry.
@@ -100,7 +100,7 @@
 1.  Introduction

As described in [RFC5440], PCEP communication privacy is one
-   importance issue, as an attacker that intercepts a Path Computation
+   important issue, as an attacker that intercepts a Path Computation
Element (PCE) message could obtain sensitive information related to
computed paths and resources.

@@ -114,14 +114,14 @@
 Internet-Draft   IGP discovery for PCEP Security August 2021


-   Among the possible solutions mentioned in these documents, Transport
+   Among the possible solutions mentioned in that document, Transport
Layer Security (TLS) [RFC8446] provides support for peer
authentication, and message encryption and integrity while TCP
Authentication Option (TCP-AO) [RFC5925] and Cryptographic Algorithms
for TCP-AO [RFC5926] offer significantly improved security for
applications using TCP.  As specified in section 4 of [RFC8253], in
order for a Path Computation Client (PCC) to establish a connection
-   with a PCE server using TLS or TCP-AO, PCC needs to know whether PCE
+   with a PCE server using TLS or TCP-AO, the PCC needs to know whether the PCE
server supports TLS or TCP-AO as a secure transport.

[RFC5088] and [RFC5089] define a method to advertise path computation
@@ -129,10 +129,10 @@
However the

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Acee Lindem (acee)]

The Working Group Last Call (WGLC) has completed. There is more than sufficient 
support for publication. As result of the WGLC discussion, there have been some 
changes and these reflected in the -07 version.


https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-07

Please review the changes resulting from the WGLC discussion. Note that the 
locator TLV will now use the PrefixOptions field common to other OSPFv3 LSAs 
advertising prefixes and will contain the Anycast (AC-bit). This change is 
reflected in sections 6 and 7.1.

Thanks,
Acee


From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Friday, July 29, 2022 at 1:18 PM
To: lsr 
Cc: "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 

Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Acee Lindem (acee)]

Speaking as WG Member:

Hi Aijun, Zhibo,

From: Huzhibo 
Date: Friday, August 19, 2022 at 6:27 AM
To: Aijun Wang , Acee Lindem , 'lsr' 

Cc: "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 

Subject: RE: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hi Aijun,

Thanks for your detailed review and please check inline below for responses.


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, August 19, 2022 5:55 PM
To: 'Acee Lindem (acee)' ; 'lsr' 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hi, All:
 I have the following comments for this draft, and would like to support 
its forwarding when the below concerns are addressed.


1. For SRv6 SID’s advertisement, I suggest we should also consider it is 
advertised as sub-TLVs of OSPF-Stub-Link TLV, as proposed in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-04#section-4.1.
  There are situations that such information can be utilized by the routers 
within the area, as I presented at the IETF 114 meeting (the draft is pending 
to be updated).  Then the following sentence:
   “SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except
   for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a
   specific Neighbor/Link and are therefore advertised as Sub-TLVs of E-
   Router-Link TLV.”


Should be relaxed as:
   “SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except
   for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a
   specific Neighbor/Link and are therefore advertised as Sub-TLVs of 
Neighbor/Link related TLVs.”



Zhibo> This description does not affect the new TLVs. If a new TLV is added, 
you can include the sub TLV in the new TLV.



2. Support for the “SRv6 Locator TLV” to be included within the existing 
LSA, rather than to define the new “Locator LSA”.

Zhibo> The reason for defining new LSAs is to prevent processing errors on 
nodes that do not support SRv6. For example, ignoring algorithm fields may 
cause loops.

Of course, using LSinfinity metric is one way to solve this problem, but the 
protocol specifies the IGP does not generate the RIB/Fib for LSinfinity Metric 
prefix.

The LSinfinity metric does not meet this scenario. In addition, IS-IS also 
defines a New TOP TLV. The OSPF definition is the same as that of IS-IS.



While either encoding could work, I agree that this may be cleaner since  the 
separation readily allows knowing whether the SRv6 or base LSA changed. 
Additionally, given that there are advantages and disadvantages to either 
approach, we’re certainly not going to change it during WG last call.



Thanks,

Acee



Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr mailto:lsr@ietf.org>>
Cc: 
draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

Re: [Lsr] AD review of draft-ietf-lsr-flex-algo-20

[Acee Lindem (acee)]

Hi John, 

On 8/18/22, 1:29 PM, "John Scudder"  wrote:

Hi Acee,

> On Aug 18, 2022, at 1:10 PM, Acee Lindem (acee) 
 wrote:
> 
> Speaking as Document Shepherd:
>  
> Hi John, 
>  
> Thanks much for your review and suggested text. I think these will 
improve the both the precision of the specification and the readability. I read 
though the comments and I don’t see any show stoppers although the additional 
operational considerations may take some thinking. Note that the main editor 
just went on PTO after you completed you review and it will be at least a 3 
weeks before you receive a response (and maybe more).

Yes, Peter also mentioned that to me unicast, thanks.

[snip]

> The Opaque ID field is an arbitrary value used to maintain multiple
> OSPFv2 EIA-ASBR LSAs.  For OSPFv2 EIA-ASBR LSAs, the Opaque ID has no
> @@ -1220,11 +1305,28 @@
> TLV is padded to 4-octet alignment; padding is not included in the
> Length field (so a 3-octet value would have a length of 3, but the
> total size of the TLV would be 8 octets).  Nested TLVs are also
> -   32-bit aligned.  For example, a 1-byte value would have the Length
> +   32-bit aligned.  For example, a 1-octet value would have the Length
> field set to 1, and 3 octets of padding would be added to the end of
> the value portion of the TLV.  The padding is composed of zeros.
> -
> -
> +   
> +jgs: I have mixed feelings about how you cut-and-paste the definition 
from
> +RFC 3630 Section 2.3.2 instead of just referencing it. On one hand, the
> +material starting with "for example" is new, provides more clarity, and
> +the requirement for padding to be zeroes is new. On the other hand, your
> +reference to the Length field, which makes sense in the original context
> +of RFC 3630 §2.3.2, is confusing here -- you have a diagram above with a
> +field called Length, but that is NOT what you're talking about here.
> +In 3630 there's a TLV diagram that makes it clear at a glance what's 
> +being talked about.
> +
> +Again I think the easiest fix is to leave the first sentence (adding
> +"Section 2.3.2" to the reference) and remove the rest, although if it's
> +important to specify zero-padding then leave that sentence.
> +
> +On the other hand if you feel the full detail is needed for clarity,
> +then go all the way and make this its own subsection and don't just
> +copy-paste the definition portion from 3630, copy the TLV diagram too,
> +so the reader isn't led astray.
> 
> Since the included text is only a couple sentences, I think it is clearer 
to include it as has been done in other OSPF documents. To avoid the ambiguity 
that you have pointed out, we can replace “Length field” with “TLV or Sub-TLV 
length”. While I don’t think replication of the TLV format in a diagram is 
needed, it better to have the very brief text rather than require going to RFC 
3630 to learn the encoding rules. One only has to cite the infamous RFC 7752 as 
a document that is unwieldy, in part, due to the number of external references 
required for the encodings.

Any solution that makes it clear what’s being referred to is OK of course. 
I do think it would be a cheap and easy thing to add a section break before 
that paragraph in support of that goal, something like the below. 

Breaking it into multiple paragraphs is fine with me. I don't feel strongly on 
section break either way. 

Thanks,
Acee

--- 10.1-para   2022-08-18 13:26:20.0 -0400
+++ 10.1-para-jgs-edits 2022-08-18 13:26:07.0 -0400
@@ -1,14 +1,17 @@
+10.1.1. EIA-ASBR TLVs
+
The format of the TLVs within the body of the OSPFv2 EIA-ASBR LSA is
the same as the format used by the Traffic Engineering Extensions to
OSPFv2 [RFC3630].  The variable TLV section consists of one or more
-   nested TLV tuples.  Nested TLVs are also referred to as sub- TLVs.
-   The Length field defines the length of the value portion in octets
+   nested TLV tuples.  Nested TLVs are also referred to as sub-TLVs.
+   
+   The TLV or Sub-TLV length field defines the length of the value portion 
in octets
(thus, a TLV with no value portion would have a length of 0).  The
TLV is padded to 4-octet alignment; padding is not included in the
Length field (so a 3-octet value would have a length of 3, but the
total size of the TLV would be 8 octets).  Nested TLVs are also
-   32-bit aligned.  For example, a 1-byte value would have the Length
+   32-bit aligned.  For example, a 1-octet value would have the TLV or 
Sub-TLV length
field s

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Acee Lindem (acee)]

Hi Ketan,

From: Ketan Talaulikar 
Date: Wednesday, August 17, 2022 at 11:35 AM
To: Acee Lindem 
Cc: lsr , "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 
, "Goethals, Dirk (Nokia - 
BE/Antwerp)" 
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hi Acee,

The routing for anycast is transparent but there are features and use cases 
where the knowledge of Anycast is required or helpful. I don't have all the 
draft pointers, but there have been presentations in SPRING and RTGWG WGs on 
redundancy and protection features that leverage anycast.

I think we’re agreeing, I’ve seen the same use case presentations and it is, 
IMO, a far better usage than prefix unreachability 😉

Thanks,
Acee

Thanks,
Ketan


On Wed, Aug 17, 2022 at 8:44 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Ketan,

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Wednesday, August 17, 2022 at 11:04 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: lsr mailto:lsr@ietf.org>>, 
"draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>"
 
mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>>,
 "Goethals, Dirk (Nokia - BE/Antwerp)" 
mailto:dirk.goeth...@nokia.com>>
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hi Acee,

Please check inline below.


On Wed, Aug 17, 2022 at 8:06 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Ketan,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Wednesday, August 17, 2022 at 9:48 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: lsr mailto:lsr@ietf.org>>, 
"draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>"
 
mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>>,
 "Goethals, Dirk (Nokia - BE/Antwerp)" 
mailto:dirk.goeth...@nokia.com>>
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hello Acee/All,

There has not been any further comment/feedback on the point that Dirk brought 
up in the thread below:
https://mailarchive.ietf.org/arch/msg/lsr/_4HcJEsteNQxjxuot1uLdoXeH6s/

I want to point out that not just the LA-flag, but also the P-flag is required 
for propagation of the SRv6 Locator LSA across NSSA.

Perhaps the best option available to us is to replace the "Flags" field in the 
SRv6 Locator TLV (refer to 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-06#section-6.1)
 with the "PrefixOptions" field that is present in all the OSPFv3 prefix 
reachability advertisements in RFC5340/8362. This will also bring a nice 
consistency for OSPFv3 even though some flags are unused in the SRv6 context.

We only have 1 bit left - 
https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4
 So, perhaps we need to add the PrefixOptions using the existing registry and 
we need a new field and registry that could be advertised in Extended LSAs.

KT> This is the idea behind 
https://datatracker.ietf.org/doc/draft-chen-lsr-anycast-flag/ - hopefully, we 
can bring it up for WG adoption soon. I believe Anycast is a strong enough use 
case to consume the remaining unused bit and the introduction of a new 
extensible Flags sub-TLV should take care of future extensions as proposed in 
the aforementioned individual draft.

Is this the first introduction of the N flag for OSPFv3 in any LSA? I don’t see 
it in https://datatracker.ietf.org/doc/rfc8666/

KT> N flag in PrefixOptions came via RFC8362 and so RFC8666 didn't have to do 
anything about it. Refer 
https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4


Ok – I thought I remembered the N-Flag but I didn’t look close enough at the 
existing IANA assignments. I agree we can use the add the Anycast Bit to the 
Prefix Options. Although it seems to negate the fact that anycast can be routed 
transparently, there are enough drafts presenting use cases as to why it is 
needed.

Thanks,
Acee



Additionally, we can use the remaining bit available for AC-flag (anycast) 
similar to the ISIS SRv6 spec.

Note that this change would not be backward compatible with the current spec 
since the bit positions are moving.

Looking for feedback/input from the WG on this proposed change.

I think we’d just need to get feedback from Dirk (who made the comment that 
initiated this) and the co-authors. Of course, anyone with know of OSPFv3 SRv6 
can comment.

KT> I did discuss offline with Dirk and we agreed

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Acee Lindem (acee)]

Hi Ketan,

From: Ketan Talaulikar 
Date: Wednesday, August 17, 2022 at 11:04 AM
To: Acee Lindem 
Cc: lsr , "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 
, "Goethals, Dirk (Nokia - 
BE/Antwerp)" 
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hi Acee,

Please check inline below.


On Wed, Aug 17, 2022 at 8:06 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Ketan,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Wednesday, August 17, 2022 at 9:48 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: lsr mailto:lsr@ietf.org>>, 
"draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>"
 
mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>>,
 "Goethals, Dirk (Nokia - BE/Antwerp)" 
mailto:dirk.goeth...@nokia.com>>
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hello Acee/All,

There has not been any further comment/feedback on the point that Dirk brought 
up in the thread below:
https://mailarchive.ietf.org/arch/msg/lsr/_4HcJEsteNQxjxuot1uLdoXeH6s/

I want to point out that not just the LA-flag, but also the P-flag is required 
for propagation of the SRv6 Locator LSA across NSSA.

Perhaps the best option available to us is to replace the "Flags" field in the 
SRv6 Locator TLV (refer to 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-06#section-6.1)
 with the "PrefixOptions" field that is present in all the OSPFv3 prefix 
reachability advertisements in RFC5340/8362. This will also bring a nice 
consistency for OSPFv3 even though some flags are unused in the SRv6 context.

We only have 1 bit left - 
https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4
 So, perhaps we need to add the PrefixOptions using the existing registry and 
we need a new field and registry that could be advertised in Extended LSAs.

KT> This is the idea behind 
https://datatracker.ietf.org/doc/draft-chen-lsr-anycast-flag/ - hopefully, we 
can bring it up for WG adoption soon. I believe Anycast is a strong enough use 
case to consume the remaining unused bit and the introduction of a new 
extensible Flags sub-TLV should take care of future extensions as proposed in 
the aforementioned individual draft.

Is this the first introduction of the N flag for OSPFv3 in any LSA? I don’t see 
it in https://datatracker.ietf.org/doc/rfc8666/

KT> N flag in PrefixOptions came via RFC8362 and so RFC8666 didn't have to do 
anything about it. Refer 
https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4


Ok – I thought I remembered the N-Flag but I didn’t look close enough at the 
existing IANA assignments. I agree we can use the add the Anycast Bit to the 
Prefix Options. Although it seems to negate the fact that anycast can be routed 
transparently, there are enough drafts presenting use cases as to why it is 
needed.

Thanks,
Acee



Additionally, we can use the remaining bit available for AC-flag (anycast) 
similar to the ISIS SRv6 spec.

Note that this change would not be backward compatible with the current spec 
since the bit positions are moving.

Looking for feedback/input from the WG on this proposed change.

I think we’d just need to get feedback from Dirk (who made the comment that 
initiated this) and the co-authors. Of course, anyone with know of OSPFv3 SRv6 
can comment.

KT> I did discuss offline with Dirk and we agreed on the necessity for the LA 
and P flags for OSPFv3 SRv6. We have not discussed the approach of using 
PrefixOptions instead of the Flags field though and Dirk is now on PTO. I hope 
others can share their views on the PrefixOptions approach.

Thanks,
Ketan


Thanks,
Acee

Thanks,
Ketan


On Fri, Jul 29, 2022 at 10:47 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Acee Lindem (acee)]

Hi Yingzhen,

From: Yingzhen Qu 
Date: Tuesday, August 16, 2022 at 7:52 PM
To: Acee Lindem 
Cc: lsr , "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 

Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

I support progressing this draft.

I have the following minor comments for the authors to consider:

· The title of Section 4 of this draft is “Advertisement of SRH 
Operation Limits”, and really it only covers the advertisements of MSDs, so may 
consider to change the title to be consistent with the ISIS SRv6 extensions 
draft, "Advertising Maximum SRv6 SID Depths”.
· The subsections in section 4 are almost identical to the subsections 
in draft-ietf-lsr-isis-srv6-extesions. It’s up to the authors and the WG to 
decide whether to keep this duplicate.
I have encouraged LSR authors to allow protocol encoding section to stand on 
their own rather than reference the other document and describe the deltas. In 
some cases, OSPF and IS-IS can share IANA registries for common enumerations. I 
see Ketan replied consistent with this approach.
Thanks,
Acee


· In draft-ietf-lsr-isis-srv6-extensions, “topology/algorithm” is used, 
and it’s not consistently used in this draft. For example, in section 5 the 
second paragraph, only “algorithm” is used, while “topology/algorithm” is used 
later.

Nits (line numbers are from idnits):

208 the SR Algorithm TLV defined in [RFC8665] as described in [RFC8666]
SR Algorithm/SR-Algorithm  Please add a “-“ to be consistent with RFC 8665.


355 The SRv6 Locator LSA has a function code of TBD while the S1/S2 bits
“TBD” should be replaced with “42” as in IANA considerations.

Thanks,
Yingzhen


On Jul 29, 2022, at 10:16 AM, Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>> wrote:

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


___
Lsr mailing list
Lsr@ietf.org<mailto: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] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Acee Lindem (acee)]

Hi Ketan,

From: Lsr  on behalf of Ketan Talaulikar 

Date: Wednesday, August 17, 2022 at 9:48 AM
To: Acee Lindem 
Cc: lsr , "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 
, "Goethals, Dirk (Nokia - 
BE/Antwerp)" 
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Hello Acee/All,

There has not been any further comment/feedback on the point that Dirk brought 
up in the thread below:
https://mailarchive.ietf.org/arch/msg/lsr/_4HcJEsteNQxjxuot1uLdoXeH6s/

I want to point out that not just the LA-flag, but also the P-flag is required 
for propagation of the SRv6 Locator LSA across NSSA.

Perhaps the best option available to us is to replace the "Flags" field in the 
SRv6 Locator TLV (refer to 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-06#section-6.1)
 with the "PrefixOptions" field that is present in all the OSPFv3 prefix 
reachability advertisements in RFC5340/8362. This will also bring a nice 
consistency for OSPFv3 even though some flags are unused in the SRv6 context.

We only have 1 bit left - 
https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4
 So, perhaps we need to add the PrefixOptions using the existing registry and 
we need a new field and registry that could be advertised in Extended LSAs. Is 
this the first introduction of the N flag for OSPFv3 in any LSA? I don’t see it 
in https://datatracker.ietf.org/doc/rfc8666/


Additionally, we can use the remaining bit available for AC-flag (anycast) 
similar to the ISIS SRv6 spec.

Note that this change would not be backward compatible with the current spec 
since the bit positions are moving.

Looking for feedback/input from the WG on this proposed change.

I think we’d just need to get feedback from Dirk (who made the comment that 
initiated this) and the co-authors. Of course, anyone with know of OSPFv3 SRv6 
can comment.

Thanks,
Acee

Thanks,
Ketan


On Fri, Jul 29, 2022 at 10:47 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo

[Acee Lindem (acee)]

Speaking as WG member:

I agree with Les. A non-backward compatible change is a non-starter.

I’m not sure why you’d need to present this again at the Interim unless you 
provide backward compatibility.

Thanks,
Acee

From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 

Date: Friday, August 12, 2022 at 12:05 PM
To: 龚立艳 , "lsr@ietf.org" , shraddha 

Subject: Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo

Liyan –

You agree that there is an existing way to prune links from the IGP SPF.
Still, you insist that an extension that requires ALL routers – whether they 
support flex algo or not – to utilize a new advertisement when computing algo 0 
SPF is necessary.
Your rationale for this is that this allows you to use IGP Metric for flex algo 
in cases where the IGP metric would have been set to maximum.
But we already have the ability to define metrics specific to flex algo – and 
this is greatly enhanced by the generic metric defined in 
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/

Requiring a non backwards compatible extension to be used in base protocol 
operation in order to support a new feature is exactly what we MUST NOT do when 
introducing protocol extensions.

My opinion is unchanged – this is a bad idea – and completely unnecessary.

   Les


From: 龚立艳 
Sent: Friday, August 12, 2022 2:16 AM
To: lsr@ietf.org; Les Ginsberg (ginsberg) ; shraddha 

Subject: Re:Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo




Hi Shraddha and Les,



Sorry for late reply and thanks for your comments.



Yes, the maximum link metric mechanism is an option as described in section 4 
of the draft.



But, it has two defects which we also wanted to discuss in ietf 114 meeting.



Firstly, it restricts the Flex-Algorithm from using IGP-Cost as its metric-type.

Secondly, it does not work with OSPF. For OSPF,the links with maximummetric 
value(65535) are also included in the SPF calculation,even if not preferred. If 
there are no other preferred paths,the Flex-Algoritnm links will still affect 
the result of thenormal SPF calculation.



Due to the time constraints,The presentation has been moved to the interim 
meeting on 2022-09-21. For more detail, please refer to the slides.

https://datatracker.ietf.org/meeting/114/materials/slides-114-lsr-13-exclusive-link-for-flex-algo-00.



In view of these two cases, new protocol extension becomes necessary.



As for the backward incompatible issues, we think it can be avoided by 
deployment.



For example, the new extension should be deployed in sync with the Flex-Algo 
feature, so that all the routers in one IGP domain will run the same software 
version.



Looking forward to your reply.



Best Regards,

Liyan




邮件原文
发件人："Les Ginsberg \\(ginsberg\\)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
收件人：Shraddha Hegde  
mailto:shraddha=40juniper@dmarc.ietf.org>>,"lsr@ietf.org"
 mailto:lsr@ietf.org>>
抄　送: (无)
发送时间：2022-07-29 21:14:08
主题：Re: [Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo


I fully agree with Shraddha.

In fact Section 4 of the draft makes clear why no protocol extensions are 
needed.

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Shraddha Hegde
Sent: Friday, July 29, 2022 2:18 AM
To: lsr@ietf.org
Subject: [Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo

Authors,


I suggest that the usecase can be satisfied using the backward compatible
Maximum link metric mechanism defined in the draft.
I don’t see any need to define protocol extensions,
that are backward incompatible and can cause serious issues in the network
in the presence of older implementations.

Rgds
Shraddha


Juniper Business Use Only


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

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Acee Lindem (acee)]

Speaking as WG member:

I support publication of this draft. I reviewed the draft and my comments have 
been incorporated.

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Friday, July 29, 2022 at 1:18 PM
To: lsr 
Cc: "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 

Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

[Lsr] FW: IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-lsr-ospfv3-srv6-extensions

[Acee Lindem (acee)]

Hey Robin, 

Haven't received your WG last call IPR poll response yet - I guess you were 
waiting for this to be posted?  

Thanks,
Acee

On 8/11/22, 10:47 AM, "Lsr on behalf of IETF Secretariat" 
 wrote:

Dear Zhenbin Li, Zhibo Hu, Ketan Talaulikar, Peter Psenak:


An IPR disclosure that pertains to your Internet-Draft entitled "OSPFv3
Extensions for SRv6" (draft-ietf-lsr-ospfv3-srv6-extensions) was submitted 
to
the IETF Secretariat on 2022-08-10 and has been posted on the "IETF Page of
Intellectual Property Rights Disclosures" (/ipr/5785/history/). The title of
the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR
related to draft-ietf-lsr-ospfv3-srv6-extensions"


Thank you

IETF Secretariat


___
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] Link State Routing (lsr) WG Virtual Meeting: 2022-09-21 CHANGED

[Acee Lindem (acee)]

Moved the meeting to avoid both US Labor Day week and Chinese Autumn Holiday 
week... 

Thanks,
Acee

On 8/10/22, 2:55 PM, "Lsr on behalf of IESG Secretary"  wrote:

MEETING DETAILS HAVE CHANGED.  SEE LATEST DETAILS BELOW.

The Link State Routing (lsr) WG will hold
a virtual interim meeting on 2022-09-21 from 10:00 to 12:00 
America/New_York (14:00 to 16:00 UTC).

Agenda:

IGP Flexible Algorithms Reverse Affinity Constraint
Peter Psenak (5 mins)

https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-flex-algo-reverse-affinity/

IGP extensions for Advertising Offset for Flex-Algorithm
Louis Chan (10 mins)
https://datatracker.ietf.org/doc/draft-chan-lsr-igp-adv-offset/

IS Extension to Advertise SRv6 SIDs using SID Block
Liyan Gong / Weiqiang Cheng (10 mins)
https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/

Advertising Exclusive Links for Flex-Algorithm in IGP
Liyan Gong / Weiqiang Cheng (10 mins)

https://datatracker.ietf.org/doc/draft-gong-lsr-exclusive-link-for-flex-algo/

More to come. 

Information about remote participation:

https://meetings.conf.meetecho.com/interim/?short=164d8b7c-491b-46d9-8898-7a8b7063fdbd

___
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-ginsberg-lsr-rfc8919bis-02

[Acee Lindem (acee)]

On 8/9/22, 7:34 PM, "Aijun Wang"  wrote:

Hi, Chris:
If so, let’s adopt them directly then, why seek the opinions from the WG?
I would like to illustrate my opinions again:
Application specific attributes just one small part of the application 
based solution, there are other issues needed to be considered and solved. And 
I think the alternative systematic  solution will obsolete RFC8919 and RFC8920 
together.
The bis draft are just repeating its precedent, and will be replaced also 
accordingly, unless it solves the issues that I mentioned.

And what alternate systematic solution are you referring to? The LSR Working 
Group is not going to defer this update based on some set of hypothetical 
requirements and solution irrespective of your opinion. 

Acee


Aijun Wang
China Telecom

> On Aug 9, 2022, at 21:50, Christian Hopps  wrote:
> 
> 
> We were asked by the AD to process these clarifications using bis drafts, 
rather than errata. That is what this is. There should be no controversy here. 
Let's not create any, please.
> 
> Thanks,
> Chris.
> 
> Aijun Wang  writes:
> 
>> Hi, Acee, Peter:
>> 
>> If there is no significant updates for these two RFCs, I recommend we 
delay the obsolete of them, also the adoption call for these two bis drafts.
>> What we should do is to find other more scalable, extensible and 
systematic approaches for the application specified advertisements.
>> 
>> For example, for the multiple application scenarios, is it enough just 
define the application specified attributes?
>> 
>> From my understandings, different applications may build different 
LSDBs, run
>> different SPF algorithm, update at different frequencies, forming 
different
>> forwarding tables etc. It is necessary to divide/group all the above 
items based
>> on application, not just the attributes.
>> 
>> 
>> Aijun Wang
>> China Telecom
>> 
>>>> On Aug 9, 2022, at 18:31, Acee Lindem (acee)  wrote:
>>> 
>>> Hi Aijun,
>>> 
>>> And the BIS changes are more clarifications than changes to the 
existing RFC 8919 and RFC 8920 RFCs.
>>> 
>>> Thanks,
>>> Acee
>>> 
>>> On 8/9/22, 5:57 AM, "Peter Psenak"  wrote:
>>> 
>>>   Aijun,
>>> 
>>>>   On 09/08/2022 05:35, Aijun Wang wrote:
>>>> Hi,
>>>> 
>>>> I am wondering why we are so hurry to obsolete RFC8919, given that 
only the
>>>> minor parts are  updated (mainly the zero length SABM/UABM, and other
>>>> interoperability issues).
>>>> There may be other methods to advertise the application specific 
attributes.
>>>>> From my POV, the rules, implementation of ASLA are still complex, the
>>>> deployment of them are challenging.
>>>> 
>>>> Is there any real deployment for RFC8919 until now?
>>> 
>>>   sure there are deployments of it. Flex-algo is built around RFC8919, 
so
>>>   any network where flex-algo is used with ISIS is using RFC8919.
>>> 
>>>   Peter
>>> 
>>>> 
>>>> Best Regards
>>>> 
>>>> Aijun Wang
>>>> China Telecom
>>>> 
>>>> -Original Message-
>>>> From: lsr-boun...@ietf.org  On Behalf Of 
Christian
>>>> Hopps
>>>> Sent: Monday, August 8, 2022 6:17 PM
>>>> To: lsr@ietf.org
>>>> Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
>>>> Subject: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02
>>>> 
>>>> 
>>>> Hi Folks,
>>>> 
>>>> This begins a 2 week WG Adoption Call for the following draft:
>>>> 
>>>>  https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/
>>>> 
>>>> Please indicate your support or objections by August 22nd, 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
> 

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

Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02

[Acee Lindem (acee)]

Hi Aijun, 

And the BIS changes are more clarifications than changes to the existing RFC 
8919 and RFC 8920 RFCs. 

Thanks,
Acee 

On 8/9/22, 5:57 AM, "Peter Psenak"  wrote:

Aijun,

On 09/08/2022 05:35, Aijun Wang wrote:
> Hi,
> 
> I am wondering why we are so hurry to obsolete RFC8919, given that only 
the
> minor parts are  updated (mainly the zero length SABM/UABM, and other
> interoperability issues).
> There may be other methods to advertise the application specific 
attributes.
>>From my POV, the rules, implementation of ASLA are still complex, the
> deployment of them are challenging.
> 
> Is there any real deployment for RFC8919 until now?

sure there are deployments of it. Flex-algo is built around RFC8919, so 
any network where flex-algo is used with ISIS is using RFC8919.

Peter

> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -Original Message-
> From: lsr-boun...@ietf.org  On Behalf Of Christian
> Hopps
> Sent: Monday, August 8, 2022 6:17 PM
> To: lsr@ietf.org
> Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
> Subject: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02
> 
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
>https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/
> 
> Please indicate your support or objections by August 22nd, 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-ppsenak-lsr-rfc8920bis-02

[Acee Lindem (acee)]

As a contributor, I'm not aware of any IPR related to the draft.

Thanks,
Acee

On 8/8/22, 9:55 AM, "Peter Psenak"  wrote:

Hi Chris,

I am not aware of any IPR related to this draft.

thanks,
Peter


On 08/08/2022 06:17, Christian Hopps wrote:
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
>https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/
> 
> Please indicate your support or objections by August 22nd, 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

Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02

[Acee Lindem (acee)]

I support WG adoption. The clarifications in the BIS document were discussed in 
the course of the flex algorithm draft.
Thanks,
Acee

On 8/8/22, 6:21 AM, "Christian Hopps"  wrote:


Hi Folks,

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

  https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/

Please indicate your support or objections by August 22nd, 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

Re: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02

[Acee Lindem (acee)]

I support WG adoption. The clarifications in the BIS document were discussed in 
the course of the flex algorithm draft.
Thanks,
Acee

On 8/8/22, 6:22 AM, "Christian Hopps"  wrote:


Hi Folks,

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

  https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/

Please indicate your support or objections by August 22nd, 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

Re: [Lsr] IPR Poll Coincident with the Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt

[Acee Lindem (acee)]

Hi Robin,
I’m only missing your IPR declaration.
Thanks,
Acee

From: Huzhibo 
Date: Wednesday, August 3, 2022 at 11:08 PM
To: Acee Lindem , "draft-ietf-lsr-ospfv3-s...@ietf.org" 

Cc: lsr 
Subject: RE: IPR Poll Coincident with the Working Group Last Call for "OSPFv3 
Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt


Hi Acee,



I am not aware of any undisclosed IPR that applies to 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt



thanks,

Zhibo


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, July 30, 2022 1:15 AM
To: draft-ietf-lsr-ospfv3-s...@ietf.org
Cc: lsr 
Subject: [Lsr] IPR Poll Coincident with the Working Group Last Call for "OSPFv3 
Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt

Co-authors,

Are you aware of any IPR that applies to 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee & Chris


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

Re: [Lsr] Comments on draft-white-lsr-distoptflood-03

[Acee Lindem (acee)]

From: Antoni Przygienda 
Date: Monday, August 1, 2022 at 11:20 AM
To: Acee Lindem , "Les Ginsberg (ginsberg)" 
, "lsr@ietf.org" 
Subject: Re: [Lsr] Comments on draft-white-lsr-distoptflood-03


1.   Agree, we already talked about it amongst the authors. Oberve that 
it’s strictly implementation specific behavior that does not need to be 
standardized so we overspecify a it but I agree that would improve the document 
overall.

2.   Agree as well, it’s not easy to express what is actually going on 
PSNPs so we try to massage the language somewhere along the lines what you said

Not grok’ing your “per never” timer. Probably auto correction 😉

Ha! Ha!  I should always “read before Send” – I meant “per neighbor”.

More than happy to get into adoption call if chairs support that. Given we 
didn’t socialize the new version I thought it’s wise not to push it during IETF 
but personally more than happy to go down the adoption route since 
implementations are there and I spent enough time on the draft helping out with 
it I personally to get it into quality high enough to be WG material IMO

We have a backlog of WG last calls but not WG adoptions that don’t aren’t 
without significant issues.

Thanks,
Acee

--- tony



From: Acee Lindem (acee) 
Date: Monday, 1 August 2022 at 07:42
To: Antoni Przygienda , Les Ginsberg (ginsberg) 
, lsr@ietf.org 
Subject: Re: [Lsr] Comments on draft-white-lsr-distoptflood-03
[External Email. Be cautious of content]

Speaking as WG member:

Hi Tony,

Great improvement to the prior version of the draft – I’d now support adoption.

My two comments at the mike were:


1.   Potentially add text to text to section 2.1 and 2.2 to allow for N 
flooding paths t the neighbors on the TNL.

2.   Suggested clarificiton for section 2.3:
   OLD:
   of all LSPs that have not been reflooded during the timer runtime
   NEW:
  of all  LSPs for which flooding to any neighbor was suppressed during the 
time runtime

Alternately, you could have a separate timer per never if one desired more 
granular failure detection. I realize that for a given LSP source, the list of 
neighbors will be exactly the same. I remember that prior to your 
modifications, this was a CSNP and I questioned whether this failure prevention 
strategy would negate the savings in flooding..


Thanks,
Acee




From: Lsr  on behalf of Antoni Przygienda 

Date: Friday, July 29, 2022 at 11:32 PM
To: "Les Ginsberg (ginsberg)" , "lsr@ietf.org" 

Subject: Re: [Lsr] Comments on draft-white-lsr-distoptflood-03

No Announce: thanks, we agree

Well, given LSP flooding is unrelible as well it seems no better and no worse 
if we RTX. The PSNP bits will be hanging there and I guess we have to put it on 
a RTX mechanism or we rely on CSNP. Good comment.

Yes, the PSNPs are _in addition_ so yes, I agree also here we can fall back on 
those. I kind of prefer those since it doesn’t change protocol behavior further 
than it already does by sending the additional PSNP

Thanks


n  Tony

From: Les Ginsberg (ginsberg) 
Date: Friday, 29 July 2022 at 15:08
To: Antoni Przygienda , lsr@ietf.org 
Subject: Comments on draft-white-lsr-distoptflood-03
[External Email. Be cautious of content]


Tony (and everyone) -

Following up on the brief discussion about this draft at today's WG meeting...

I withdraw the comment regarding having to announce use of the algorithm. After 
rereading I agree this is not necessary.

Regarding my second comment about the use of PSNPs as a recovery mechanism in 
cases where topology changes temporarily compromise the optimized 
flooding...the draft says in Section 2.3


o  Set a short timer; the default should be one second

   o  When the timer expires, send Partial Sequence Number Packet (PSNP)
  of all LSPs that have not been reflooded during the timer runtime
  to all neighbors unless an up-to-date PSNP or CSNP has been
  already received from the neighbor


Given that PSNPs are unreliable, how can you guarantee that the neighbor has 
received the PSNP(s) required by the most recent set of LSP updates which were 
NOT flooded to that neighbor?

The traditional way of closing this gap is to send periodic CSNPs on interfaces 
where flooding may have been suppressed. In this way you guarantee the 
reliability of the update process.
The recovery time may be a bit slower as sending CSNPs every second is 
excessive - but I do not see how you guarantee reliability without periodic 
transmissions.

Or do you mean to say send the PSNP once IN ADDITION to periodic CSNPs?? This 
would allow quicker recovery in most cases while using a slower periodic timer 
for the CSNPs as protection in case the PSNP was lost.

   Les


Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Comments on draft-white-lsr-distoptflood-03

[Acee Lindem (acee)]

Speaking as WG member:

Hi Tony,

Great improvement to the prior version of the draft – I’d now support adoption.

My two comments at the mike were:


  1.  Potentially add text to text to section 2.1 and 2.2 to allow for N 
flooding paths t the neighbors on the TNL.
  2.  Suggested clarificiton for section 2.3:
   OLD:
   of all LSPs that have not been reflooded during the timer runtime
   NEW:
  of all  LSPs for which flooding to any neighbor was suppressed during the 
time runtime

Alternately, you could have a separate timer per never if one desired more 
granular failure detection. I realize that for a given LSP source, the list of 
neighbors will be exactly the same. I remember that prior to your 
modifications, this was a CSNP and I questioned whether this failure prevention 
strategy would negate the savings in flooding..


Thanks,
Acee




From: Lsr  on behalf of Antoni Przygienda 

Date: Friday, July 29, 2022 at 11:32 PM
To: "Les Ginsberg (ginsberg)" , "lsr@ietf.org" 

Subject: Re: [Lsr] Comments on draft-white-lsr-distoptflood-03

No Announce: thanks, we agree

Well, given LSP flooding is unrelible as well it seems no better and no worse 
if we RTX. The PSNP bits will be hanging there and I guess we have to put it on 
a RTX mechanism or we rely on CSNP. Good comment.

Yes, the PSNPs are _in addition_ so yes, I agree also here we can fall back on 
those. I kind of prefer those since it doesn’t change protocol behavior further 
than it already does by sending the additional PSNP

Thanks


n  Tony

From: Les Ginsberg (ginsberg) 
Date: Friday, 29 July 2022 at 15:08
To: Antoni Przygienda , lsr@ietf.org 
Subject: Comments on draft-white-lsr-distoptflood-03
[External Email. Be cautious of content]


Tony (and everyone) -

Following up on the brief discussion about this draft at today's WG meeting...

I withdraw the comment regarding having to announce use of the algorithm. After 
rereading I agree this is not necessary.

Regarding my second comment about the use of PSNPs as a recovery mechanism in 
cases where topology changes temporarily compromise the optimized 
flooding...the draft says in Section 2.3


o  Set a short timer; the default should be one second

   o  When the timer expires, send Partial Sequence Number Packet (PSNP)
  of all LSPs that have not been reflooded during the timer runtime
  to all neighbors unless an up-to-date PSNP or CSNP has been
  already received from the neighbor


Given that PSNPs are unreliable, how can you guarantee that the neighbor has 
received the PSNP(s) required by the most recent set of LSP updates which were 
NOT flooded to that neighbor?

The traditional way of closing this gap is to send periodic CSNPs on interfaces 
where flooding may have been suppressed. In this way you guarantee the 
reliability of the update process.
The recovery time may be a bit slower as sending CSNPs every second is 
excessive - but I do not see how you guarantee reliability without periodic 
transmissions.

Or do you mean to say send the PSNP once IN ADDITION to periodic CSNPs?? This 
would allow quicker recovery in most cases while using a slower periodic timer 
for the CSNPs as protection in case the PSNP was lost.

   Les


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IPR Poll Coincident with the Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Acee Lindem (acee)]

Co-authors,

Are you aware of any IPR that applies to 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee & Chris


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

[Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Acee Lindem (acee)]

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

[Lsr] IPR Poll Coincident with the Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt

[Acee Lindem (acee)]

Co-authors,

Are you aware of any IPR that applies to 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee & Chris


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

[Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt

[Acee Lindem (acee)]

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

Re: [Lsr] Comments on draft-ppsenak-lsr-igp-ureach-prefix-announce

[Acee Lindem (acee)]

Hi Peter, Ketan, 

See one inline. 

On 7/28/22, 10:08 AM, "Lsr on behalf of Peter Psenak"  wrote:

Hi Ketan,

On 28/07/2022 02:27, Ketan Talaulikar wrote:
> Hello Authors,
> 
> Sharing some comments upfront on this draft given the packed LSR agenda.
> 
> 1) There is currently no change in protocol encoding (see also further 
> comment), however, there are protocol procedures at the ABR being 
> specified using normative language. Specifically, the text related to 
> the propagation of UPA across levels/areas/domains. Therefore, I believe 
> that this draft should be moved to the standards track.

no objection from my side, if the WG decides that way.

> 
> 2) The document refers to "prefix reachability" in a generic sense. My 
> understanding is that this refers to the "base" prefix reachability in 
> the IGPs - i.e., Extended IP Reachability (TLV 135) and its MT & IPv6 
> siblings in ISIS, the OSPFv2 Type 3 LSA, and the OSPFv3 
> Inter-Area Prefix LSA (and its Extended LSA sibling). It would be good 
> to specify these for clarity.

sure, we can clarify.

> 
> 3) I also prefer (like some other WG members) that there is an explicit 
> indication that is carried along with the UPAs. E.g., a UPA flag. This 
> will help in more accurate monitoring and handling of these updates. It 
> will also help differentiate the usual/existing max/infinite metric 
> advertisements that may be triggered for other reasons from a UPA.

I'm of opinion that the existing mechanisms are sufficient and the flag 
would be redundant.

I agree. One of the main arguments against this signaling overhead and for 
OSPFv2, we'd need to use an opaque LSA (given the LSA Options are all taken 
unless we reuse the MC-Bit). Using the same metric that is used for backward 
compatibility simplifies things.

Thanks,
Acee


thanks,
Peter

> 
> Thanks,
> Ketan
> 

___
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] Comments on draft-wang-lsr-prefix-unreachable-annoucement

[Acee Lindem (acee)]

Speaking as WG Member:

Hi Ketan,

Thanks for pointing out the similarities. Even after the recent changes,  there 
are still some difference between the drafts which I’ll describe in the 
baseless comments which follow. For conciseness, I’ll refer to the drafts as 
PUA (Draft Wang) and UPA (Draft Psenak).


  1.  Backward Compatibility – Now that PUA has appropriated the metric 
mechanisms from UPA, it is also backward compatible. However, PUA still 
proposes extensions the IGPs to advertise the PUA capabilities and says the 
nodes may misbehave if they don’t agree on these capabilities. I guess removing 
these was omitted when the UPA metric mechanisms were appropriated.
  2.  Receive Router Behavior – For UPA, the unreachable prefix notification is 
solely for an event signal to be used by other routers in the IGP domain to 
trigger actions, e.g., BGP PIC excluding the unreachable prefix.  PUA is used 
for the switchover of services as well but is also used to modify persistent 
state. In section 4, the PUA advertisement will trigger the advertisement of 
the prefix by an ABR that does have a route to the unreachable prefix 
advertised by another ABR.
  3.  Advertisement Persistence – PUA is advertised like any other LSA and 
presumably advertised as long as the prefix is unreachable. Conversely, UPA is 
an ephemeral LSA that will be withdrawn after enough time is allowed for the 
event notification to propagate.

In my opinion, UPA is superior to PUA since it is addresses the original 
requirement with minimal overhead and changes to the IGP. Even after many 
revisions, PUA still contains a lot of additional unnecessary overhead and 
complexity. I think the WG should adopt UPA and not spend any more time on this 
discussion.

Thanks,
Acee

From: Lsr  on behalf of Ketan Talaulikar 

Date: Thursday, July 28, 2022 at 2:29 AM
To: Aijun Wang 
Cc: "Les Ginsberg (ginsberg)" , 
"draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org" 
, lsr 
Subject: Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

Hi Aijun,

Indeed, your draft has done a "pivot" in the latest version with the use of 
LSInfinity like the UPA proposal. I hope you will do yet another "pivot" to 
move away from the use of Prefix Originator.

IMHO that would also bring the PUA and UPA proposals much closer to each other.

Thanks,
Ketan


On Thu, Jul 28, 2022 at 6:52 AM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Les:

I admire you and your comments as usual, but the baseless comments will 
decrease your credits within the WG. Would you like to review the update of the 
draft more carefully, then post your comments? Doing this can avoid misleading 
some of your followers.

To facilitate your review, I copied the related contents 
again:(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10#section-5)



  If not all of nodes within one area support the PUAM capabilities,

   the PUAM message should be advertised with the associated prefix cost

   set to LSInfinity.  According to the description in 
[RFC2328],

   [RFC5305] and 
[RFC5308], the prefix advertised 
with such metric value

   will not be considered during the normal SPF computation, then such

   additional information will avoid the misbehavior of the nodes when

   they don't recognize the PUAM message.



   If all of nodes within one area support the PUAM capabilites, the

   PUAM message can be safely advertised without the additional

   LSInfinity metric information.

Then, how can the “legacy nodes MUST interpret as meaning reachable.” ? I wish 
to hear your explanation.

Aijun Wang
China Telecom


On Jul 28, 2022, at 06:39, Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
(Preamble: All of what I am going to say I have said many times before – on the 
list – off the list – in private conversations – in WG meetings…
I don’t say this to start a discussion with the WG authors – it seems clear 
that we don’t agree and have no path to agreement.
My purpose in saying this is to respond to the ongoing existence of this draft 
and offering my opinion as to what action the WG should take.)

The mechanism defined in this draft is broken. Not only is it not backwards 
compatible – the PUA advertisements will be misinterpreted to mean the exact 
opposite of what is intended i.e., the intent is to signal that a prefix is 
unreachable, but you do so by using an advertisement which legacy nodes MUST 
interpret as meaning reachable. This is simply broken and should not be done.

The authors deserve credit for bringing the attention of the WG to the problem 
space – but the solution offered is not deployable. Given the long period of 
time during which this draft has been published and the many times it has been 
presented/discussed in the WG I think it is now time to sa

Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

[Acee Lindem (acee)]

Hi Ketan,
I’m glad you brought this up. The primary (and AFAIK only) reason for this 
draft is to get the stub-link information to a router in the IGP domain running 
BGP-LS so that it can be advertised to the controller. For reference, see 
https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt
 figure 1. So, the IGP encoding is only to get the stub-link information from 
B1 and B3 to S2 and from B2 and B4 to T1. Since the IGPs and TE are not 
consuming the information, the problem could be avoid by simply running BGP-LS 
on B1-B4. See inline.


From: Lsr  on behalf of Ketan Talaulikar 

Date: Wednesday, July 27, 2022 at 5:33 AM
To: "draft-wang-lsr-stub-link-attribu...@ietf.org" 

Cc: lsr 
Subject: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

Hello Authors,

Please find below my comments/suggestions on this draft. I am sharing them 
upfront given the packed LSR agenda.


  1.  Sec 3 the rationale provided for not using the Inter-AS TE LSAs/TLVs is 
not sound in my opinion. I would say that the TE encoding may not be suitable 
for use in all deployments as their advertisement results in the addition of 
those Inter-AS links in a TE topology database and that may not be desired. So, 
I would suggest that the draft keeps the option of use of Inter-AS TE TLVs 
valid and goes ahead with the Stub Link proposal as an alternative with broader 
applicability (also see the next comment).

Agree.


  1.  For the proclaimed wider applicability (e.g., links to servers/hosts) in 
the slides, there is no such text in the draft. The draft seems focused on 
Inter-AS links. I hope the authors update either the draft or the slides - to 
be in sync with their objectives.

It is solely for purposes of advertisement in BGP-LS and consumption by the SDN 
controller as described in 
https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt.



  1.  The use of the prefix TLVs in this context is something that is (in my 
opinion) broken from day 1 of this draft. Prefixes are for reachability. For 
identification of links, we have the local/remote link identifiers along with 
the local/remote IP addresses (NOT prefixes!). This to me is a NO-GO for the 
progression of this document.

I agree, if this draft is to persist, these should be referred to as ASBR 
addresses as in the IDR draft (the sole raison d’etre for this IGP draft).


  1.  The placement of the Stub Link TLV should be top-level (similar to 
other/existing links). I can share further suggestions offline, provided we 
reach an agreement on the above points and we converge on the main 
purpose/motivation for this work.

I feel that strongly here as this is analogous to the new BGP-LS NLRI type in  
https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt.

Thanks,
Acee


Thanks,
Ketan

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

Re: [Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Acee Lindem (acee)]

Hi All.

What is the expected action if all routers in the area do not support 
multi-part TLVs? Does the advertising router simply not advertise the 
information that doesn’t fit? This needs to be specified.

In general, I’m not a fan of these all or none IGP capabilities but sometimes 
they can’t be avoided.

Thanks,
Acee

From: Lsr  on behalf of Ketan Talaulikar 

Date: Friday, July 22, 2022 at 11:20 AM
To: Tony Li 
Cc: lsr 
Subject: Re: [Lsr] Fwd: New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt

Hi Tony & Co-authors,

The introduction of the capabilities (at this stage) might be a challenge given 
existing implementations that do multi-part TLVs and are shipping and deployed. 
If this was intended mainly to aid debugging and for the operator to evaluate 
the capabilities in the network, it might be helpful. However, triggering 
anything based on network-wide capability determination might turn out to be 
problematic.

There was this text in v00 of the draft in sec 3 (perhaps it should have been 
in sec 4).


   Note: If the fixed portion of a TLV includes information that is NOT

   part of the key and the non-key elements of the fixed portion of the

   TLV (metric and other bits in the control octet in the example below)

   differ, the values in the first TLV present in the lowest numbered

   LSP MUST be used.

This seems to have been omitted from v01. Not sure if this was specifically 
intended and if so, I think the above text is important to clarify.

There is also this more general thing about sub-TLVs that are supposed to be 
advertised only once and if there are multiple instances of them (this might 
happen in transient situations), then the instance in the lowest 
number/fragment is considered valid and others ignored. There are specs that 
say this, but perhaps there are others that don't? So can this be also 
considered for addition as a "general" rule even though it is slightly 
different from the multi-part TLV focus of the draft?

And thanks for keeping the discussion on clarifications of keys (at least for a 
few important sub-TLV/TLV) still on the table :-)

Thanks,
Ketan

On Tue, Jul 5, 2022 at 6:39 AM Tony Li 
mailto:tony...@tony.li>> wrote:

Hi all,

This is an update to reflect some of the discussions to date. A diff is 
attached.  Most of this is a change to terminology to stop using the word 
‘instance’ and shift to using ‘multi-part TLV’.

We have been having a discussion about adding more discussion of keys in this 
document.  We have not done that yet.  This is not an indication of refusal, 
just making one baby step forward.  More to come… Text contributions are more 
than welcome.

Other comments?

Regards,
Tony






Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt
Date: July 4, 2022 at 6:04:37 PM PDT
To: "Antoni Przygienda" mailto:p...@juniper.net>>, "Chris 
Bowers" mailto:cbo...@juniper.net>>, "Les Ginsberg" 
mailto:ginsb...@cisco.com>>, "Parag Kaneriya" 
mailto:pkane...@juniper.net>>, "Shraddha Hegde" 
mailto:shrad...@juniper.net>>, "Tony Li" 
mailto:tony...@tony.li>>, "Tony Przygienda" 
mailto:p...@juniper.net>>


A new version of I-D, draft-pkaneria-lsr-multi-tlv-01.txt
has been successfully submitted by Tony Li and posted to the
IETF repository.

Name: draft-pkaneria-lsr-multi-tlv
Revision: 01
Title: Multi-part TLVs in IS-IS
Document date: 2022-07-04
Group: Individual Submission
Pages: 7
URL:
https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-01.txt
Status: https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-pkaneria-lsr-multi-tlv-01

Abstract:
  New technologies are adding new information into IS-IS while
  deployment scales are simultaneously increasing, causing the contents
  of many critical TLVs to exceed the currently supported limit of 255
  octets.  Extensions such as [RFC7356] require significant IS-IS
  changes that could help address the problem, but a less drastic
  solution would be beneficial.  This document codifies the common
  mechanism of extending the TLV content space through multiple TLVs.




The IETF Secretariat


___
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] 答复: IETF 114 LSR Slot Request

[Acee Lindem (acee)]

Hi Chenxi,

I guess you don’t normally follow the LSR list…

Our agenda is more than full for IETF 114 and we intend to have an interim.

Thanks,
Acee

From: "lichenxi (A)" 
Date: Friday, July 15, 2022 at 8:30 AM
To: Yingzhen Qu , "lsr@ietf.org" 
Cc: "lsr-cha...@ietf.org" 
Subject: 答复: [Lsr] IETF 114 LSR Slot Request
Resent-From: 
Resent-To: Acee Lindem , Yingzhen Qu , 
Christian Hopps 
Resent-Date: Friday, July 15, 2022 at 8:30 AM

Hi YingZhen and chairs,

I would like to request one slot:
Draft: IS-IS Traffic Engineering (TE) Metric LAN Extensions, 
https://datatracker.ietf.org/doc/draft-li-lsr-isis-te-metric-lan-extensions/
Speaker:  Chenxi Li
Time:   10 minutes


发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Yingzhen Qu
发送时间: 2022年6月28日 15:04
收件人: lsr@ietf.org
抄送: lsr-cha...@ietf.org
主题: [Lsr] IETF 114 LSR Slot Request

Hi,

The preliminary agenda for IETF 114 has been posted: 
https://datatracker.ietf.org/meeting/114/agenda/

LSR will have one session:

Friday, July 29, 2022
12:30 - 14:30 Session II
Liberty B

Please send slot request to lsr-cha...@ietf.org. 
Please include draft name, presenter, slot length including Q&A.

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

Re: [Lsr] [GROW] [Idr] IGP Monitoring Protocol

[Acee Lindem (acee)]

See one typo.

From: GROW  on behalf of "Acee Lindem (acee)" 

Date: Monday, July 11, 2022 at 10:45 AM
To: Gyan Mishra , Yingzhen Qu 
Cc: IDR List , "g...@ietf.org g...@ietf.org" , 
lsr 
Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

Hi Gyan,

From: GROW  on behalf of Gyan Mishra 

Date: Monday, July 11, 2022 at 1:41 AM
To: Yingzhen Qu 
Cc: IDR List , "g...@ietf.org g...@ietf.org" , 
lsr 
Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

Hi Yingzhen

So with OSPFV2 using RFC 6549 would support multiple instances or OSPFV3 
already supports instances, how is the GT instance differentiated from any 
other routed instance?

Did you read the draft? The main difference is that since OSPF-GT is 
generalized to be used for non-routing, there is installation of routes.

“No installation of routes”…


OSPF-GT neighbors need not be directly attached (or come with complex OSPF 
Virtual-Link considerations and processing). Depending on the application, the 
extent to which the “condition of reachability” is enforced MUST be described 
in the document describing the application usage of OSPF-GT.


For OSPFV2 it would use Opaque LSA Type 9,10,21 similar to RSVP-TE with an 
opaque option code for GTI.

For OSPFV3 it would use an OSPFV3 function code for GTI.

So the NBI BGP-LS peering to the PCE/SDN controller would be replaced with a   
OSPF GTI neighbor ?

It could be but that is just one OSPF-GT use case and would need to be 
described in a separate draft.

Would you still need a standard routed OSPF neighbor for reachability or I 
guess you could put a static route on the controller across the NBI for 
reachability.

Yes.

Is that correct?

Are there any operators implementations of this using OSPF GTI in place of 
BGP-LS?

You mean OSPF-GT… Since the draft to describe the details of using OSPF-GT in 
place of BGP-LS is yet to be written, it would be very strange indeed if it 
were already deployed. 😉

RFC 6823 provides the same GTI solution for ISIS.

Yes and no, OSPF-GT is able to cover a much wider range of applications than 
RFC 683. This is due mostly to OSPF (and especially OSPFv3 with extended LSAs) 
being much more flexible than IS-IS.


Are there any operators implementations of this using OSPF GTI in place of 
BGP-LS?

No - answered above.

Thanks,
Acee


Kind Regards

Gyan

On Sun, Jul 10, 2022 at 1:04 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:
Hi,

Since we’re discussing possible solutions, I’d like to bring up the draft: 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/

We just submitted a new version. The name of the document is changed to 
“OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT as a 
possible replacement of BGP-LS.

Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate routes. 
It uses the reachability info calculated by routing protocols, OSPF, ISIS or 
static routing etc.. It provides mechanisms to advertise non-routing 
information, and remote neighbor is supported.

Reviews and comments are welcome.


Thanks,
Yingzhen


On Jul 9, 2022, at 5:33 PM, Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:


During the interim meeting we should keep it open to discuss all possible 
alternatives to BGP-LS.

Thanks

Gyan

On Sat, Jul 9, 2022 at 4:45 PM Susan Hares 
mailto:sha...@ndzh.com>> wrote:
Jeff:

An interim sounds like a good plan.

[IDR-chair hat]
Alvaro has indicated that since all of the proposal received on the IDR list 
are new protocol proposals,
· Capturing IDR’s input on BGP-LS problems and potential solutions is 
appropriate for IDR as BGP-LS home.
· Refining any potential non-BGP solutions is outside of the scope of 
IDR.

[IDR-chair hat off]
[rtgwg WG member]
I’d love to attend an interim on this topic.

Sue Hares


From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Sent: Saturday, July 9, 2022 3:40 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; lsr 
mailto:lsr@ietf.org>>; i...@ietf.org<mailto:i...@ietf.org>; Susan 
Hares mailto:sha...@ndzh.com>>; 
g...@ietf.org<mailto:g...@ietf.org> g...@ietf.org<mailto:g...@ietf.org> 
mailto:g...@ietf.org>>
Subject: Re: [Idr] [Lsr] IGP Monitoring Protocol



Speaking as RTGWG chair:

Robert - I don’t think we’d have enough time to accommodate a good discussion 
during IETF114 (we got only 1 slot), however would be happy to provide a 
platform for an interim.
The topic is important and personally (being a very large BGP-LS user) I’d like 
to see it progressing.
Cheers,
Jeff

On Jul 8, 2022, at 14:44, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Acee,

Yes, by all means input from the operator's community is needed. It can be 
collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We 
have already seen input from some operators and their opinion

Re: [Lsr] [GROW] [Idr] IGP Monitoring Protocol

[Acee Lindem (acee)]

Hi Gyan,

From: GROW  on behalf of Gyan Mishra 

Date: Monday, July 11, 2022 at 1:41 AM
To: Yingzhen Qu 
Cc: IDR List , "g...@ietf.org g...@ietf.org" , 
lsr 
Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

Hi Yingzhen

So with OSPFV2 using RFC 6549 would support multiple instances or OSPFV3 
already supports instances, how is the GT instance differentiated from any 
other routed instance?

Did you read the draft? The main difference is that since OSPF-GT is 
generalized to be used for non-routing, there is installation of routes. 
OSPF-GT neighbors need not be directly attached (or come with complex OSPF 
Virtual-Link considerations and processing). Depending on the application, the 
extent to which the “condition of reachability” is enforced MUST be described 
in the document describing the application usage of OSPF-GT.


For OSPFV2 it would use Opaque LSA Type 9,10,21 similar to RSVP-TE with an 
opaque option code for GTI.

For OSPFV3 it would use an OSPFV3 function code for GTI.

So the NBI BGP-LS peering to the PCE/SDN controller would be replaced with a   
OSPF GTI neighbor ?

It could be but that is just one OSPF-GT use case and would need to be 
described in a separate draft.

Would you still need a standard routed OSPF neighbor for reachability or I 
guess you could put a static route on the controller across the NBI for 
reachability.

Yes.

Is that correct?

Are there any operators implementations of this using OSPF GTI in place of 
BGP-LS?

You mean OSPF-GT… Since the draft to describe the details of using OSPF-GT in 
place of BGP-LS is yet to be written, it would be very strange indeed if it 
were already deployed. 😉

RFC 6823 provides the same GTI solution for ISIS.

Yes and no, OSPF-GT is able to cover a much wider range of applications than 
RFC 683. This is due mostly to OSPF (and especially OSPFv3 with extended LSAs) 
being much more flexible than IS-IS.


Are there any operators implementations of this using OSPF GTI in place of 
BGP-LS?

No - answered above.

Thanks,
Acee


Kind Regards

Gyan

On Sun, Jul 10, 2022 at 1:04 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:
Hi,

Since we’re discussing possible solutions, I’d like to bring up the draft: 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/

We just submitted a new version. The name of the document is changed to 
“OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT as a 
possible replacement of BGP-LS.

Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate routes. 
It uses the reachability info calculated by routing protocols, OSPF, ISIS or 
static routing etc.. It provides mechanisms to advertise non-routing 
information, and remote neighbor is supported.

Reviews and comments are welcome.


Thanks,
Yingzhen



On Jul 9, 2022, at 5:33 PM, Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:


During the interim meeting we should keep it open to discuss all possible 
alternatives to BGP-LS.

Thanks

Gyan

On Sat, Jul 9, 2022 at 4:45 PM Susan Hares 
mailto:sha...@ndzh.com>> wrote:
Jeff:

An interim sounds like a good plan.

[IDR-chair hat]
Alvaro has indicated that since all of the proposal received on the IDR list 
are new protocol proposals,
· Capturing IDR’s input on BGP-LS problems and potential solutions is 
appropriate for IDR as BGP-LS home.
· Refining any potential non-BGP solutions is outside of the scope of 
IDR.

[IDR-chair hat off]
[rtgwg WG member]
I’d love to attend an interim on this topic.

Sue Hares


From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Sent: Saturday, July 9, 2022 3:40 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; lsr 
mailto:lsr@ietf.org>>; i...@ietf.org<mailto:i...@ietf.org>; Susan 
Hares mailto:sha...@ndzh.com>>; 
g...@ietf.org<mailto:g...@ietf.org> g...@ietf.org<mailto:g...@ietf.org> 
mailto:g...@ietf.org>>
Subject: Re: [Idr] [Lsr] IGP Monitoring Protocol



Speaking as RTGWG chair:

Robert - I don’t think we’d have enough time to accommodate a good discussion 
during IETF114 (we got only 1 slot), however would be happy to provide a 
platform for an interim.
The topic is important and personally (being a very large BGP-LS user) I’d like 
to see it progressing.
Cheers,
Jeff

On Jul 8, 2022, at 14:44, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Acee,

Yes, by all means input from the operator's community is needed. It can be 
collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We 
have already seen input from some operators and their opinion on adding and 
distributing more and more link state protocol and topology data in BGP. More 
such input is very welcome.

And to your point about RFC9086 - I see nothing wrong in keeping BGP 
information in BGP. So IGP Monitoring Protocol does not target to shut down 
BGP-LS. It only aims to 

Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

[Acee Lindem (acee)]

Hi Robert,

From: Lsr  on behalf of Robert Raszuk 
Date: Sunday, July 10, 2022 at 1:32 PM
To: Yingzhen Qu 
Cc: Gyan Mishra , Susan Hares , IDR 
List , "g...@ietf.org g...@ietf.org" , lsr 

Subject: Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

Hi Yingzhen & OSPF-GT authors,

UP front I must state that anything is better to export IGP information from 
routers to interested nodes than using BGP for it.

But to propose using OSPF to transport ISIS seems pretty brave :) I must admit 
it !

With that I have few questions to the proposal - assuming the use case is to 
distribute links state info in a point to point fashion:


  1.  What is the advantage - if any - to use a new OSPF instance/process to 
send link state data over a unicast session to a controller ?

It doesn’t have to be unicast, the remote neighbor construct just extends the 
possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is all the 
protocol machinery is in place.  Note that LSDB streaming is just but one use 
case and of OSPF-GT. The detals of this application would be specified in a 
separate draft.



  1.  The draft is pretty silent on the nature of such a p2p session. Please be 
explicit if this is TCP, QUIC or what ?

It is OSPF, OSPF has its own protocol identifier (89). This draft just extends 
OSPF. I think you’ve misinterpreted the draft. Hence, your other questions 
aren’t really applicable or would be answered in a draft of the OSPF/IS-IS LSDB 
usage of OSPF-GT.

Thanks,
Acee



C) The draft is pretty silent on types of authentication for such sessions. 
Security considerations are pretty weak in that respect as well.

   The security considerations for OSPF-GT will be similar to those for
   OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
   used to update OSPF routing, the consequences of attacks will be
   dependent on advertised non-routing information.

I would actually argue that security considerations of p2p remote neighbors are 
actually quite different from security considerations of flooding data.

Along the same lines security is not about protecting your routing ... it is 
much more about protecting the entire network by exposing critical information 
externally to non authorized parties.

D) Are there any PUB-SUB options possible for OSPF-GT ?

E) Is there any filtering possible for OSPF-GT ?

F) Are you envisioning use of OSPF-GT proxies and if so are you planning to add 
this to the document ?

G) How are you going to address Receivers which do not support OSPF-GT parser ?

H) As you know many operators are attracted to BGP-LS based on the fact that it 
offers the same view of information irrespective of what is the protocol 
producing the data. Is there some thought on such normalization in the OSPF-GT 
proposal ?

I) What's the take of OSPF-GT draft authors on the YANG model in respect of 
using it for normalization of exported data ?

To summarize IMHO we should not stretch routing protocols be it OSPF, ISIS or 
BGP to be messengers of link state data running and to artificially force them 
to run in a point-to-point model between router and controller.

Kind regards,
Robert


On Sun, Jul 10, 2022 at 7:04 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:
Hi,

Since we’re discussing possible solutions, I’d like to bring up the draft: 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/

We just submitted a new version. The name of the document is changed to 
“OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT as a 
possible replacement of BGP-LS.

Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate routes. 
It uses the reachability info calculated by routing protocols, OSPF, ISIS or 
static routing etc.. It provides mechanisms to advertise non-routing 
information, and remote neighbor is supported.

Reviews and comments are welcome.


Thanks,
Yingzhen


On Jul 9, 2022, at 5:33 PM, Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:


During the interim meeting we should keep it open to discuss all possible 
alternatives to BGP-LS.

Thanks

Gyan

On Sat, Jul 9, 2022 at 4:45 PM Susan Hares 
mailto:sha...@ndzh.com>> wrote:
Jeff:

An interim sounds like a good plan.

[IDR-chair hat]
Alvaro has indicated that since all of the proposal received on the IDR list 
are new protocol proposals,
· Capturing IDR’s input on BGP-LS problems and potential solutions is 
appropriate for IDR as BGP-LS home.
· Refining any potential non-BGP solutions is outside of the scope of 
IDR.

[IDR-chair hat off]
[rtgwg WG member]
I’d love to attend an interim on this topic.

Sue Hares


From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Sent: Saturday, July 9, 2022 3:40 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; lsr 
mailto:lsr@ietf.org>>; i...@ietf.org<mailto:i...@ietf.org>; Susan 
Hares mailto:sh

Re: [Lsr] Early allocation request for code points in draft-ietf-lsr-ospfv3-srv6-extensions

[Acee Lindem (acee)]

Hi John,

From: John Scudder 
Date: Friday, July 8, 2022 at 7:13 PM
To: Acee Lindem 
Cc: IANA , lsr , 
draft-ietf-lsr-ospfv3-srv6-extensions 

Subject: Re: Early allocation request for code points in 
draft-ietf-lsr-ospfv3-srv6-extensions

Hi Acee,

Can I assume you’ve already checked on the RFC 7120 Section 2 conditions being 
met?

Yes – I recently reviewed the document and I don’t expect non-backward 
compatible changes to the specifications since an implementation is in progress.

Thanks,
Acee

Thanks,

—John

On Jul 8, 2022, at 6:38 PM, Acee Lindem (acee)  wrote:
Hi IANA Team, John,

The authors of the subject draft have requested early codepoint allocation as 
there are implementations in progress and I, as document shepherd, believe that 
this is overdue. Can we start the approval/allocation process?

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

[Lsr] Early allocation request for code points in draft-ietf-lsr-ospfv3-srv6-extensions

[Acee Lindem (acee)]

Hi IANA Team, John,

The authors of the subject draft have requested early codepoint allocation as 
there are implementations in progress and I, as document shepherd, believe that 
this is overdue. Can we start the approval/allocation process?

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

Re: [Lsr] IGP Monitoring Protocol

[Acee Lindem (acee)]

Hi Robert,

From: Robert Raszuk 
Date: Friday, July 8, 2022 at 4:36 PM
To: Acee Lindem 
Cc: lsr , IDR List , Susan Hares 
Subject: Re: [Lsr] IGP Monitoring Protocol

Hi Acee,

Thank you. I was not planning to present it in the upcoming IETF.

> Let’s see how many stakeholders actually want to this protocol - then we can 
> talk about a WG home.

An alternative approach could be to see how many stakeholders do not want to 
further (for no good reason) to trash BGP. That to me would be in this specific 
case a much better gauge.

In that case, it seems to me that this discussion should be relegated to IDR. 
Note that there is already non-IGP information transported in BGP-LS, e.g., 
Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/). I 
implemented this on our data center routers (NXOS) years and it is solely BGP 
specific.

Thanks,
Acee

Kind regards,
Robert


On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Speaking as WG chair:

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Friday, July 8, 2022 at 3:21 PM
To: lsr mailto:lsr@ietf.org>>
Cc: IDR List mailto:i...@ietf.org>>, Susan Hares 
mailto:sha...@ndzh.com>>
Subject: [Lsr] IGP Monitoring Protocol

Dear LSR WG,

Based on ongoing discussion in respect to the future of BGP-LS I committed 
myself to put together an alternate proposal.

The main goal is not to just publish a -00 version of the draft using different 
encapsulation. The goal is to make a useful tool which can help to export link 
state information from network elements as well as assist in network 
observability.

The IGP Monitoring Protocol (IMP) draft has been posted and should be available 
at:

https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/

One of the key points I wanted to accomplish was full backwards compatibility 
with TLVs defined for BGP-LS. In parallel other formats (optional) are also 
supported.

The PUB-SUB nature or FILTERING capabilities are in the spec however as noted 
in the deployment section there is no expectation that this should be supported 
directly on routers. Concept of Producer's Proxies has been introduced to 
support this added functionality as well as provide fan-out (analogy to BGP 
route reflectors).

I encourage everyone interested to take a look and provide comments. At this 
point this document is nothing more than my individual submission. Offline I 
have had few conversations with both operators and vendors expressing some 
level of interest in this work. How we proceed further (if at all :) depends on 
WG feedback.

Kind regards,
Robert.

PS, I do believe this work belongs in LSR WG pretty squerly.

Let’s see how many stakeholders actually want to this protocol - then we can 
talk about a WG home.  By stakeholders, I mean operators and vendors who are 
committed to implementing and deploying it - not simply those who you are able 
to enlist as co-authors. Note that our IETF 114 LSR agenda is full (with 
multiple agenda items not making the cut).

Thanks,
Acee



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

Re: [Lsr] IGP Monitoring Protocol

[Acee Lindem (acee)]

Speaking as WG chair:

From: Lsr  on behalf of Robert Raszuk 
Date: Friday, July 8, 2022 at 3:21 PM
To: lsr 
Cc: IDR List , Susan Hares 
Subject: [Lsr] IGP Monitoring Protocol

Dear LSR WG,

Based on ongoing discussion in respect to the future of BGP-LS I committed 
myself to put together an alternate proposal.

The main goal is not to just publish a -00 version of the draft using different 
encapsulation. The goal is to make a useful tool which can help to export link 
state information from network elements as well as assist in network 
observability.

The IGP Monitoring Protocol (IMP) draft has been posted and should be available 
at:

https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/

One of the key points I wanted to accomplish was full backwards compatibility 
with TLVs defined for BGP-LS. In parallel other formats (optional) are also 
supported.

The PUB-SUB nature or FILTERING capabilities are in the spec however as noted 
in the deployment section there is no expectation that this should be supported 
directly on routers. Concept of Producer's Proxies has been introduced to 
support this added functionality as well as provide fan-out (analogy to BGP 
route reflectors).

I encourage everyone interested to take a look and provide comments. At this 
point this document is nothing more than my individual submission. Offline I 
have had few conversations with both operators and vendors expressing some 
level of interest in this work. How we proceed further (if at all :) depends on 
WG feedback.

Kind regards,
Robert.

PS, I do believe this work belongs in LSR WG pretty squerly.

Let’s see how many stakeholders actually want to this protocol - then we can 
talk about a WG home.  By stakeholders, I mean operators and vendors who are 
committed to implementing and deploying it - not simply those who you are able 
to enlist as co-authors. Note that our IETF 114 LSR agenda is full (with 
multiple agenda items not making the cut).

Thanks,
Acee



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

Re: [Lsr] WG last call for draft-ietf-lsr-ospf-terminology-00

[Acee Lindem (acee)]

Speaking as WG Member: 

Here is the update I intend to submit today:

   Additionally, in Section 2.4.,first paragraph, "Changes to the Hello
   Packet Processing", the text is updated to remove the non-inclusive
   terms pertaining to unreachability handling as follows:

  When an OSPFv3 router does not support this specification and an
  interface is configured with the Instance ID corresponding to a
  IPv4 AF, packets could be routed toward this interface and
  dropped. This could happen due to misconfiguration or a router
  software downgrade. Packet reception and dropping on an
  interface not configured with the packet AF, e.g., IPv4 is
  possible because a router that doesn't support this specification
  can still be included in the  SPF calculated path as long as it
  establishes adjacencies using the Instance ID corresponding to
  the IPv4 AF. Note that OSPPFv3 Router-LSAs and Network-LSAs are
  AF-agnostic.

 Figure 1: RFC 5838, Section 2.4 - Updated First Paragraph

Thanks,
Acee

On 7/7/22, 6:23 PM, "Alvaro Retana"  wrote:

On July 7, 2022 at 6:04:30 PM, Adrian Farrel wrote:


Adrian:

Hi!


...
> I checked the mailing list and couldn't find any discussion of this point 
so:
> is there any reason why the term "black hole" is also not being 
addressed? It
> seems to fall under the NIST guidance ("Avoid terms that use ‘black’ to 
mean
> something bad or negative") and is present in 5838.

No reason beyond the fact that we didn't comb through the documents enough 
-- the initial focus being put on terms that may show up on CLIs.

If there's no objection we can update the draft.

Also, if there are other terms that we missed, please point them out.

Thanks!

Alvaro. 

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

[Lsr] "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-20

[Acee Lindem (acee)]

Hi John,

I’ve received multiple queries as to what is holding up this draft.

https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

it is referenced by several drafts awaiting publication in cluster 447.

https://www.rfc-editor.org/cluster_info.php?cid=C447

Can you please make this a priority?

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

Re: [Lsr] [Idr] YANG requirements for IDR drafts (was Re: draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20))

[Acee Lindem (acee)]

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Tuesday, July 5, 2022 at 5:23 PM
To: Robert Raszuk , Jeff Haas 
Cc: Susan Hares , IDR List , lsr 
Subject: Re: [Lsr] [Idr] YANG requirements for IDR drafts (was Re: 
draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20))

Hi Robert,

Like the SNMP MIBs before them, the YANG models trail the routing protocol 
functional drafts. We have enough trouble satisfying all the references without 
requiring YANG models.

I mean requiring YANG models in the same drafts as the routing protocol 
features. We do require YANG models and as Jeff noted we need to publish the 
base models first and have a number of enhancements drafts in progress. You can 
use the IETF data tracker to check the status of these.

Thanks,
Acee


If you pay attention during the WG document status at IETF 114, you’ll get a 
picture of where the base and enhancement models are in the IETF life cycle.

See one inline.

From: Idr  on behalf of Robert Raszuk 
Date: Tuesday, July 5, 2022 at 4:37 PM
To: Jeff Haas 
Cc: Susan Hares , IDR List , lsr 
Subject: Re: [Idr] YANG requirements for IDR drafts (was Re: 
draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20))

Hi Jeff,

Many thx for your note. As I clarified to Sue my question was really about LSR 
WG not IDR :)

And the trigger was Gunter's claim that his employer's OS is already sending 
content of LSDB over YANG.

So I was a bit puzzled what happens with new extensions if they like ISIS 
reflection if they do not contain the YANG model from day one ? How is that 
data being encoded if at all ?

I guess you aren’t working with many vendor products. Most vendors use 
primarily native YANG models for configuration and operational state.

Thanks,
Acee

That answer is also important to alternative to BGP-LS discussion but let's 
have a separate discussion on this in the coming weeks.

Best,
R.


On Tue, Jul 5, 2022 at 10:28 PM Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:
Robert,


On Jun 30, 2022, at 6:56 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Isn't the YANG section a requirement for all protocol extension documents 
before they are sent for publications these days ?


We're not yet to the point where extensions to YANG modules are part of base 
IETF work, but we're probably going to need to have that discussions soon 
across IETF.

This year will see base YANG modules for a number of protocols done.  I had 
hoped I could contribute toward the BGP YANG module getting done closer to 
start of year than not, the BGP module is more likely to be complete this 
fall.[1]

Once we have the base modules out, augmentations for them covering various 
extensions will make sense.  Prior to the publication of the base modules, we 
wouldn't have had the documents advance due to MISREF dependencies.

Once our base module is out, we'll have need of a number of small augmentation 
modules to fill in the missing features.  If you're looking to help with that 
work, there's probably room to start writing some drafts now.  I think the BGP 
YANG module is structurally solid for most configuration and operational state. 
 Policy is the remaining large piece of work.

That said, I think we'll find trying to write YANG for BGP-LS challenging.

The reason I am asking this is in fact in light of the other discussions we 
have on IDR list where at least one mode of link state state advertisement can 
be done using YANG encoding. Is YANG section optional in LSR WG documents which 
define new protocol extensions and new functionality ? If an implementation 
uses YANG to push LSDB how the new TLVs defined in the draft are going to be 
shared across ?

I think your broader question about what a streaming protocol for IGP state 
looks like is probably best addressed in those threads.  But, as above, it's 
going to be an interesting modeling exercise.

-- Jeff

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

Re: [Lsr] [Idr] YANG requirements for IDR drafts (was Re: draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20))

[Acee Lindem (acee)]

Hi Robert,

Like the SNMP MIBs before them, the YANG models trail the routing protocol 
functional drafts. We have enough trouble satisfying all the references without 
requiring YANG models. If you pay attention during the WG document status at 
IETF 114, you’ll get a picture of where the base and enhancement models are in 
the IETF life cycle.

See one inline.

From: Idr  on behalf of Robert Raszuk 
Date: Tuesday, July 5, 2022 at 4:37 PM
To: Jeff Haas 
Cc: Susan Hares , IDR List , lsr 
Subject: Re: [Idr] YANG requirements for IDR drafts (was Re: 
draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20))

Hi Jeff,

Many thx for your note. As I clarified to Sue my question was really about LSR 
WG not IDR :)

And the trigger was Gunter's claim that his employer's OS is already sending 
content of LSDB over YANG.

So I was a bit puzzled what happens with new extensions if they like ISIS 
reflection if they do not contain the YANG model from day one ? How is that 
data being encoded if at all ?

I guess you aren’t working with many vendor products. Most vendors use 
primarily native YANG models for configuration and operational state.

Thanks,
Acee

That answer is also important to alternative to BGP-LS discussion but let's 
have a separate discussion on this in the coming weeks.

Best,
R.


On Tue, Jul 5, 2022 at 10:28 PM Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:
Robert,


On Jun 30, 2022, at 6:56 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Isn't the YANG section a requirement for all protocol extension documents 
before they are sent for publications these days ?


We're not yet to the point where extensions to YANG modules are part of base 
IETF work, but we're probably going to need to have that discussions soon 
across IETF.

This year will see base YANG modules for a number of protocols done.  I had 
hoped I could contribute toward the BGP YANG module getting done closer to 
start of year than not, the BGP module is more likely to be complete this 
fall.[1]

Once we have the base modules out, augmentations for them covering various 
extensions will make sense.  Prior to the publication of the base modules, we 
wouldn't have had the documents advance due to MISREF dependencies.

Once our base module is out, we'll have need of a number of small augmentation 
modules to fill in the missing features.  If you're looking to help with that 
work, there's probably room to start writing some drafts now.  I think the BGP 
YANG module is structurally solid for most configuration and operational state. 
 Policy is the remaining large piece of work.

That said, I think we'll find trying to write YANG for BGP-LS challenging.

The reason I am asking this is in fact in light of the other discussions we 
have on IDR list where at least one mode of link state state advertisement can 
be done using YANG encoding. Is YANG section optional in LSR WG documents which 
define new protocol extensions and new functionality ? If an implementation 
uses YANG to push LSDB how the new TLVs defined in the draft are going to be 
shared across ?

I think your broader question about what a streaming protocol for IGP state 
looks like is probably best addressed in those threads.  But, as above, it's 
going to be an interesting modeling exercise.

-- Jeff

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

Re: [Lsr] Early allocation request for code points in draft-ietf-lsr-ospfv3-srv6-extensions

[Acee Lindem (acee)]

I think this is a great idea – I have heard rumors that there is an 
implementation in progress. I’ll send an Email to the AD and IANA…
Thanks,
Acee

From: Lsr  on behalf of Ketan Talaulikar 

Date: Friday, July 1, 2022 at 8:20 AM
To: "lsr-cha...@ietf.org" 
Cc: lsr 
Subject: [Lsr] Early allocation request for code points in 
draft-ietf-lsr-ospfv3-srv6-extensions

Hello Acee/Chris,

We (authors) would like to request for early allocation of code points by IANA 
for 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-05

More specifically for the suggested values in the following sections:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-05#section-12.1
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-05#section-12.2
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-05#section-12.3

Thanks,
Ketan (on behalf of co-authors)

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

Re: [Lsr] Request 5-10 minutes

[Acee Lindem (acee)]

We will reserve  time on the agenda for this since it is important. However, 
I’d hope we (the LSR chairs) would be involved as well.
Thanks,
Acee

From: Susan Hares 
Date: Thursday, June 30, 2022 at 12:51 PM
To: Acee Lindem , "lsr@ietf.org" 
Subject: RE: [Lsr] Request 5-10 minutes

Acee:

A presentation on the rules for included BGP-LS TLVs in
LSR drafts will not occur in IDR or LSR unless you and Chris both agree
with the slides and the content of the slides.

If you do not have time in LSR – we will provide time
In IDR WG for Q&A on the topic.

Based on the feedback on the adoption call for
draft-head-idr-bgp-ls-isis-fr-00.txt
(now: draft-ietf-idr-bgp-ls-isis-flood-reduction-00.txt),
it appears the IDR chairs were unclear about the rules
for including BGP-LS TLVs in LSR specifications.

It seems wise to clarify these rules for BGP-LS TLVs
for LSR and IDR.

If we do not have consensus within the LSR and IDR chairs
on the rules for BGP-LS TLVs In LSR drafts by IETF-114,
we will go back to the previous mechanism of
requiring drafts in LSR and IDR.

Cheers, Sue

PS – I was going to work on the slides and a YouTube
Video for the slides this weekend.

From: Acee Lindem (acee) 
Sent: Thursday, June 30, 2022 12:37 PM
To: Susan Hares ; lsr@ietf.org
Subject: Re: [Lsr] Request 5-10 minutes


Note that to the best of my knowledge, the LSR chairs have not agreed to these 
slides so I must assume the agreement is amongst the IDR chairs?
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Susan Hares mailto:sha...@ndzh.com>>
Date: Thursday, June 30, 2022 at 12:24 PM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: [Lsr] Request 5-10 minutes

The IDR chairs wish to request 5-7 minute time slot to present
IDR chair agreement with LSR chairs on BGP-LS TLVs in
LSR WG drafts.

Cheers, Sue Hares




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

Re: [Lsr] Request 5-10 minutes

[Acee Lindem (acee)]

Note that to the best of my knowledge, the LSR chairs have not agreed to these 
slides so I must assume the agreement is amongst the IDR chairs?

Acee

From: Lsr  on behalf of Susan Hares 
Date: Thursday, June 30, 2022 at 12:24 PM
To: "lsr@ietf.org" 
Subject: [Lsr] Request 5-10 minutes

The IDR chairs wish to request 5-7 minute time slot to present
IDR chair agreement with LSR chairs on BGP-LS TLVs in
LSR WG drafts.

Cheers, Sue Hares




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

Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

[Acee Lindem (acee)]

Great – we’ll reserve time.
Thanks,
Acee

From: Tony Li  on behalf of Tony Li 
Date: Wednesday, June 29, 2022 at 2:44 PM
To: Acee Lindem 
Cc: Ketan Talaulikar , 
"draft-pkaneria-lsr-multi-...@ietf.org" 
, lsr 
Subject: Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link


Yes, we will.  We’re still discussing about who will present.  I can if there 
are no other volunteers.  You’re welcome to put my name down for now.

T



On Jun 29, 2022, at 11:26 AM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

Speaking as WG chair:

Can someone present this at IETF 114? It seems like there more interest than 
most of the other agenda requests.

Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Tony 
Li mailto:tony...@tony.li>>
Date: Wednesday, June 29, 2022 at 12:58 PM
To: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Cc: 
"draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>"
 
mailto:draft-pkaneria-lsr-multi-...@ietf.org>>,
 lsr mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link


Hi Ketan,




On Jun 29, 2022, at 9:33 AM, Ketan Talaulikar 
mailto:ketant.i...@gmail.com>> wrote:

Hi Tony,

No. It does not work. Take the following text from Sec 4.


   If this is insufficient sub-TLV space, then the node MAY advertise

   additional instances of the Extended IS Reachability TLV.  The key

   information MUST be replicated identically and the additional sub-TLV

   space may be populated with additional information.  The complete

   information for a given key in such cases is the joined set of all

   the carried information under the key in all the TLV instances.

There is a normative MUST there, but the "key information" is unspecified. 
Without that information these rules would not be really useful for 
implementation, would they?


They would if the implementors understood the intent and spirit. Perhaps that’s 
asking too much.





I agree with the challenge of trying to catalog "keys" and "rules" on a per 
TLV/sub-TLV basis. Perhaps starting with the more widely used TLVs/sub-TLVs 
that are likely to exceed limits would be better than not covering any of them?


Duly noted.  We have had this comment before, we will definitely consider it.

Tony


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