Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00

[bruno.decraene]

Les, all 
 
> From: Les Ginsberg (ginsberg)  
> 
> Chris -
> 
> 
> However, that is the missing piece, so it works if we also add a capability 
> bit. If we have the capability bit you now know which routers are processing 
> the container TLV and which aren't. That should be enough info to route 
> correctly.
> 
> Using a container TLV *and* a capability bit is not a free lunch, but it 
> should work to allow incremental deployment safely. If that's something we 
> want as a WG.
> 
> 
> No - this does not work.
> Customer deploys some features. They expect all routers in the network to be 
> able to correctly calculate topology and correctly forward for the features 
> they support.
> They do not deploy a feature and expect only a subset of the routers in the 
> network that are configured to support the feature to correctly calculate 
> paths.
> 
> There is no way to successfully support incremental deployment.

[Bruno]
1) globally consistent TLV or not
Probably the discussion we could make a distinction between:
- a- TLVs which are required to be consistent (typically the one involved in 
distributed SPF e.g. IP and IS reachability)
- b- TLVs which are not (e.g. SRv6 locators for algo 0 & 1, but there are 
probably others easier e.g. local adjacency SIDs for SR-MPLS)

For "a" there is no way to do incremental deployment. So it's either relying on 
careful deployment (and implementation) or relying on a capability. Both 
solution seems equal on this.
For "b" the big TLV will allow to deploy larger TLV without impacting legacy 
implementation. That's a benefit.

2) failing versus failing
Even when we need global consistency , there may be multiple failure modes to 
consider.
- One is not achieving global consistency, which will trigger adverse 
consequences. E.g. persistent forwarding loops for some path for data involved 
in SPF computations. Both solutions have the same properties 
- One is that the new advertisement is not correctly understood by legacy 
implementation and confuse them. This may trigger additional issues. E.g. 
larger set of inconsistencies as the first TLV instance/part may not become 
inconsistent anymore. Also, unfortunately, it's not unheard that some 
implementation are light on the error handling part (e.g. "undefined behavior", 
IS-IS process crash). In that regards, big-tlv seems to have an advantage in 
that legacy implementation are not impacted and everyone have a consistent view 
of the first TLV part.
. 

> > >>>We are not naïve - we understood very well that if not all routers in the
> > network supported at least reception of MP TLVs that there would be
> > deployment issues.

[Bruno]
Did network operators had the opportunity to comment on these deployment issues 
and discuss the involved trade-off?
I have never assumed that you were naïve and I don't feel that this was implied 
in the original email. IMO the question is that different person may have 
different perspective (which is just fine). So if the decision is taken by a 
single set of persons having a similar perspective, it's likely that the 
outcome optimization be only local.  e.g. pushing back the issue/complexity on 
the network operation side versus on the design/implementation side.

--Bruno

> 
> I already gave an example in my comments below:
> 
> > >> > [LES:] Consider the following simple example.
> > >> >
> > >> > Node A needs to send 10 sub-TLVs about a particular object –
> > >> > requiring more than 255 bytes to be sent.
> > >> >
> > >> > Some nodes in the network do not support reception of more than 255
> > >> > bytes/object. Consider two such nodes.
> > >> >
> > >> > Node B, based on the local configuration, needs to be able to receive
> > >> > sub-TLVs 1,3,5,7,9 from A.
> > >> >
> > >> > Node C, based on local configuration, needs to be able to receive
> > >> > sub-TLVs 2,4,6,8,10 from A.
> > >> >
> > >> >
> > >> >
> > >> > There is no way that A can advertise all 10 sub-TLVs in a way which
> > >> > allows both B and C to correctly process the sub-TLVs they require.
> > >> >
> 
   > Les
> 
> > -Original Message-
> > From: Christian Hopps 
> > Sent: Tuesday, March 28, 2023 9:52 AM
> > To: Les Ginsberg (ginsberg) 
> > Cc: Christian Hopps ; Huaimo Chen
> > ; draft-chen-lsr-isis-big-tlv.auth...@ietf.org;
> > lsr@ietf.org
> > Subject: Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00
> > 
> > 
> > "Les Ginsberg (ginsberg)"  writes:
> > 
> > > Chris -
> > >
> > > Please see inline - I'll try to conform to your request about ">>>" 
> > > quoting -
> > > but given that this style does not identify who made the comment, I have
> > found
> > > in the past that this style becomes very hard to follow after a couple of
> > > replies.
> > > Though perhaps that could be said of any style. 
> > 
> > Well in the ">>>" style my text that you were quoting would have been
> > 
> > "> like this"
> > 
> > and yours would not have anything preceding it.. like mine is here.
> > 
> > anyway, it's a losing 

[Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[bruno.decraene]

Hi authors,

Please find below some questions.


  1.  Assuming ABR1 advertises IP1 with metric 10 while ABR2 advertises IP1 
with MAX metric. Is this prefix reachable or unreachable (or both)?
  2.  Assuming ABR1 advertises a summary address but ABR2 does not. If ABR2 
advertises IP1 with MAX metric does this count as UPA? (i.e. may a router 
advertise unreachability for a prefix advertised by another router?)
  3.  Can you clarify the scope of the UPA signaling? E.g. if TLV 135 
advertises prefix IP1 with MAX metric
 *   does this signal UPA for all FlexAlgo?
 *   If IS-IS Flexible Algorithm Prefix Metric is advertised, is MAX metric 
to be advertised in the main TLV, or per FAPM sub-TLV, or both? Can you specify 
the behavior in case on "inconsistencies"?
 *   Does this signal UPA If the summary address (aka the less specific 
prefix) is advertised in a different IS-IS instance or in a different protocol 
(e.g. OSPF, BGP...)?
  4.  Is an UPA for a /24 equivalent to 255 UPA for /32? (i.e. will trigger BGP 
PIC edge for 255 /32)
  5.  For UPA of SRv6 locators for algo 0 or 1, is the MAX METRIC to be 
advertised for TLV 27 or 236 or both? Can you specify the behavior in case on 
"inconsistencies"?
  6.  "a summary address which covers the prefix is being advertised by the 
ABR/ASBR". For IS-IS, does the Attached bit count as a summary address or is it 
needed to advertise a summary address in IP reachability?

Ideally it would be good if the draft were updated to answer the above 
questions.

Thanks,
Regards,
--Bruno

_

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] draft-ietf-lsr-isis-fast-flooding-03.txt

[bruno.decraene]

Hi all,

We have updated the document with the following changes:
- text highlighting that the DIS plays a special role in flooding. Hence 
consider increasing the LAN priority for nodes supporting faster flooding.
- a new section on LSP pacing, inspired (read copy pasted) from RFC 9002 
section 7  (QUIC congestion control)
- some editorial changes, including replacing a couple of word/sentences by 
better equivalent from RFC 9002

Diff: 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-isis-fast-flooding-02=draft-ietf-lsr-isis-fast-flooding-03=--html

And we asked for a small slot for next LSR meeting.

Thanks,
--Bruno, on behalf of all authors.


Orange Restricted

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: Monday, March 13, 2023 7:07 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-isis-fast-flooding-03.txt


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

   Title   : IS-IS Fast Flooding
   Authors : Bruno Decraene
 Les Ginsberg
 Tony Li
 Guillaume Solignac
 Marek Karasek
 Chris Bowers
 Gunter Van de Velde
 Peter Psenak
 Tony Przygienda
   Filename: draft-ietf-lsr-isis-fast-flooding-03.txt
   Pages   : 25
   Date: 2023-03-13

Abstract:
   Current Link State Protocol Data Unit (PDU) flooding rates are much
   slower than what modern networks can support.  The use of IS-IS at
   larger scale requires faster flooding rates to achieve desired
   convergence goals.  This document discusses the need for faster
   flooding, the issues around faster flooding, and some example
   approaches to achieve faster flooding.  It also defines protocol
   extensions relevant to faster flooding.

The IETF datatracker status page for this Internet-Draft is:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-isis-fast-flooding%2F=05%7C01%7Cbruno.decraene%40orange.com%7C164a13878f04472ebbe408db23edcc78%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638143276463463955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=UnzzJLID5eE8zW4k0%2FLdCFi%2F6tq6R%2BxVjou00aP5I3s%3D=0

There is also an htmlized version available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-isis-fast-flooding-03=05%7C01%7Cbruno.decraene%40orange.com%7C164a13878f04472ebbe408db23edcc78%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638143276463463955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=ql3mPOtzsWXIC35yTHrJcmsDgNL5AgOytZSrLdUVMP4%3D=0

A diff from the previous version is available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-lsr-isis-fast-flooding-03=05%7C01%7Cbruno.decraene%40orange.com%7C164a13878f04472ebbe408db23edcc78%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638143276463463955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=P0zVVAer9LP8Ch8%2F6OB%2FEeqGLyAd9WzLiNDOhbmrHg4%3D=0

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


___
Lsr mailing list
Lsr@ietf.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr=05%7C01%7Cbruno.decraene%40orange.com%7C164a13878f04472ebbe408db23edcc78%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638143276463463955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=hHzwC8o2vgdOhLKmQsS59ybQgxjI6Vi41Sab9erFiOA%3D=0

_

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 

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-fast-flooding-02.txt

[bruno.decraene]

Hi all,


This is just a refresh.

Regards,
--Bruno


Orange Restricted

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, January 10, 2023 4:18 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-isis-fast-flooding-02.txt


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   : IS-IS Fast Flooding
Authors : Bruno Decraene
  Les Ginsberg
  Tony Li
  Guillaume Solignac
  Marek Karasek
  Chris Bowers
  Gunter Van de Velde
  Peter Psenak
  Tony Przygienda
  Filename: draft-ietf-lsr-isis-fast-flooding-02.txt
  Pages   : 24
  Date: 2023-01-10

Abstract:
   Current Link State Protocol Data Unit (PDU) flooding rates are much
   slower than what modern networks can support.  The use of IS-IS at
   larger scale requires faster flooding rates to achieve desired
   convergence goals.  This document discusses the need for faster
   flooding, the issues around faster flooding, and some example
   approaches to achieve faster flooding.  It also defines protocol
   extensions relevant to faster flooding.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-02

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-fast-flooding-02


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

_

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

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

[bruno.decraene]

I support progression of this document. It clarifies RFC8919 and as such 
improves interoperability.
(I've already reviewed and commented on the doc)

Thanks,
Regards,
--Bruno


Orange Restricted

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: Wednesday, December 7, 2022 2:20 PM
To: lsr@ietf.org
Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org; 
draft-ietf-lsr-rfc8919...@ietf.org
Subject: [Lsr] WG Last Call for draft-ietf-lsr-rfc8919bis-00


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.

_

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

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

[bruno.decraene]

Hi Tony,

> Comments or questions?

Thanks for the update
Just looking at the diff, 2 comments


  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:
-  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.
- 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?)

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?




Thanks
Regards,
--Bruno




Orange Restricted
From: Lsr  On Behalf Of Tony Li
Sent: Wednesday, November 30, 2022 7:52 PM
To: lsr 
Subject: [Lsr] Fwd: New Version Notification for 
draft-pkaneria-lsr-multi-tlv-02.txt


Hi all,

This is an update on the multi-part TLV draft.

This irons out the nits in the previous version and removes the capability 
advertisement.

Comments or questions?

Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-pkaneria-lsr-multi-tlv-02.txt
Date: November 30, 2022 at 10:49:51 AM PST
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-02.txt
has been successfully submitted by Tony Li and posted to the
IETF repository.

Name:  draft-pkaneria-lsr-multi-tlv
Revision: 02
Title: Multi-part TLVs in IS-IS
Document date:  2022-11-30
Group: Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-02.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-02

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



_

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 

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

[bruno.decraene]

Peter,

> From: Peter Psenak  
> Sent: Wednesday, November 9, 2022 2:13 PM
> 
> On 09/11/2022 14:56, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
> >> 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.
> > 
> > The problem is that a prefix with metric > 0xfe00 isn't actually an
> > unreachable prefix, it's a prefix that doesn't have specific routing
> > information associated with it, which in turn allows sticking other data
> > into it that might be routing-related but not quite a reachability.
> 
> well, that is your interpretation. For me a prefix with metric > 
> 0xfe00 is unreachable. Implementations use the max-metric today to 
> signal the prefix unreachability - to avoid reaching 
> local/leaked/redistributed prefixes in cases where OL-bit is set on the 
> originator. So we are not doing anything new here really.

I'm a bit surprised since even draft-ppsenak-lsr-igp-ureach-prefix-announce 
seems to say the contrary:

Old nodes:
" Existing nodes in a network which receive UPA advertisements will
   ignore them."

New nodes:
"As per the definitions referenced in the preceding section, any
   prefix advertisement with a metric value greater than 0xFE00 can
   be used for purposes other than normal routing calculations.  Such an
   advertisement can be interpreted by the receiver as a UPA."

https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-01#section-2.1

So draft seems to clearly state that the UPA is a new interpretation leading to 
a new behavior.

To me, the difference of opinions expressed on the list is the following:
a) draft-ppsenak-lsr-igp-ureach-prefix-announce is fine with the specific 
metric value being locally interpreted as UPA even though that's not a 
standard/global behavior
b) multiple other persons on the list have preference for an explicit signaling 
with a standardized meaning being "UPA"

I agree that "a" can be made to work, with a local interpretation through local 
config or new code.
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 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
> > 

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

[bruno.decraene]

> 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

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

[bruno.decraene]

Les, all

Please see inline 

> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Friday, October 7, 2022 1:35 AM

A bit late in the game. At least I've read all subsequent emails.

> To: Christian Hopps 
> Cc: Peter Psenak (ppsenak) ; Tony Li ; 
> Robert Raszuk ; Henk Smit ; 
> lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for 
> draft-pkaneria-lsr-multi-tlv-01.txt
> 
> Chris -
> 
> Not sure what SE means but...one more significant point.
> 
> Multiple implementations have successfully deployed MP-TLV without any 
> protocol extensions. We did not require a new sub-TLV, a new flag, a sequence 
> number...we simply send additional information encoded according to existing 
> standards. This isn't "luck" - it is following existing standards.
> 
> For implementations which do not process MP-TLVs correctly - why does this 
> happen?
> On the receive side, they do not have the intelligence in their 
> implementation to do a merge.
> On the transmit side they do not have the intelligence to generate multiple 
> TLVs.

- That protocol does not disallow the sending of multi-part (sub)-TLVs is one 
(good) thing.
- The encoding of MP-TLVs is another thing. (encoding detail IMHO, although I 
understand and agree that this is not one for existing implementations)
- Another aspect is the behavior expected on the receiving side. If that 
behavior is not specified, that's out of spec/standard in the general case, 
especially as in this case different spec specified different behaviors.

The following example (for sub-TLVs) show that there is at least two behaviors: 
"undefined", "merge"

"Where a receiving system has two copies of a capabilities TLV from
   the same system that have different settings for a given attribute,
   the procedure used to choose which copy shall be used is undefined."
https://datatracker.ietf.org/doc/html/rfc4971#section-3

"undefined" is different from "merge".
(Also note the terms "to choose which copy shall be used" could even be seen as 
excluding the possibility for a merge, at least in the mind of the authors)

Then FlexAlgo defined "merge"  for its FAD with the spec for it

"In such cases, the
   FAD MAY be split into multiple such sub-TLVs and the content of the
   multiple FAD sub-TLVs combined to provide a complete FAD for the
   Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
   Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
   Algorithm from a given IS."

And also raised the question for sub-sub-TLVs, explicitly allowing for any 
behavior 

"   Any specification that introduces a new IS-IS FAD sub-sub-TLV MUST
   specify whether the FAD sub-TLV may appear multiple times in the set
   of FAD sub-TLVs for a given Flex-Algorithm from a given IS and how to
   handle them if multiple are allowed."

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-25#section-6

Bottom lines:
- if the spec does not define the MP-TLV behavior on the receiving side by the 
spec, then -unless this is obvious and everyone agrees- this is out of spec. 
Let's not blame the receiver.
- I think we should distinguish the different aspects: allowed on the sending 
side, the encoding, the behavior on the receiving side, the need to signal the 
MP capability or not, the reaction to this signal (which can simply be an alarm 
message in log, with no IS-IS actions). I suspect that different persons have 
different sensibilities on each of those points and a sensibility with one does 
not equal to a sensibility with all. (let's not make any disagreement bigger 
than it is)

Thanks,
--Bruno


> You can propose protocol extensions (such as you have done) - but it will not 
> change the need for implementations to enhance their receive/generation logic 
> - and it will not make it any easier for implementations to do so. What it 
> will do is to introduce(sic) an interoperability problem because you will be 
> requiring implementations to understand some new advertisement in order to 
> send/receive MP-TLVs successfully. This is what Peter's point is about i.e., 
> we MUST NOT break existing working MP-TLV implementations by requiring 
> protocol extensions in order to send MP-TLVs.
> 
> As regards deployment controls, I have no problem with recommending that 
> implementations provide ways to control the enablement of the sending of 
> MP-TLVs. 
> 
   > Les
> 
> > -Original Message-
> > From: Christian Hopps 
> > Sent: Thursday, October 6, 2022 3:28 PM
> > To: Les Ginsberg (ginsberg) 
> > Cc: Christian Hopps ; Peter Psenak (ppsenak)
> > ; Tony Li ; Robert Raszuk
> > ; Henk Smit ; lsr@ietf.org
> > Subject: Re: [Lsr] New Version Notification for 
> > draft-pkaneria-lsr-multi-tlv-
> > 01.txt
> > 
> > 
> > It sounds like you're talking about networks defined to work by SE not by
> > standards. I don't want to argue about this, so perhaps we can agree to
> > disagree.
> > 
> > Thanks,
> > Chris.
> > [as wg-member]
> > 
> > 
> > "Les Ginsberg 

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

[bruno.decraene]

I've not followed everything in details so I've been reluctant to comment, but 
nonetheless please find below a diverse set of comments.


> From: Christian Hopps mailto:cho...@chopps.org>>
[...]

> AFAICT we now have implementations out there that are sending multiple TLVs 
> which are not documented to be sent that way, that historically were not 
> expected to be received that way, and then we have other implementations that 
> do not expect this new, convenient but rather loose interpretation of the 
> standards. Consider we have documents that explicitly state that a TLV can be 
> sent multiple times, it would be completely normal for someone to then assume 
> that when that isn't stated explicitly that multiple versions of those TLV 
> will not be sent.



> Thus the need for this document -- in some form.

Thank you Chris.
Definitely +1

To clarify, are we talking about:
- different nodes in the flooding domain having a different understanding of 
the LSDB content
- a (LS) protocol relying on all nodes in the flooding domain to have a 
consistent (view of the) LSDB (especially with FlexAlgo for which the number of 
(sub)TLV requiring a consistent view across the flooding domain has increased 
and may further increase)


And a standardization group defining specifications to allow for interop?

Sure, I'd be interested in an implementation report to at least learn about 
such (sub) TLV and those implementations.

[...]

> From: Lsr lsr-boun...@ietf.org On Behalf Of Les 
> Ginsberg (ginsberg)


> [LES:] This isn't a new problem for operators. There are many examples of 
> extensions to the protocol which have been introduced which result in a 
> broken network in cases of partial deployment. To list just a few:

>

>  - Wide metrics

> - Cryptographic authentication

> - Support for extended LSP lifetime (> 1200 seconds)



> The consequences of sending MP-TLVs when not all routers support them are no 
> more severe than the consequences of partial support for any of the above 
> features.

Agreed.
However, it's not because this is not a new problem that this is not a problem. 
We don't need to increase the problems and make things worse.
And it's not because this can be made to work (with extra work), that this 
can't also fails. (and this does fail sometimes)


[...]

> From: Lsr lsr-boun...@ietf.org On Behalf Of Les 
> Ginsberg (ginsberg)
[...]
> Using the protocol to send what is best described as some subset of a PICS 
> means that we propose to use the IGP flooding mechanism to send static 
> information which the protocol itself cannot (and should not) use in its 
> operation.

I'm not sure that I agree with "cannot (and should not) use in its operation".
If the correct understanding of MP TLV is required for correct operation, such 
information can be used by IS-IS to warn the network operator that IS-IS is not 
correctly working anymore. As of today, an operator may not be even aware of 
the problem.
And a so-called "smart" implementation could even forbid a configuration change 
which would translate into sending a MP TLV not understood by all nodes.


So on my side, I would rather welcome a continued discussion on this topic 
which seems important for network operations.

Thank you,
Regards,
--Bruno



Orange Restricted
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, October 4, 2022 7:35 PM
To: Tony Li 
Cc: Christian Hopps ; Robert Raszuk ; 
Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt

Tony -

We don't agree - but that isn't news.
Let me try to start a meaningful discussion.

Using the protocol to send what is best described as some subset of a PICS 
means that we propose to use the IGP flooding mechanism to send static 
information which the protocol itself cannot (and should not) use in its 
operation. This consumes space, bandwidth, gets periodically refreshed 
unnecessarily, and now a complete copy of the information from every node 
resides on every router in the network when it is only needed by an "NMS". It 
would be hard to come up with a better example of "IGP isn't a dump truck" than 
this.

If there is a belief that we can severely limit the amount of information that 
is sent/node, I'd have to say that I am skeptical. Once we allow this into the 
protocol, I don't see any basis on which to separate what is allowed and what 
is disallowed. It would not be unreasonable for an operator to say that 
everything that is a candidate to be mentioned in a PICS is a legitimate 
candidate for being advertised using this mechanism. Which means the amount of 
information is likely to become very large - especially once it becomes the de 
facto way of providing protocol management information.

The justification seems to be that we don't have anything better - which 
represents a longstanding failure of the management plane. While I agree with 
you that 

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

[bruno.decraene]

Hi chairs, all,

I strongly support WG adoption: the goal of this bis doc is clarification of an 
existing RFC in order to ensure (well, at least help) that we have 
interoperable implementations.
- Clarity and interoperability is a clear goal in general, but especially in 
the context of FlexAlgo where this is used to compute the distributed SPF.
- While we could always argue whether a clarification is needed or not, we have 
found different interpretation in different implementations so to me this is a 
proof that the previous text could be interpreted differently and hence need 
clarification. 

I've already reviewed the document, commented on it, and the authors have 
already updated the document.

I would like to thank the authors for their willingness to do this maintenance 
work. As such, I would support making their effort easier (discussion and 
review focused on this maintenance work)

Thanks,
--Bruno

Orange Restricted

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: Monday, August 8, 2022 12: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.

_

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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-fast-flooding-01.txt

[bruno.decraene]

Hi all,

Two technical changes:
- reflecting the IANA allocated code point.
- addition of a sub-TLV to specifically advertise the Receive Window of the 
flow control algo (aka RWIN). Previously, the "LSP Burst Window" was used, but 
the latter is more like a QoS/data plane buffer information so not a very good 
fit.

Regards,
--Bruno


Orange Restricted

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: Monday, July 11, 2022 6:44 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-isis-fast-flooding-01.txt


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   : IS-IS Fast Flooding
Authors : Bruno Decraene
  Les Ginsberg
  Tony Li
  Guillaume Solignac
  Marek Karasek
  Chris Bowers
  Gunter Van de Velde
  Peter Psenak
  Tony Przygienda
  Filename: draft-ietf-lsr-isis-fast-flooding-01.txt
  Pages   : 24
  Date: 2022-07-11

Abstract:
   Current Link State Protocol Data Unit (PDU) flooding rates are much
   slower than what modern networks can support.  The use of IS-IS at
   larger scale requires faster flooding rates to achieve desired
   convergence goals.  This document discusses the need for faster
   flooding, the issues around faster flooding, and some example
   approaches to achieve faster flooding.  It also defines protocol
   extensions relevant to faster flooding.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-lsr-isis-fast-flooding-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-fast-flooding-01


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

_

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

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

[bruno.decraene]

Hi Tony,

Thanks the update.
1 clarification question on §5 (new capability)

« If all routers in an area advertise the Multi-part TLV Capability a node MAY 
advertise multi-part TLVs "



Does this mean that if one router does not advertise the capability, routers 
MUST NOT advertise multi-part TLVs? (and if necessary readvertises LSPs which 
contained such multi-part TLV)

If so, I would favor adding this explicitly.

Regards,
--Bruno



Orange Restricted
From: Lsr  On Behalf Of Tony Li
Sent: Tuesday, July 5, 2022 3:09 AM
To: lsr 
Subject: [Lsr] Fwd: New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt


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



_

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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[bruno.decraene]

Hi Peter,

Thanks for your reply. Please see inline [Bruno2]



Orange Restricted

> -Original Message-
> From: Peter Psenak  
> Sent: Thursday, June 16, 2022 11:22 AM
> To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
> Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
> 
> Hi Bruno,
> 
> thanks for your feedback, please see inline (##PP):
> 
> On 15/06/2022 16:09, bruno.decra...@orange.com wrote:
> > Hi Peter, authors, all
> > 
> > Thanks for the draft. I find it a useful contribution to the problem space.
> > 
> > IMHO the use of MAX_PATH_METRIC is a good idea in particular since it 
> > can be made backward compatible and provides incremental benefits with 
> > incremental deployment.
> > 
> > I also have two disagreements on the current draft. Both are minor IMO, 
> > but authors may have a different opinion.
> > 
> >  1. This draft defines a new signaling from an egress ABR to all ingress
> > ABR/PE. As such, this require all these nodes to agree on this
> > signaling. So I’d call for a STD track document.
> 
> ##PP
> there is no new signalling defined in the draft. We are using what has 
> been defined in the RFC5305/RFC5308

[Bruno2] By "signaling", I did not meant "protocol extension". I meant 
"signaling of information". 
https://dictionary.cambridge.org/fr/dictionnaire/anglais/signal
Draft proposes an IGP announcement to signal something, more specifically that 
the prefix becomes unreachable
 
> 
> >  2. IMO, the behavior defined in this draft is not backward compatible
> > with the specification of MAX_PATH_METRIC in an IP prefix.
> 
> ##PP
> I see no backward compatibility issue
> > 
> > RFC5305 says:
> > 
> > If a prefix is advertised with a metric larger then MAX_PATH_METRIC
> > 
> > (0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
> > 
> > during the normal SPF computation.This allows advertisement of a
> > 
> > prefix for purposes other than building the normal IP routing table.
> > 
> > As per the above, one (ABR) may (is allowed and free to do so) already 
> > advertise both an aggregate prefix IP1/N with a regular metric and a 
> > more specific prefix IP2/32 with MAX_PATH_METRIC.
> > 
> > With the above advertisement, all nodes compliant with RFC 5305 will 
> > install IP1/N in their FIB and not consider IP2/32 during their SPF and 
> > as a consequence not install it in their FIB.
> > 
> > In term of reachability, all nodes have IP reachability to all IP @ in 
> > IP1 including IP2.
> > 
> > If one node now implements the draft, it will remove reachability for 
> > IP2. And hence all my BGP routes using IPv2 for next-hop will be removed.
> 
> ##PP
> there is no such thing specified in the draft. What the drafts says is 
> that if the receiver is configured to do so, it can pass the UPA to the 
> applications that may be interested in it. How they act on it is outside 
> of the draft and ISIS as such.

[Bruno2] In the draft, I'm not seeing the text "if the receiver is configured 
to do so". That would be a useful change (even though not enough to me)
 
> I'm not sure where did you get the "remove reachability for IP2".

[Bruno2] From the title "Unreachable Prefix Announcement".
1) I think we'll agree that there was reachability before the announcement. 
2) the draft is about announcing that the "Prefix" becomes "Unreachable".
That seems to be "removing reachability for the prefix". I'm open to using a 
different terminology such as "Announcing the Prefix to be Unreachable" but I 
don't think that this would change the conclusion.

There is other text in the draft, such as "The functionality being described is 
called Unreachable Prefix Announcement (UPA)."

> 
> > 
> > This looks clearly like a change in behavior to me, plus one which 
> > introduce loss of reachability in an existing network.
> > 
> > 3) The solution that I would suggest is:
> > 
> > - advertise the “unreachable prefix” with metric MAX_PATH_METRIC
> > 
> > - define a new “Extended Reachability Attribute Flags” ([RFC 7794]) 
> > explicitly signaling that the reachability to this prefix has been lost:
> > 
> > Unreachable Flag (U_flag). Set if this prefix is to be considered 
> > unreachable.
> 
> ##PP
> I see no reason for the new flag. RFC5305/RFC5308 already provide a way 
> to signal unreachable prefix. That's all we need.

[Bruno2]
RFC5305/RFC5308 provides a way to advertise a prefix that "MUST NOT be 
considered during the normal SPF computation". That is different from "a way to 
signal unreachable prefix"

If you believe that all you need is RFC5305/RFC5308 I guess this means that we 
don't need draft-ppsenak-lsr-igp-ureach-prefix-announce

Thanks,
--Bruno
 
> thanks,
> Peter
> > 
> > This would allow for explicit signaling of the reachability (vs implicit 
> > currently) and would be backward compatible with existing specification 
> > and deployments.
> > 
> > Regards,
> > 
> > --Bruno
> > 
> > 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[bruno.decraene]

Daniel, inline



Orange Restricted
From: Voyer, Daniel 
Sent: Wednesday, June 15, 2022 9:43 PM
To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Bruno, inline

From: Bruno Decraene 
mailto:bruno.decra...@orange.com>>
Date: Wednesday, June 15, 2022 at 12:27 PM
To: Dan Voyer mailto:daniel.vo...@bell.ca>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: [EXT]RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Daniel,

I agree that the draft-ppsenak-lsr-igp-ureach-prefix-announce, is presented as 
"a use case"/informational.

My point is that IMO the draft changes the behavior defined in RFC5305/RFC5308.
Indeed, as per those two RFC, I'm allowed, today, to advertise a prefix with 
MAX_PATH_METRIC for a purposes other than building the normal IP routing table..
-a) As per RFC5305/RFC5308, my reading is that such advertisement does not 
change the reachability of this prefix. IOW it's reachable if there is an 
aggregate prefix.
-b) draft-ppsenak-lsr-igp-ureach-prefix-announce would change that and hence 
would change existing behavior in my network. i.e. the existing prefixes 
advertised with MAX_PATH_METRIC would become unreachable, breaking existing 
services.

[DV] but if MAX_PATH_METRIC gets triggered, it means an existing service got 
broken or else MAX_PATH_METRIC doesn't get triggered.

[Bruno] Agreed in the context of your draft. I disagree in the general case as 
RFC5305/08 allows the use if MAX_PATH_METRIC even if the PE is up and fully 
functional.

The trigger could that that a PE is going on maintenance or .. just crashed - 
nonetheless that PE vanished and with summarization other PEs from other area 
won't get notified resulting in "breaking" service if MAX_PATH_METRIC is not 
triggered - "in this proposal". We are just reusing an existing idea.

I don't see the big deal of defining a new flag for advertising this 
unreachability: the use case defined in 
draft-ppsenak-lsr-igp-ureach-prefix-announce requires a new implementation on 
all (ingress) PEs and ABRs. Given this, what's the cost having those new 
implementation also advertising a sub-TLV/flag?

[DV] it only requires support for RFC5305/RFC5308 - hence why I am asking 
what's missing in those 2 RFC ? Basically, if I ignore 
"draft-ppsenak-lsr-igp-ureach-prefix-announce" since it's only informational, 
and wanted to do these RFCs - what's missing ?


[Bruno] There is nothing wrong with RFC5305/08.
To make it clear: on the receiver side, 
draft-ppsenak-lsr-igp-ureach-prefix-announce is not backward compatible with 
all/existing usages of MAX_PATH_METRIC as defined/allowed by RFC5305. E.g. the 
one I described in my original email.
Please review my above text and in particular the two cases "a" and "b" 
highlighted in yellow: For the same IGP advertisement from the egress (ABR) the 
behavior are different and even opposite: reachability UP for "a)"/RFC5305; 
reachability DOWN for "b)"/ draft-ppsenak-lsr-igp-ureach-prefix-announce. If 
you disagree with this reasoning, please explain why.
If you, as a network operator, wants to implement this non interoperable 
behavior in your network IGP, you are free to do so.
If an implementation that is deployed in a network that I care, implements this 
non interoperable behavior by default, and hence deliberately decide to break 
the existing behavior, for sure I'll complain to this vendor. Especially since 
the solution could easily be fixed at no cost.

Thanks,
Cheers,
--Bruno


Orange Restricted
From: Voyer, Daniel mailto:daniel.vo...@bell.ca>>
Sent: Wednesday, June 15, 2022 6:06 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>; 
lsr@ietf.org
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Bruno,

Thanks for your comment on the draft. I too, have a minor disagreement on your 
disagreement.

The draft-ppsenak-lsr-igp-ureach-prefix-announce, is really presented as "a use 
case"/informational. In this case, a PE being hidden from other area due to 
route summarization. The draft is not meant to "invent" something new, hence 
the reference to RFC5305/RFC5308.

If you jump to RFC5308 (as we are looking at IPv6 here), the advertising 
mechanism is well describe. What's missing from RFC5308 from your view point ?

Thanks
Dan

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Bruno Decraene mailto:bruno.decra...@orange.com>>
Date: Wednesday, June 15, 2022 at 10:09 AM
To: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: [EXT][Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Peter, authors, all

Thanks for the draft. I find it a useful contribution to the problem space.

IMHO the use of MAX_PATH_METRIC is a good idea in particular since it can be 
made backward compatible and provides incremental benefits with incremental 
deployment.

I also have two disagreements on the current draft. Both are minor IMO, but 
authors may have a 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[bruno.decraene]

Hi Aijun,



Orange Restricted
From: Aijun Wang 
Sent: Thursday, June 16, 2022 1:59 AM
To: DECRAENE Bruno INNOV/NET 
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi, Bruno:

I agree with your thoughts on the solutions to this questions.

Actually, this is the reason that we brought up the thread “Convergence of 
Prefixes Unreachable Announcement Proposal” and I think you can review the 
discussion of this thread again.

And, in the mail 
https://mailarchive.ietf.org/arch/msg/lsr/qZ87Kjc9RdSsNpXzpOu31g1dSR0/, we have 
the following statements:
“ Anyway, to make the UPA mechanism take effect, you will also require the 
router be upgraded. And the “Max-Value” solution doesn’t necessarily indicate 
the prefix is lost. We should announce such information explicitly.”


[Bruno] Yes we seem to be in agreement on this point.

Whether defining a new flag or use the prefix originator information(as adopt 
by  
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09#section-4)
  to indicate explicitly the prefix is unreachable can be further discussed.

[Bruno] I agree that the encoding for the explicit signaling is totally open to 
discussion.
I proposed a flag since:
- all we need is a binary information
- given the use case, this RFC7794 sub-tlv (type 4) seems likely to be already 
present. (e.g. X or R flag, possibly N-flag)

Thanks for your email and your contribution to this topic.
Best regards,
--Bruno

Aijun Wang
China Telecom


On Jun 15, 2022, at 22:09, 
bruno.decra...@orange.com wrote:

Hi Peter, authors, all

Thanks for the draft. I find it a useful contribution to the problem space.

IMHO the use of MAX_PATH_METRIC is a good idea in particular since it can be 
made backward compatible and provides incremental benefits with incremental 
deployment.

I also have two disagreements on the current draft. Both are minor IMO, but 
authors may have a different opinion.


1)  This draft defines a new signaling from an egress ABR to all ingress 
ABR/PE. As such, this require all these nodes to agree on this signaling. So 
I’d call for a STD track document.

2)  IMO, the behavior defined in this draft is not backward compatible with 
the specification of MAX_PATH_METRIC in an IP prefix.

RFC5305 says:
   If a prefix is advertised with a metric larger then MAX_PATH_METRIC
   (0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
   during the normal SPF computation.  This allows advertisement of a
   prefix for purposes other than building the normal IP routing table.

As per the above, one (ABR) may (is allowed and free to do so) already 
advertise both an aggregate prefix IP1/N with a regular metric and a more 
specific prefix IP2/32 with MAX_PATH_METRIC.
With the above advertisement, all nodes compliant with RFC 5305 will install 
IP1/N in their FIB and not consider IP2/32 during their SPF and as a 
consequence not install it in their FIB.
In term of reachability, all nodes have IP reachability to all IP @ in IP1 
including IP2.

If one node now implements the draft, it will remove reachability for IP2. And 
hence all my BGP routes using IPv2 for next-hop will be removed.
This looks clearly like a change in behavior to me, plus one which introduce 
loss of reachability in an existing network.

3) The solution that I would suggest is:
- advertise the “unreachable prefix” with metric MAX_PATH_METRIC
- define a new  “Extended Reachability Attribute Flags” ([RFC 7794]) explicitly 
signaling that the reachability to this prefix has been lost:

Unreachable Flag (U_flag). Set if this prefix is to be considered 
unreachable.

This would allow for explicit signaling of the reachability (vs implicit 
currently) and would be backward compatible with existing specification and 
deployments.

Regards,
--Bruno


_



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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[bruno.decraene]

Hi Daniel,

I agree that the draft-ppsenak-lsr-igp-ureach-prefix-announce, is presented as 
"a use case"/informational.

My point is that IMO the draft changes the behavior defined in RFC5305/RFC5308.
Indeed, as per those two RFC, I'm allowed, today, to advertise a prefix with 
MAX_PATH_METRIC for a purposes other than building the normal IP routing table..
- As per RFC5305/RFC5308, my reading is that such advertisement does not change 
the reachability of this prefix. IOW it's reachable if there is an aggregate 
prefix.
- draft-ppsenak-lsr-igp-ureach-prefix-announce would change that and hence 
would change existing behavior in my network. i.e. the existing prefixes 
advertised with MAX_PATH_METRIC would become unreachable, breaking existing 
services.

I don't see the big deal of defining a new flag for advertising this 
unreachability: the use case defined in 
draft-ppsenak-lsr-igp-ureach-prefix-announce requires a new implementation on 
all (ingress) PEs and ABRs. Given this, what's the cost having those new 
implementation also advertising a sub-TLV/flag?

Thanks,
Cheers,
--Bruno


Orange Restricted
From: Voyer, Daniel 
Sent: Wednesday, June 15, 2022 6:06 PM
To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Bruno,

Thanks for your comment on the draft. I too, have a minor disagreement on your 
disagreement.

The draft-ppsenak-lsr-igp-ureach-prefix-announce, is really presented as "a use 
case"/informational. In this case, a PE being hidden from other area due to 
route summarization. The draft is not meant to "invent" something new, hence 
the reference to RFC5305/RFC5308.

If you jump to RFC5308 (as we are looking at IPv6 here), the advertising 
mechanism is well describe. What's missing from RFC5308 from your view point ?

Thanks
Dan

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Bruno Decraene mailto:bruno.decra...@orange.com>>
Date: Wednesday, June 15, 2022 at 10:09 AM
To: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: [EXT][Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Peter, authors, all

Thanks for the draft. I find it a useful contribution to the problem space.

IMHO the use of MAX_PATH_METRIC is a good idea in particular since it can be 
made backward compatible and provides incremental benefits with incremental 
deployment.

I also have two disagreements on the current draft. Both are minor IMO, but 
authors may have a different opinion.


1)This draft defines a new signaling from an egress ABR to all ingress 
ABR/PE. As such, this require all these nodes to agree on this signaling. So 
I'd call for a STD track document.

2)IMO, the behavior defined in this draft is not backward compatible with 
the specification of MAX_PATH_METRIC in an IP prefix.

RFC5305 says:
   If a prefix is advertised with a metric larger then MAX_PATH_METRIC
   (0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
   during the normal SPF computation.  This allows advertisement of a
   prefix for purposes other than building the normal IP routing table.

As per the above, one (ABR) may (is allowed and free to do so) already 
advertise both an aggregate prefix IP1/N with a regular metric and a more 
specific prefix IP2/32 with MAX_PATH_METRIC.
With the above advertisement, all nodes compliant with RFC 5305 will install 
IP1/N in their FIB and not consider IP2/32 during their SPF and as a 
consequence not install it in their FIB.
In term of reachability, all nodes have IP reachability to all IP @ in IP1 
including IP2.

If one node now implements the draft, it will remove reachability for IP2. And 
hence all my BGP routes using IPv2 for next-hop will be removed.
This looks clearly like a change in behavior to me, plus one which introduce 
loss of reachability in an existing network.

3) The solution that I would suggest is:
- advertise the "unreachable prefix" with metric MAX_PATH_METRIC
- define a new  "Extended Reachability Attribute Flags" ([RFC 7794]) explicitly 
signaling that the reachability to this prefix has been lost:

Unreachable Flag (U_flag). Set if this prefix is to be considered 
unreachable.

This would allow for explicit signaling of the reachability (vs implicit 
currently) and would be backward compatible with existing specification and 
deployments.

Regards,
--Bruno


_



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 

[Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[bruno.decraene]

Hi Peter, authors, all

Thanks for the draft. I find it a useful contribution to the problem space.

IMHO the use of MAX_PATH_METRIC is a good idea in particular since it can be 
made backward compatible and provides incremental benefits with incremental 
deployment.

I also have two disagreements on the current draft. Both are minor IMO, but 
authors may have a different opinion.


  1.  This draft defines a new signaling from an egress ABR to all ingress 
ABR/PE. As such, this require all these nodes to agree on this signaling. So 
I'd call for a STD track document.
  2.  IMO, the behavior defined in this draft is not backward compatible with 
the specification of MAX_PATH_METRIC in an IP prefix.

RFC5305 says:
   If a prefix is advertised with a metric larger then MAX_PATH_METRIC
   (0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
   during the normal SPF computation.  This allows advertisement of a
   prefix for purposes other than building the normal IP routing table.

As per the above, one (ABR) may (is allowed and free to do so) already 
advertise both an aggregate prefix IP1/N with a regular metric and a more 
specific prefix IP2/32 with MAX_PATH_METRIC.
With the above advertisement, all nodes compliant with RFC 5305 will install 
IP1/N in their FIB and not consider IP2/32 during their SPF and as a 
consequence not install it in their FIB.
In term of reachability, all nodes have IP reachability to all IP @ in IP1 
including IP2.

If one node now implements the draft, it will remove reachability for IP2. And 
hence all my BGP routes using IPv2 for next-hop will be removed.
This looks clearly like a change in behavior to me, plus one which introduce 
loss of reachability in an existing network.

3) The solution that I would suggest is:
- advertise the "unreachable prefix" with metric MAX_PATH_METRIC
- define a new  "Extended Reachability Attribute Flags" ([RFC 7794]) explicitly 
signaling that the reachability to this prefix has been lost:

Unreachable Flag (U_flag). Set if this prefix is to be considered 
unreachable.

This would allow for explicit signaling of the reachability (vs implicit 
currently) and would be backward compatible with existing specification and 
deployments.

Regards,
--Bruno


_

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

Re: [Lsr] [Technical Errata Reported] RFC8919 (6630)

[bruno.decraene]

Hi Les, John, all,

Could we have an update on this?

> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> John Scudder
[…]
> I think the changes could be processed either as a bis or as a so-called 
> “patch” draft, i.e. one that looks substantially similar to the errata you 
> submitted (a bunch of OLD: and NEW: blocks, for example) that Updates: RFC 
> 8919.
[…]
> Do let me know if we agree in principle on this as a way forward; if so I’ll 
> close the errata.

!! Hopefully, I’m not changing the meaning of John’s email with my above edit. 
Please correct me as needed.


  1.  Since the errata has been closed, I’m assuming that there is an agreement 
to proceed with a new draft. Is this correct?
  2.  Can we have a confirmation that the new draft is on its way? Possibly 
with an ETA?

We do faced multiple interop issues with this ASLA document, and from 
preliminary recent feedback this may not be over. So IMO the spec do need to be 
clarified.

Thanks,
--Bruno




Orange Restricted
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, May 11, 2022 8:47 PM
To: John Scudder 
Cc: Acee Lindem (acee) ; Peter Psenak (ppsenak) 
; stef...@previdi.net; wim.henderi...@nokia.com; John E 
Drake ; aretana.i...@gmail.com; martin.vigour...@nokia.com; 
cho...@chopps.org; lsr@ietf.org
Subject: Re: [Lsr] [Technical Errata Reported] RFC8919 (6630)

John –

Don’t know if you have completed your review of the mailing list archives on 
this subject.

Given it is almost a year since the discussion, I had to review it myself. 
Here are some pointers:

The discussion started with an email from Bruno asking for some clarification:
https://mailarchive.ietf.org/arch/msg/lsr/DrehmMy9Ru7CNPTfAMmyCofXjTY/


This led to proposed Errata for RFC 8919/8920 – the discussion of which can be 
found here:

https://mailarchive.ietf.org/arch/browse/lsr/?gbt=1=%22Proposed%20Errata%20for%20RFCs%208919%2F8920%22

Given the protracted discussions on the drafts which became RFC 8919/8920, I am 
not eager to do a BIS draft simply to insert a clarification.

I do think the discussion of the Errata on the list could be considered as 
achieving consensus.
There are then two options:

1)Use the errata to document the clarifications

2)Use a “patch RFC”

I have never done a “patch RFC” – wasn’t even aware this option existed.  And I 
am not clear on how it is done procedurally – is this simply a new draft but 
everyone agrees to limit discussion given the “patch format”?

Frankly, I don’t see the difference between the Errata and the “patch RFC”- 
other than the latter is more work.
Certainly content-wise they are the same.
So your comment that Errata are only meant to address “bugs” doesn’t make it 
clear why a “patch RFC” is OK but an Errata that has the same textual changes 
is not.

I would prefer to use the Errata if possible.

Your thoughts?

Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of John 
Scudder
Sent: Tuesday, May 10, 2022 11:16 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; Peter Psenak 
(ppsenak) mailto:ppse...@cisco.com>>; 
stef...@previdi.net; 
wim.henderi...@nokia.com; John E Drake 
mailto:jdr...@juniper.net>>; 
aretana.i...@gmail.com; 
martin.vigour...@nokia.com; 
cho...@chopps.org; lsr@ietf.org
Subject: Re: [Lsr] [Technical Errata Reported] RFC8919 (6630)

Hi Les,

Yes that’s about right, except I think the changes could be processed either as 
a bis or as a so-called “patch” draft, i.e. one that looks substantially 
similar to the errata you submitted (a bunch of OLD: and NEW: blocks, for 
example) that Updates: RFC 8919.

The IESG has in the past discussed whether and how to avoid problems such as 
you describe, but so far to no effect. Because of such concerns — that even a 
closely-focused bis may be treated as open season for review comments unrelated 
to the substance of the actual changes — it’s pretty common practice for 
authors to use patch RFCs instead. IMO these are ugly to have floating around 
our document set, but our process creates a strong incentive to use them. As 
such, if you wanted to follow that approach I wouldn’t be against it, on the 
other hand if you view the bis as “the right thing” and you want to DTRT, I’d 
do what I can to encourage the IESG to keep their comments focused and not 
treat it as open season.

Hope that helps. Do let me know if we agree in principle on this as a way 
forward; if so I’ll close the errata.

Thanks,

—John

On May 10, 2022, at 1:08 PM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:


John –

If I interpret the essence of your comments correctly, you are expressing a 
preference that the proposed changes be handled via a BIS draft rather than an 
errata.

I don’t have an objection to that – and in some 

Re: [Lsr] BGP vs PUA/PULSE

[bruno.decraene]

Peter,

> From: Peter Psenak 
> Sent: Thursday, January 6, 2022 11:03 AM
> 
> Bruno,
> 
> On 06/01/2022 10:40, bruno.decra...@orange.com wrote:
> > Peter,
> >
> > Thanks for your answer.
> > Please see inline [Bruno]
> >
> >
> >> From: Peter Psenak 
> >> Sent: Thursday, January 6, 2022 10:25 AM
> >>
> >> Bruno,
> >>
> >> the PIC is used unchanged with PULSE.
> >
> > [Bruno] OK. Therefore, from a FIB standpoint, does this mean that the 
> > scaling
> properties are also unchanged compared to loopback leaking (no aggregation on
> ABR)?
> 
> that is correct.

OK. Clear. Thanks.
IMHO that point has been missing in some of the threads. (not from you)

 
> > In which case, compared to leaking loopbacks, the key/only benefit of ABR
> summarization + PULSE is the reduction of the number of (IS-IS) LSP being
> flooded (before failure, and after failure if multiple PE fails at the same 
> time)?
> 
> it's the reduction of number of prefixes that would need to be
> advertised by IGP and installed in foowarding of all routers.

In sync with the benefits on the IGP signaling part.
For the forwarding part:
- I agree for pure MPLS LSR/P routers not installing BGP routes
- But for PE/ingress nodes and IP transit routers installing BGP routes, since 
nothing change in the FIB, I would assume that this provides no reduction on 
the number of prefix installed in the FIB (well, at least when BGP PIC edge is 
used).

Thanks,
--Bruno 

> thanks,
> Peter
> 
> 
> >
> > If so this seem to partially contradict the below statement from Gyan as we 
> > only
> get partial advantage of the summarization.
> >
> >>> *From:*Lsr  *On Behalf Of *Gyan Mishra
> >>> *Sent:* Thursday, January 6, 2022 12:27 AM
> > [...]
> >>> With the PUA/Pulse feature allows the domain wide flooding of the
> >>> loopback host routes is now possible as can now we take advantage and of
> >>> summarization.
> >
> >> The only difference is that the PIC is triggered by the pulse arrival,
> >> instead of the IGP route removal. We have made a prototype of it and it
> >> works fine.
> >
> > [Bruno] OK thanks. I believe you, I was just trying to more precisely 
> > understand
> the benefits and limits.
> >
> > --Bruno
> >
> >> thanks,
> >> Peter
> >>
> >> On 06/01/2022 09:09, bruno.decra...@orange.com wrote:
> >>> Hi Gyan,
> >>>
> >>> You are referring to both summarization and BGP PIC (edge).
> >>>
> >>> BGP PIC is quite old story, but if my memory serve me well, BGP PIC edge
> >>> relies on the presence of the specific (/32) prefix information in the
> >>> FIB. Hence it’s not clear to me how you can have both prefix
> >>> summarization and BGP PIC edge benefits in the FIB on the BGP ingress
> node.
> >>>
> >>> Taking the example from [1], below is a typical FIB chain for BGP Pic 
> >>> edge:
> >>>
> >>> IP Leaf:Pathlist:IP Leaf:Pathlist:
> >>>
> >>> +---++--+
> >>>
> >>> VPN-IP1-->|BGP-NH1|-->IGP-IP1(BGP NH1)--->|IGP-NH1,I1|--->Adjacency1
> >>>
> >>> ||BGP-NH2|-->||IGP-NH2,I2|--->Adjacency2
> >>>
> >>> |+---+|+--+
> >>>
> >>> ||
> >>>
> >>> ||
> >>>
> >>> vv
> >>>
> >>> OutLabel-List:OutLabel-List:
> >>>
> >>> +--++--+
> >>>
> >>> |VPN-L11 (VPN-IP1, NH1)||IGP-L11 (IGP-IP1, NH1)|
> >>>
> >>> |VPN-L21 (VPN-IP1, NH2)||IGP-L12 (IGP-IP1, NH2)|
> >>>
> >>> +--++--+
> >>>
> >>> Figure 2 Shared Hierarchical Forwarding Chain at iPE
> >>>
> >>> [1]
> >>> https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-bgp-pic-17#section-2.2
> >>> 
> >>>
> >>> To help me get the picture, could you please highlight/draw the
> >>> change(s) that you have in mind assuming IGP prefix summarization and
> >>> PULSE? (More specifically regarding the IGP leaf “IGP-IP1(BGP NH1)")
> >>>
> >>> Thanks,
> >>>
> >>> Regards,
> >>>
> >>> -Bruno
> >>>
> >>> Orange Restricted
> >>>
> >>> *From:*Lsr  *On Behalf Of *Gyan Mishra
> >>> *Sent:* Thursday, January 6, 2022 12:27 AM
> >>> *To:* Robert Raszuk 
> >>> *Cc:* Greg Mirsky ; Les Ginsberg (ginsberg)
> >>> ; Christian Hopps ; Aijun
> Wang
> >>> ; Shraddha Hegde ;
> Tony
> >>> Li ; Hannes Gredler ; lsr
> >>> ; Peter Psenak 
> >>> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
> >>>
> >>> Hi Robert
> >>>
> >>> The goal of the draft is providing egress protection when summarization
> >>> is used similar to RFC 8679 Egress protection framework, but without the
> >>> complexities.
> >>>
> >>> An IGP RIB within a domain is made up on connected interfaces and
> >>> loopbacks. Of the two types, the critical prefix to be tracked is the
> >>> /32 or /128 host routes on egress PE which is the BGP next-hop attribute
> >>> via next-hop-self rewrite.  So both connected and loopbacks can be
> >>> placed in the same range for large aggregation domains, however due to
> >>> the criticality of the next hop attribute the loopbacks are placed in a
> >>> separate range, and so not 

Re: [Lsr] BGP vs PUA/PULSE

[bruno.decraene]

Peter,

Thanks for your answer.
Please see inline [Bruno]


> From: Peter Psenak 
> Sent: Thursday, January 6, 2022 10:25 AM
> 
> Bruno,
> 
> the PIC is used unchanged with PULSE.

[Bruno] OK. Therefore, from a FIB standpoint, does this mean that the scaling 
properties are also unchanged compared to loopback leaking (no aggregation on 
ABR)?
In which case, compared to leaking loopbacks, the key/only benefit of ABR 
summarization + PULSE is the reduction of the number of (IS-IS) LSP being 
flooded (before failure, and after failure if multiple PE fails at the same 
time)?

If so this seem to partially contradict the below statement from Gyan as we 
only get partial advantage of the summarization.

> > *From:*Lsr  *On Behalf Of *Gyan Mishra
> > *Sent:* Thursday, January 6, 2022 12:27 AM
[...]
> > With the PUA/Pulse feature allows the domain wide flooding of the
> > loopback host routes is now possible as can now we take advantage and of
> > summarization. 

> The only difference is that the PIC is triggered by the pulse arrival,
> instead of the IGP route removal. We have made a prototype of it and it
> works fine.

[Bruno] OK thanks. I believe you, I was just trying to more precisely 
understand the benefits and limits.

--Bruno
 
> thanks,
> Peter
> 
> On 06/01/2022 09:09, bruno.decra...@orange.com wrote:
> > Hi Gyan,
> >
> > You are referring to both summarization and BGP PIC (edge).
> >
> > BGP PIC is quite old story, but if my memory serve me well, BGP PIC edge
> > relies on the presence of the specific (/32) prefix information in the
> > FIB. Hence it’s not clear to me how you can have both prefix
> > summarization and BGP PIC edge benefits in the FIB on the BGP ingress node.
> >
> > Taking the example from [1], below is a typical FIB chain for BGP Pic edge:
> >
> > IP Leaf:Pathlist:IP Leaf:Pathlist:
> >
> > +---++--+
> >
> > VPN-IP1-->|BGP-NH1|-->IGP-IP1(BGP NH1)--->|IGP-NH1,I1|--->Adjacency1
> >
> > ||BGP-NH2|-->||IGP-NH2,I2|--->Adjacency2
> >
> > |+---+|+--+
> >
> > ||
> >
> > ||
> >
> > vv
> >
> > OutLabel-List:OutLabel-List:
> >
> > +--++--+
> >
> > |VPN-L11 (VPN-IP1, NH1)||IGP-L11 (IGP-IP1, NH1)|
> >
> > |VPN-L21 (VPN-IP1, NH2)||IGP-L12 (IGP-IP1, NH2)|
> >
> > +--++--+
> >
> > Figure 2 Shared Hierarchical Forwarding Chain at iPE
> >
> > [1]
> > https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-bgp-pic-17#section-2.2
> > 
> >
> > To help me get the picture, could you please highlight/draw the
> > change(s) that you have in mind assuming IGP prefix summarization and
> > PULSE? (More specifically regarding the IGP leaf “IGP-IP1(BGP NH1)")
> >
> > Thanks,
> >
> > Regards,
> >
> > -Bruno
> >
> > Orange Restricted
> >
> > *From:*Lsr  *On Behalf Of *Gyan Mishra
> > *Sent:* Thursday, January 6, 2022 12:27 AM
> > *To:* Robert Raszuk 
> > *Cc:* Greg Mirsky ; Les Ginsberg (ginsberg)
> > ; Christian Hopps ; Aijun Wang
> > ; Shraddha Hegde ; Tony
> > Li ; Hannes Gredler ; lsr
> > ; Peter Psenak 
> > *Subject:* Re: [Lsr] BGP vs PUA/PULSE
> >
> > Hi Robert
> >
> > The goal of the draft is providing egress protection when summarization
> > is used similar to RFC 8679 Egress protection framework, but without the
> > complexities.
> >
> > An IGP RIB within a domain is made up on connected interfaces and
> > loopbacks. Of the two types, the critical prefix to be tracked is the
> > /32 or /128 host routes on egress PE which is the BGP next-hop attribute
> > via next-hop-self rewrite.  So both connected and loopbacks can be
> > placed in the same range for large aggregation domains, however due to
> > the criticality of the next hop attribute the loopbacks are placed in a
> > separate range, and so not summarized and flooded domain wide.
> >
> > The BGP next hop attribute is an MPLS exact match FEC binding for the
> > LSP.  Flooding of loopbacks workaround  is typically done for MPLS
> > domain due to issue with RFC 5283 inter area extension feature not being
> > viable solution for LPM summary matching,  thus all the prefixes still
> > have to be flooded  in LDP, so no net reduction in host route flooding.
> >
> > With the PUA/Pulse feature allows the domain wide flooding of the
> > loopback host routes is now possible as can now we take advantage and of
> > summarization.
> >
> > Even independent of MPLS in an IPv4, IPv6 or SRv6 environment the
> > tracking of BGP next-hop-attribute component prefixes is critically
> > important to improved convergence and not rely on BGP dead timers to
> > expire.  Even with BFD, LFA/RLFA/TILFA local protection , PIC and other
> > optimizations we still need an optimization to track the summary route
> > component prefixes to speed up convergence providing  egress PE protection.
> >
> > Kind Regards
> >
> > Gyan
> >
> > On Tue, Jan 4, 2022 at 6:55 PM Robert Raszuk  > 

Re: [Lsr] BGP vs PUA/PULSE

[bruno.decraene]

Hi Gyan,

You are referring to both summarization and BGP PIC (edge).
BGP PIC is quite old story, but if my memory serve me well, BGP PIC edge relies 
on the presence of the specific (/32) prefix information in the FIB. Hence it’s 
not clear to me how you can have both prefix summarization and BGP PIC edge 
benefits in the FIB on the BGP ingress node.

Taking the example from [1], below is a typical FIB chain for BGP Pic edge:

   IP Leaf:Pathlist:IP Leaf:   Pathlist:
     +---+   +--+
   VPN-IP1-->|BGP-NH1|-->IGP-IP1(BGP NH1)--->|IGP-NH1,I1|--->Adjacency1
 |   |BGP-NH2|-->  | |IGP-NH2,I2|--->Adjacency2
 |   +---+ | +--+
 | |
 | |
 v v
   OutLabel-List:OutLabel-List:
   +--+  +--+
   |VPN-L11 (VPN-IP1, NH1)|  |IGP-L11 (IGP-IP1, NH1)|
   |VPN-L21 (VPN-IP1, NH2)|  |IGP-L12 (IGP-IP1, NH2)|
   +--+  +--+

   Figure 2 Shared Hierarchical Forwarding Chain at iPE


[1] 
https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-bgp-pic-17#section-2.2

To help me get the picture, could you please highlight/draw the change(s) that 
you have in mind assuming IGP prefix summarization and PULSE? (More 
specifically regarding the IGP leaf “IGP-IP1(BGP NH1)")

Thanks,
Regards,
-Bruno



Orange Restricted
From: Lsr  On Behalf Of Gyan Mishra
Sent: Thursday, January 6, 2022 12:27 AM
To: Robert Raszuk 
Cc: Greg Mirsky ; Les Ginsberg (ginsberg) 
; Christian Hopps ; Aijun Wang 
; Shraddha Hegde ; Tony Li 
; Hannes Gredler ; lsr ; 
Peter Psenak 
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Robert

The goal of the draft is providing egress protection when summarization is used 
similar to RFC 8679 Egress protection framework, but without the complexities.

An IGP RIB within a domain is made up on connected interfaces and loopbacks. Of 
the two types, the critical prefix to be tracked is the /32 or /128 host routes 
on egress PE which is the BGP next-hop attribute via next-hop-self rewrite.  So 
both connected and loopbacks can be placed in the same range for large 
aggregation domains, however due to the criticality of the next hop attribute 
the loopbacks are placed in a separate range, and so not summarized and flooded 
domain wide.

The BGP next hop attribute is an MPLS exact match FEC binding for the LSP.  
Flooding of loopbacks workaround  is typically done for MPLS domain due to 
issue with RFC 5283 inter area extension feature not being viable solution for 
LPM summary matching,  thus all the prefixes still have to be flooded  in LDP, 
so no net reduction in host route flooding.

With the PUA/Pulse feature allows the domain wide flooding of the loopback host 
routes is now possible as can now we take advantage and of summarization.

Even independent of MPLS in an IPv4, IPv6 or SRv6 environment the tracking of 
BGP next-hop-attribute component prefixes is critically important to improved 
convergence and not rely on BGP dead timers to expire.  Even with BFD, 
LFA/RLFA/TILFA local protection , PIC and other optimizations we still need an 
optimization to track the summary route component prefixes to speed up 
convergence providing  egress PE protection.

Kind Regards

Gyan

On Tue, Jan 4, 2022 at 6:55 PM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Aijun,

In most deployments summary routes are already crafted carefully to only cover 
those destinations which are important and should be reachable from outside of 
the area.

So I see no point in building yet another policy to select a subset of 
summaries to be PUA eligible.

Along those lines I do not buy into the notion of "some prefixes within 
summaries to be more important than others" - it is simply impossible to say 
that this PE is more important than the other one in all practical cases.

If we are to roll out a mechanism to signal unreachability it better be robust 
and dependable - not just an optional hint. With that I would welcome solution 
which says - if we have more then X prefixes (or % of prefixes) to be 
advertised by ABR we stop advertising the summary covering them (or deaggregate 
the summary).

Thx,
R.






On Wed, Jan 5, 2022 at 12:06 AM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
I think the mentioned solution can also address Robert and Christian’s concerns.
Aijun Wang
China Telecom


On Jan 5, 2022, at 07:02, Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Greg:

https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-8
 has some description for such considerations:
“ In order to reduce the unnecessary advertisements of PUAM

   messages on ABRs, the ABRs should support the configuration of the

   protected prefixes.  Based on such information, the ABR will 

[Lsr] FW: IPR Disclosure Cisco Systems, Inc.'s Statement about IPR related to draft-decraeneginsberg-lsr-isis-fast-flooding

[bruno.decraene]

Orange Restricted

-Original Message-
From: IETF Secretariat  
Sent: Tuesday, November 30, 2021 4:03 PM
To: draft-decraeneginsberg-lsr-isis-fast-flood...@ietf.org
Cc: ipr-annou...@ietf.org
Subject: IPR Disclosure Cisco Systems, Inc.'s Statement about IPR related to 
draft-decraeneginsberg-lsr-isis-fast-flooding

Dear Bruno Decraene, Les Ginsberg, Tony Li, Guillaume Solignac, Marek Karasek, 
Chris Bowers, Gunter Van de Velde, Peter Psenak, Tony Przygienda:


An IPR disclosure that pertains to your Internet-Draft entitled "IS-IS Fast
Flooding" (draft-decraeneginsberg-lsr-isis-fast-flooding) was submitted to
the IETF Secretariat on 2021-11-29 and has been posted on the "IETF Page of
Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/5323/). The title of the IPR disclosure is
"Cisco Systems, Inc.'s Statement about IPR related to
draft-decraeneginsberg-lsr-isis-fast-flooding"


Thank you

IETF Secretariat


_

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

Re: [Lsr] WG Adoption Call for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

[bruno.decraene]

As co-author, I support adopting this draft as a WG document.

I'd favor the standard track:

  *   I'd argue that _flow_ control based on a signaled window is simple 
(compared to congestion control), old and well-known and not subject to 
experimentation any more. It has been deployed in much more diverse environment 
and larger scale, e.g. TCP and QUIC.
  *   Even if the _congestion_ control algorithm is not agreed upon, there is 
chance that explicitly signaling supported flooding parameters/capabilities 
yields to better behavior compared to guessing, and simpler deployment 
considerations compared to requiring configuration of those parameters. 
Eventually in the future, the WG would agree on a sub-set of standard track 
parameters (sub-TLV) carried in the TLV defined in this document. Having this 
document experimental would lead to a downref.

Thanks,
--Bruno




Orange Restricted
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Monday, November 22, 2021 3:07 PM
To: lsr@ietf.org
Subject: [Lsr] WG Adoption Call for "IS-IS Fast Flooding" - 
draft-decraeneginsberg-lsr-isis-fast-flooding-00

We indicated the intent to adopt of 
draft-decraeneginsberg-lsr-isis-fast-flooding-00 as an LSR WG document at the 
IETF 112 LSR WG meeting.
We are now confirming WG consensus on this action. Please indicate your support 
or objection on this list by 12:00 AM UTC on December 7th, 2021.

Another question that came to light is whether the document should be standards 
track or experimental. If you have an opinion on this matter, please chime in 
along with your arguments for one track or the other. We probably won't make a 
final decision on this now but let's get the discussion started.

Here is a link for your convenience:

https://datatracker.ietf.org/doc/draft-decraeneginsberg-lsr-isis-fast-flooding/

Thanks,
Acee

_

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

Re: [Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi Peter,

> From: Peter Psenak 
> Sent: Thursday, September 9, 2021 3:30 PM
> To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
> 
> Hi Bruno,
> 
> On 09/09/2021 15:27, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thanks for your answer.
> > Please see inline
> >
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Thursday, September 9, 2021 2:52 PM
> >> To: DECRAENE Bruno INNOV/NET ;
> lsr@ietf.org
> >> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
> >>
> >> Hi Bruno,
> >>
> >> On 09/09/2021 14:43, bruno.decra...@orange.com wrote:
> >>> Hi authors, all,
> >>>
> >>> I have a question related to the two-way connectivity check performed on
> each
> >> link during the FlexAlgo SPF.
> >>
> >> flex-algo is defined as set of:
> >>
> >> (a) calculation-type
> >> (b) metric-type,
> >> (c) a set of constraints
> >>
> >> Two way connectivity check for any link in the MT topology is orthogonal
> >> to flex-algo and is done once only and used for all algorithms.
> >
> > OK. Excellent.
> > Could the above be added in the specification, so that we have consistent
> behaviour across implementations?
> 
> sure, I will push it with the next revision - after the AD review.


Thanks for the update.
-18 addresses my comment.

Thank you,
--Bruno

 
> thanks,
> Peter
> 
> 
> >
> > Thanks,
> > Regards,
> > Bruno
> >>
> >> Flex-algo calculation using (a), (b), and (c) is done on top of MT
> >> topology using only links for which the 2WCC has already been performed.
> >>
> >>
> >>>
> >>> Is this point documented in the document? I could not find it so far.
> >>> If not, what is the (reverse connectivity) check that need to be 
> >>> performed on
> the
> >> reverse link?
> >>
> >>
> >> none.
> >>
> >> thanks,
> >> Peter
> >>
> >>
> >>>
> >>> A priori I could see multiple options:
> >>> a) link exist
> >>> b) link exist with a standard IGP metric  (seem the option defined in the 
> >>> ISO
> spec
> >> §7.2.8.2)
> >>> c) link exist with the FlexAlgo metric used by FlexAlgo
> >>> d) link exist with the FlexAlgo metric used by FlexAlgo and link complies 
> >>> to
> >> FlexAlgo constraints.
> >>>
> >>> I think we'll agree that this point requires uniformity across nodes hence
> >> standardization.
> >>>
> >>> Personally, I don't have significant preference, but the algo defined in 
> >>> §13
> >> "Calculation of Flexible Algorithm Paths" could be read as defining option 
> >> "d"
> (as
> >> links not following the constraints are "pruned from the computation") but 
> >> I'm
> not
> >> sure that this is intended for the two-way connectivity check.
> >>>
> >>> Thanks,
> >>> Regards,
> >>> --Bruno
> >>>
> >>>
> >>>
> >>>
> >>
> 
> >> _
> >>>
> >>> 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
> >>>
> >>>
> >
> >
> >
> __
> ___
> >
> > 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 

[Lsr] draft-decraeneginsberg-lsr-isis-fast-flooding-00

[bruno.decraene]

Dear all,

During LSR interim meeting on September 29th [0] authors of 
draft-decraene-lsr-isis-flooding-speed [1] and 
draft-ginsberg-lsr-isis-flooding-scale [2] agreed to work together and publish 
a common combined draft by October 25 [3].

New draft has been published today [4]. As presented during the interim, it's 
scope is:
- Define new TLV supporting:
-- InterfaceLSPReceiveWindow (RWIN)
-- LSP/PSNPThreshold(LPP)
-- partialSNPInterval(milliseconds)
-- Extensible to advertise other values
- TLV supported in IIHs and PSNPs

This provides tools for multiple solutions and the draft informatively 
describes two algorithm as examples.

Review and comments is more than welcome.

Thanks,
Regards,
Authors

[0] https://datatracker.ietf.org/wg/lsr/meetings/
[1] https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed
[2] https://datatracker.ietf.org/doc/html/draft-ginsberg-lsr-isis-flooding-scale
[3] 
https://datatracker.ietf.org/meeting/interim-2021-lsr-01/materials/slides-interim-2021-lsr-01-sessa-1-joint-statement-00.pdf
[4] 
https://datatracker.ietf.org/doc/html/draft-decraeneginsberg-lsr-isis-fast-flooding





Orange Restricted

-Original Message-
From: internet-dra...@ietf.org  
Sent: Friday, October 22, 2021 10:55 AM
To: DECRAENE Bruno INNOV/NET ; Chris Bowers 
; Guillaume Solignac ; Gunter Van 
de Velde ; Les Ginsberg ; 
Marek Karasek ; Peter Psenak ; Tony Li 
; Tony Przygienda 
Subject: New Version Notification for 
draft-decraeneginsberg-lsr-isis-fast-flooding-00.txt


A new version of I-D, draft-decraeneginsberg-lsr-isis-fast-flooding-00.txt
has been successfully submitted by Bruno Decraene and posted to the
IETF repository.

Name:   draft-decraeneginsberg-lsr-isis-fast-flooding
Revision:   00
Title:  IS-IS Fast Flooding
Document date:  2021-10-22
Group:  Individual Submission
Pages:  24
URL:
https://www.ietf.org/archive/id/draft-decraeneginsberg-lsr-isis-fast-flooding-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-decraeneginsberg-lsr-isis-fast-flooding/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-decraeneginsberg-lsr-isis-fast-flooding


Abstract:
   Current Link State Protocol Data Unit (PDU) flooding rates are much
   slower than what modern networks can support.  The use of IS-IS at
   larger scale requires faster flooding rates to achieve desired
   convergence goals.  This document discusses the need for faster
   flooding, the issues around faster flooding, and some example
   approaches to achieve faster flooding.  It also defines protocol
   extensions relevant to faster flooding.


  


The IETF Secretariat


_

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

Re: [Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

> From: Peter Psenak [mailto:ppse...@cisco.com]
>
> Hi Bruno,
> 
> On 09/09/2021 15:27, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thanks for your answer.
> > Please see inline
> >
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Thursday, September 9, 2021 2:52 PM
> >> To: DECRAENE Bruno INNOV/NET ;
> lsr@ietf.org
> >> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
> >>
> >> Hi Bruno,
> >>
> >> On 09/09/2021 14:43, bruno.decra...@orange.com wrote:
> >>> Hi authors, all,
> >>>
> >>> I have a question related to the two-way connectivity check performed on 
> >>> each
> >> link during the FlexAlgo SPF.
> >>
> >> flex-algo is defined as set of:
> >>
> >> (a) calculation-type
> >> (b) metric-type,
> >> (c) a set of constraints
> >>
> >> Two way connectivity check for any link in the MT topology is orthogonal
> >> to flex-algo and is done once only and used for all algorithms.
> >
> > OK. Excellent.
> > Could the above be added in the specification, so that we have consistent
> behaviour across implementations?
> 
> sure, I will push it with the next revision - after the AD review.

OK.
Thank you Peter.

--Bruno
> 
> thanks,
> Peter
> 
> 
> >
> > Thanks,
> > Regards,
> > Bruno
> >>
> >> Flex-algo calculation using (a), (b), and (c) is done on top of MT
> >> topology using only links for which the 2WCC has already been performed.
> >>
> >>
> >>>
> >>> Is this point documented in the document? I could not find it so far.
> >>> If not, what is the (reverse connectivity) check that need to be 
> >>> performed on
> the
> >> reverse link?
> >>
> >>
> >> none.
> >>
> >> thanks,
> >> Peter
> >>
> >>
> >>>
> >>> A priori I could see multiple options:
> >>> a) link exist
> >>> b) link exist with a standard IGP metric  (seem the option defined in the 
> >>> ISO
> spec
> >> §7.2.8.2)
> >>> c) link exist with the FlexAlgo metric used by FlexAlgo
> >>> d) link exist with the FlexAlgo metric used by FlexAlgo and link complies 
> >>> to
> >> FlexAlgo constraints.
> >>>
> >>> I think we'll agree that this point requires uniformity across nodes hence
> >> standardization.
> >>>
> >>> Personally, I don't have significant preference, but the algo defined in 
> >>> §13
> >> "Calculation of Flexible Algorithm Paths" could be read as defining option 
> >> "d" (as
> >> links not following the constraints are "pruned from the computation") but 
> >> I'm not
> >> sure that this is intended for the two-way connectivity check.
> >>>
> >>> Thanks,
> >>> Regards,
> >>> --Bruno
> >>>
> >>>
> >>>
> >>>
> >>
> 
> >> _
> >>>
> >>> 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
> >>>
> >>>
> >
> >
> >
> 
> _
> >
> > 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.
> >
> >
> >

Re: [Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi Peter,

Thanks for your answer.
Please see inline

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, September 9, 2021 2:52 PM
> To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
> 
> Hi Bruno,
> 
> On 09/09/2021 14:43, bruno.decra...@orange.com wrote:
> > Hi authors, all,
> >
> > I have a question related to the two-way connectivity check performed on 
> > each
> link during the FlexAlgo SPF.
> 
> flex-algo is defined as set of:
> 
> (a) calculation-type
> (b) metric-type,
> (c) a set of constraints
> 
> Two way connectivity check for any link in the MT topology is orthogonal
> to flex-algo and is done once only and used for all algorithms.

OK. Excellent.
Could the above be added in the specification, so that we have consistent 
behaviour across implementations?

Thanks,
Regards,
Bruno
> 
> Flex-algo calculation using (a), (b), and (c) is done on top of MT
> topology using only links for which the 2WCC has already been performed.
> 
> 
> >
> > Is this point documented in the document? I could not find it so far.
> > If not, what is the (reverse connectivity) check that need to be performed 
> > on the
> reverse link?
> 
> 
> none.
> 
> thanks,
> Peter
> 
> 
> >
> > A priori I could see multiple options:
> > a) link exist
> > b) link exist with a standard IGP metric  (seem the option defined in the 
> > ISO spec
> §7.2.8.2)
> > c) link exist with the FlexAlgo metric used by FlexAlgo
> > d) link exist with the FlexAlgo metric used by FlexAlgo and link complies to
> FlexAlgo constraints.
> >
> > I think we'll agree that this point requires uniformity across nodes hence
> standardization.
> >
> > Personally, I don't have significant preference, but the algo defined in §13
> "Calculation of Flexible Algorithm Paths" could be read as defining option 
> "d" (as
> links not following the constraints are "pruned from the computation") but 
> I'm not
> sure that this is intended for the two-way connectivity check.
> >
> > Thanks,
> > Regards,
> > --Bruno
> >
> >
> >
> >
> 
> _
> >
> > 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
> >
> >


_

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] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi authors, all,

I have a question related to the two-way connectivity check performed on each 
link during the FlexAlgo SPF.

Is this point documented in the document? I could not find it so far.
If not, what is the (reverse connectivity) check that need to be performed on 
the reverse link?

A priori I could see multiple options:
a) link exist
b) link exist with a standard IGP metric  (seem the option defined in the ISO 
spec §7.2.8.2)
c) link exist with the FlexAlgo metric used by FlexAlgo
d) link exist with the FlexAlgo metric used by FlexAlgo and link complies to 
FlexAlgo constraints.

I think we'll agree that this point requires uniformity across nodes hence 
standardization.

Personally, I don't have significant preference, but the algo defined in §13 
"Calculation of Flexible Algorithm Paths" could be read as defining option "d" 
(as links not following the constraints are "pruned from the computation") but 
I'm not sure that this is intended for the two-way connectivity check.

Thanks,
Regards,
--Bruno



_

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

Re: [Lsr] IS-IS flooding

[bruno.decraene]

Some more questions on S13 (speeding UP, aka sensing the receiver performance)

Can you clarifying the definition of the three measurements reported (LSPTxMax, 
Tx, RxAv)?

So far, it seems that LSPTxMax is always higher than RxAv, i.e. the sender's 
estimation seems higher than the receiver capability.
Could you elaborate why there is no loss of LSP?
Trying to guess on my side (since the algorithm is not published in the draft):
a) LSPTxMax seems in advance of phase (compare to the real sending rate)
b) the receiver seems buffering the LSP in excess rate. i.e. the algorithm 
seems to take benefit of a buffer that he knows nothing about (and may be 
specific to your implementation). Do you know the size of this buffer (either 
from implementation knowledge or from measurements)? If not, you could please 
send the rate data so that I can compute the one used. (looking at the second 
figure, the buffer seems to be at least 400LSP (220*(15-13) which a 
conservative measurement on the graph)


The second figure is showing two bursts.
Why/how has the sender paused?

Thank you,
--Bruno




From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of bruno.decra...@orange.com
Sent: Tuesday, August 3, 2021 10:41 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: [Lsr] IS-IS flooding

Les,

Thank you for the implementation and test results.
I have some clarification questions on your test results

S6:
What burst size did you use? And distributions of reals values if possible, if 
not (min, max, average, median) would be useful.
What scheduling frequency/period did you use on the sender?

S9:
Given that the sender seems to react after 1 second, it seems clear that 
feedback (PSNPs) was received before.
- How fast does the receiver sends PSNP? Is this default value or was that 
changed?
- What value did you use for you configured parameter "Receiver ACK Delay"?

Thank you,
--Bruno

_



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.

_

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] IS-IS flooding

[bruno.decraene]

Les,

Thank you for the implementation and test results.
I have some clarification questions on your test results

S6:
What burst size did you use? And distributions of reals values if possible, if 
not (min, max, average, median) would be useful.
What scheduling frequency/period did you use on the sender?

S9:
Given that the sender seems to react after 1 second, it seems clear that 
feedback (PSNPs) was received before.
- How fast does the receiver sends PSNP? Is this default value or was that 
changed?
- What value did you use for you configured parameter "Receiver ACK Delay"?

Thank you,
--Bruno

_

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

Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[bruno.decraene]

Les,

Faster flooding may be achieved without protocol extension. But if we are at 
changing flooding, it would be reasonable to try to make it good (rather than 
just faster than today).
In particular some goals are:
- faster flooding when the receiver has free cycles
- slower flooding when the receiver is busy/congested (either by flooding, or 
any CPU computation including not coming from IS-IS)
- avoiding/minimizing the parameters that the network operator is been asked to 
tune
- avoiding/minimizing the loss of LSPs
- robust to a wide variety of conditions (good ones and bad ones)

You seem to agree on changing the flooding behaviour on both the sender and the 
receiver so that they can better cooperate. That’s protocol extension to me 
(and IMHO much bigger than the sending of info in one TLV)

Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, July 9, 2021 7:49 PM
To: DECRAENE Bruno INNOV/NET ; lsr-cha...@ietf.org
Cc: lsr@ietf.org
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

Bruno –

Neither of us has presented anything new of substance in the last few IETFs.
There were two presentations recently - one by Arista and one by Huawei – each 
of which simply demonstrated that it is possible to flood faster - and that in 
order to do so it is helpful to send acks faster - both points on which there 
is no disagreement.

To have a productive discussion we both need to present new data - which is why 
having the discussion as part of the meeting at which the presentations occur 
makes sense to me.

We removed the example(sic) algorithm from our draft because it was only an 
example, is not normative, and we did not want the discussion of our approach 
to be bogged down in a debate on the specifics of the example algorithm.
Based on your response, seems like we were right to remove the algorithm. 

Regarding WG adoption, one of the premises of our draft is that faster flooding 
can be achieved w/o protocol extensions and so there is no need for a draft at 
all. I am sure we do not yet agree on this - but I do hope that makes clear why 
adopting either draft at this time is premature.

   Les


From: bruno.decra...@orange.com 
mailto:bruno.decra...@orange.com>>
Sent: Friday, July 9, 2021 9:15 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr-cha...@ietf.org
Cc: lsr@ietf.org
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

Les,

> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
[…]
> I also think it would be prudent to delay WG adoption

For how long exactly would it be “prudent to delay WG adoption”? (in addition 
to the past two years)
Until what condition?

It’s been two years now since draft-decraene-lsr-isis-flooding-speed brought 
this subject to the WG (and even more in private discussions).
Two years during which we have presented our work to the WG, discussed your 
comments/objections, been asked to provide more data and consequently worked 
harder to implement it and obtain evaluation results.
What’s precisely the bar before a call for WG adoption be initiated?
We have data proving the benefit, so after those two years, what are your clear 
and precise _technical_ objections to the mechanism proposed in 
draft-decraene-lsr-isis-flooding-speed?

Coming back to draft-decraene-lsr-isis-flooding-speed,
we have a specification and the flow control part is stable.
We have an implementation and many evaluations demonstrating that flow control 
alone is very effective in typical conditions.
we have an additional congestion control part which is still been refined but 
this part is a local behavior which don’t necessarily needs to be standardized 
and which is mostly useful when the receivers of the LSP is not CPU-bound which 
does not seem to be the case from what we have seen. (in most of the cases, 
receivers are CPU bound. In fact, we needed to artificially create I/O 
congestion in order to evaluate the congestion control part) .


Regarding your draft, in the latest version of your draft, published yesterday, 
you have removed the specification of your proposed congestion control 
algorithm… Based on this, I don’t see how technical discussion and comparison 
of the specification can be achieved.
You have an implementation. This is good to know and we are ready to evaluate 
it under the same conditions than our implementation, so that we can compare 
the data. Could you please send us an image? We may be able to have data for 
the interim.

--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, July 9, 2021 5:00 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>; 
lsr-cha...@ietf.org; 
lsr@ietf.org
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

As is well known, there are two drafts in this problem space:

Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[bruno.decraene]

Les,

> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
[...]
> I also think it would be prudent to delay WG adoption

For how long exactly would it be "prudent to delay WG adoption"? (in addition 
to the past two years)
Until what condition?

It's been two years now since draft-decraene-lsr-isis-flooding-speed brought 
this subject to the WG (and even more in private discussions).
Two years during which we have presented our work to the WG, discussed your 
comments/objections, been asked to provide more data and consequently worked 
harder to implement it and obtain evaluation results.
What's precisely the bar before a call for WG adoption be initiated?
We have data proving the benefit, so after those two years, what are your clear 
and precise _technical_ objections to the mechanism proposed in 
draft-decraene-lsr-isis-flooding-speed?

Coming back to draft-decraene-lsr-isis-flooding-speed,
we have a specification and the flow control part is stable.
We have an implementation and many evaluations demonstrating that flow control 
alone is very effective in typical conditions.
we have an additional congestion control part which is still been refined but 
this part is a local behavior which don't necessarily needs to be standardized 
and which is mostly useful when the receivers of the LSP is not CPU-bound which 
does not seem to be the case from what we have seen. (in most of the cases, 
receivers are CPU bound. In fact, we needed to artificially create I/O 
congestion in order to evaluate the congestion control part) .


Regarding your draft, in the latest version of your draft, published yesterday, 
you have removed the specification of your proposed congestion control 
algorithm... Based on this, I don't see how technical discussion and comparison 
of the specification can be achieved.
You have an implementation. This is good to know and we are ready to evaluate 
it under the same conditions than our implementation, so that we can compare 
the data. Could you please send us an image? We may be able to have data for 
the interim.

--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, July 9, 2021 5:00 PM
To: DECRAENE Bruno INNOV/NET ; lsr-cha...@ietf.org; 
lsr@ietf.org
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

As is well known, there are two drafts in this problem space:

https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
and
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/


Regarding the latter, we also have a working implementation and we also have 
requested a presentation slot for IETF 111 LSR WG meeting.

I agree with Bruno that the time available in the WG meeting will likely be 
inadequate to present full updates for both drafts. In addition, I think it is 
important that the WG have
an opportunity to discuss publicly in an interactive way, the merits of each 
proposal. The likelihood that time will be available in the scheduled WG 
meeting for that discussion as well seems low.

I therefore join w Bruno in suggesting that an interim meeting dedicated to the 
flooding speed topic be organized.
Given the short time available before IETF 111, I would suggest that we look at 
scheduling an interim meeting after IETF 111 - but I leave it to the WG chairs 
to decide when to schedule this.

I also think it would be prudent to delay WG adoption calls for either draft 
until after such an interim meeting is held. In that way the WG can make a more 
informed decision.

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, July 9, 2021 2:01 AM
To: lsr-cha...@ietf.org; 
lsr@ietf.org
Subject: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

Hi chairs, WG,

Over the last two years, we have presented and the WG discussed 
draft-decraene-lsr-isis-flooding-speed at IETF 105 and "107"
IETF 105: https://datatracker.ietf.org/meeting/105/proceedings#lsrNote: 
that the presentation is in first slot/video but a large part of the discussion 
is in the second one.
IETF 107/interim: 
https://datatracker.ietf.org/meeting/interim-2020-lsr-02/materials/agenda-interim-2020-lsr-02-lsr-01-07.html

The goal is to improve flooding performance and robustness to make it both 
faster when the receiver have free cycles, and slower when the receiver is 
congested.

In addition to technical discussions, a feedback was that implementation and 
tests/evaluation would be good in order to evaluate the proposal.

We are reporting that we have an implementation of [1] based on the open source 
Free Range Routing implementation.
We are now ready to report the evaluation to the WG. We have a lot of data so 
ideally would need around an hour in order to cover the whole picture.

We have requested a slot for IETF 111 LSR meeting. If the IETF 111 slot is 
short, we'd like to request for an interim 

[Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

[bruno.decraene]

Hi chairs, WG,

Over the last two years, we have presented and the WG discussed 
draft-decraene-lsr-isis-flooding-speed at IETF 105 and "107"
IETF 105: https://datatracker.ietf.org/meeting/105/proceedings#lsrNote: 
that the presentation is in first slot/video but a large part of the discussion 
is in the second one.
IETF 107/interim: 
https://datatracker.ietf.org/meeting/interim-2020-lsr-02/materials/agenda-interim-2020-lsr-02-lsr-01-07.html

The goal is to improve flooding performance and robustness to make it both 
faster when the receiver have free cycles, and slower when the receiver is 
congested.

In addition to technical discussions, a feedback was that implementation and 
tests/evaluation would be good in order to evaluate the proposal.

We are reporting that we have an implementation of [1] based on the open source 
Free Range Routing implementation.
We are now ready to report the evaluation to the WG. We have a lot of data so 
ideally would need around an hour in order to cover the whole picture.

We have requested a slot for IETF 111 LSR meeting. If the IETF 111 slot is 
short, we'd like to request for an interim meeting. In order to keep the 
context, the sooner/closer to IETF 111 seems the better.

Since we have an implementation, we have requested for a code point, in order 
to avoid squatting on one. This is currently under review by the designed 
experts.

Finally, given the two-years work, the specification, the implementation and 
extensive evaluation, we'd like to ask for WG adoption.

Thanks,
Regards,
--Bruno


[1] https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed


_

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

Re: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

[bruno.decraene]

OK. Crystal clear.

Thanks Peter.

--Bruno

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, June 17, 2021 4:59 PM
> To: DECRAENE Bruno INNOV/NET ; Acee Lindem
> (acee) ; lsr@ietf.org
> Cc: lsr-...@ietf.org; Christian Hopps ; 
> draft-ietf-lsr-flex-
> algo@ietf.org
> Subject: Re: Second Working Last Call for draft-ietf-lsr-flex-algo
> 
> Hi Bruno,
> 
> On 17/06/2021 16:12, bruno.decra...@orange.com wrote:
> > Hi,
> >
> > I have a question/comment.
> >
> > I think that we all agree that FlexAlgo/Link State computation requires
> > that all node use the same topology to compute their SPF. Otherwise,
> > permanent forwarding loops are probable.
> >
> > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12
> > says
> >
> > “ASLA Admin Group Advertisements to be used by the Flexible Algorithm
> >
> > Application MAY use either the Administrative Group or Extended
> >
> > Administrative Group encodings. »
> >
> > My reading of the above is that the sender of the attribute is free to
> > advertise either Administrative Groups or Extended Administrative Group
> > encoding (or both).
> 
> correct.
> 
> >
> > In order to enforce topology consistency, I’m assuming that there is a
> > non-expressed requirement for the node reading the attribute to be able
> > to read both. (ie. MUST support the reading of both encodings).
> 
> yes, the receiver MUST be able to accept both.
> 
> 
> >
> > Is this a correct assumption?
> >
> > - if so, could this requirement be written in the document. (If we have
> > to choose one, I’d rather have the “MUST” requirement expressed rather
> > than the “MAY”)
> 
> will add to the text.
> 
> thanks,
> Peter
> 
> 
> >
> > - if not, how is the topology made consistent across all nodes?
> >
> > Thank you,
> >
> > Regards,
> >
> > --Bruno
> >
> > *From**:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem (acee)
> > *Sent:* Wednesday, June 16, 2021 4:01 PM
> > *To:* lsr@ietf.org
> > *Cc:* lsr-...@ietf.org; Christian Hopps ;
> > draft-ietf-lsr-flex-algo@ietf.org
> > *Subject:* [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo
> >
> > After the first successful WG last call, the authors discovered that
> > some re-work was needed for OSPF AS External route calculation –
> > specifically with respect to the Flex Algorithm ASBR metrics and
> > calculation. This was fixed and there were clarifications in the IANA
> > section (see versions -14 and -15). The draft has been stable since
> > April and we are now ready to WG last call the updated version.
> >
> > Without further ado, this begins a 2 week WG Last Call, ending on July
> > 1st, 2021, for draft-ietf-lsr-flex-algo
> >
> > https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/
> >
> > All authors, please indicate by sending an email to the list, whether
> > you aware of any other IPR beyond what is already posted:
> >
> >    [>From
> > https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]
> >
> > https://datatracker.ietf.org/ipr/3910/
> >
> > https://datatracker.ietf.org/ipr/3248/
> >
> > Thanks,
> >
> > Chris & Acee.
> >
> >
> __
> ___
> >
> > 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.
> >


_

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.

Re: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi,

I have a question/comment.

I think that we all agree that FlexAlgo/Link State computation requires that 
all node use the same topology to compute their SPF. Otherwise, permanent 
forwarding loops are probable.

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12 
says


“ASLA Admin Group Advertisements to be used by the Flexible Algorithm
   Application MAY use either the Administrative Group or Extended
   Administrative Group encodings. »

My reading of the above is that the sender of the attribute is free to 
advertise either Administrative Groups or Extended Administrative Group 
encoding (or both).

In order to enforce topology consistency, I’m assuming that there is a 
non-expressed requirement for the node reading the attribute to be able to read 
both. (ie. MUST support the reading of both encodings).
Is this a correct assumption?
- if so, could this requirement be written in the document. (If we have to 
choose one, I’d rather have the “MUST” requirement expressed rather than the 
“MAY”)
- if not, how is the topology made consistent across all nodes?

Thank you,
Regards,
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, June 16, 2021 4:01 PM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ; 
draft-ietf-lsr-flex-algo@ietf.org
Subject: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

After the first successful WG last call, the authors discovered that some 
re-work was needed for OSPF AS External route calculation – specifically with 
respect to the Flex Algorithm ASBR metrics and calculation. This was fixed and 
there were clarifications in the IANA section (see versions -14 and -15). The 
draft has been stable since April and we are now ready to WG last call the 
updated version.


Without further ado, this begins a 2 week WG Last Call, ending on July 1st, 
2021, for draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.



_

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

Re: [Lsr] Proposed Errata for RFCs 8919/8920

[bruno.decraene]

Les, Peter,

Thank you for agreeing to clarify the sentence and for the effort put in 
proposing a new text.

Proposed text looks much better to me. I particularly like the either MUST or 
MUST NOT statement.

I have one comment.
In the RFC, the term "advertisement" is used to refer both to sub-TLV [1] and 
to ASLA attribute [2]
[1] https://www.rfc-editor.org/rfc/rfc8919.html#name-legacy-advertisements
[2] https://www.rfc-editor.org/rfc/rfc8919.html#name-advertising-application-spe

As such, I would have a slight preference to be explicit about the type of 
advertisement which is meant. Especially since Gunter, an AD and myself raised 
that exact point, and that OSPF and IS-IS did not seemed aligned on this.

I would propose the following change in RFC 8919 section 4.2 & RFC 8920 section 
5
OLD: Such advertisements MUST
NEW: Such link attribute advertisements MUST

(I'm aware that the previous sentence starts with "Link attributes MAY be 
advertised", which in general should be a clear enough reference. But since we 
are clarifying, IMHO the more straightforward the clarification, the better, 
especially for the OSPF document which seemed to use the alternative 
understanding)


I definitely agree that this wording affects interoperability and must be fixed.
I'm not taking position (and don't care) whether an errata is the appropriate 
way. I'm happy to leave this to the chairs and AD. But my understanding is that 
if the errata is not classified as "Verified", then we'll need a bis document.

Thanks,
Regards,
--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, June 15, 2021 5:25 PM
To: lsr@ietf.org
Cc: DECRAENE Bruno INNOV/NET ; Van De Velde, Gunter 
(Nokia - BE/Antwerp) 
Subject: Proposed Errata for RFCs 8919/8920


Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Errata before officially filing them.



  Les and Peter


Errata Explanation

Both RFC 8919 and RFC 8920 define advertising link attributes with zero length 
Standard Application Bit Mask (SABM) and zero length User Defined Application 
Bit Mask (UDABM)
as a means of advertising link attributes that can be used by any application. 
However, the text uses the word "permitted", suggesting that the use of such 
advertisements is "optional".
Such an interpretation could lead to interoperability issues and is not what 
was intended.

The replacement text below makes explicit the specific conditions when such 
advertisements MUST be used and the specific conditions under which they MUST 
NOT be used.

RFC 8919 Section 4.2:

OLD

"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications,
then any standard application and/or any user-defined application is permitted 
to use that set of link attributes so long as there is not another set of 
attributes
advertised on that same link that is associated with a non-zero-length 
Application Identifier Bit Mask with a matching Application Identifier Bit set."

NEW

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

RFC 8919 Section 6.2

OLD

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, these advertisements are permitted to be used by the new 
application. If this is not what is intended, then existing advertisements MUST 
be readvertised
with an explicit set of applications specified before a new application is 
introduced."


NEW

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, the new application will use these advertisements, when the 
aforementioned restrictions are met. If this is not what is intended, then 
existing
advertisements MUST be readvertised with an 

Re: [Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

Les, Peter,

Thanks for the clarification. This is crystal clear.
This address my concern. My goal is specification clarity to avoid interop 
issues at the earliest stage, because the latter the misalignment is found the 
bigger the delay and the cost, both for vendors and network operators.

Thank you for working on a revised language and for the errata.

--Bruno
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, June 4, 2021 7:16 PM
To: DECRAENE Bruno INNOV/NET ; 
draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org
Subject: RE: draft-ietf-lsr-flex-algo

Bruno -

The intent of the RFC 8919 language is to say:

1)If there are ASLA advertisements w non-zero SABM/UABM matching the 
application,  these MUST be used
2)If there are no matching ASLA advertisements as per #1, then ASLA 
advertisements w zero length SABM/UABM (if present) MUST be used

There is no intent of making these rules "optional".

Peter and I are working on revised language that will make this more explicit 
(as well as resolving the unintentional discrepancies between the IS-IS/OSPF 
RFCs that you pointed out in an earlier thread).
Once language is agreed upon, these will be filed as Errata.
But it is important to note that this is a clarification - not a change in 
intended behavior.

Hope this is sufficient to address your concern.
Thanx for helping us to improve the quality of the RFCs.

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, June 4, 2021 2:03 AM
To: 
draft-ietf-lsr-flex-a...@ietf.org; 
lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-flex-algo

Hi all,

I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1]

FlexAlgo is distributed routing computation so it's required that all routers 
use exactly the same data to compute the routes/SPF.

FlexAlgo is clear that ASLA MUST be used:

"Link attribute advertisements that are to be used during Flex-

   Algorithm calculation MUST use the Application-Specific Link

   Attribute (ASLA) advertisements defined in 
[RFC8919] or 
[RFC8920],"

However ASLA provides multiple ways to advertise IGP attributes and does not 
seem precise enough in its specification.
"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes"

My issue is the use of the term "permitted" which
a) is not a normative keyword
b)IMHO translates to MAY hence also MAY NOT. While we need a MUST to ensure 
a consistent SPF.



One example of issue is when FlexAlgo uses a metric different from the IGP 
(e.g. TE-metric) , and one node advertises this TE-metric in an ASLA with 
zero-length Bit Mask.
- If one node uses this TE-metric (since it is permitted to) it includes that 
link in its SPF
- If another node does not use this TE-metric (since it is not required to) it 
prunes that link from its SPF
I think it's self-evident that we would end up with a permanent routing loop.

Ideally, I would probably have preferred ALSA to be specific about the 
behaviour but ASLA is already published as RFC so it's a bit late
So at this point, I think that the burden is on FlexAlgo to specify the precise 
behaviour as a MUST in section 12. [2]

The smallest change from FlexAlgo draft standpoint may be to _require_ the use 
of the ASLA _with the X-Flag set_ . But I'm fine with whatever interoperable 
behaviour (well for me, ideally I'd prefer the behaviour already implemented by 
the implementations that I've deployed ;-) but that would be a selfish 
requirement).

Note that there are existing implementations and this would impact them. That 
been said, we do need the interop behaviour so if there are already 
inconsistent behaviours, some implementations will need to be changed (and 
hence become non interoperable with themselves)

Thanks,
Regards,
--Bruno


[1] https://www.rfc-editor.org/rfc/rfc8919.html
[2] https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12


_



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 

Re: [Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, June 4, 2021 4:50 PM
To: DECRAENE Bruno INNOV/NET 
Cc: draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo


To me this "permitted" is only about applying ASLA to all apps (no bit mask) 
except specific apps IDs matching their ID if present in the bit mask.
It is not about applying ASLA itself or not applying it at all.

[BD] I think that I agree but I don’t see how this relates to my comment.
Let’s come back to my example:
when FlexAlgo uses a metric different from the IGP (e.g. TE-metric) , and one 
node advertises this TE-metric in an ASLA with zero-length Bit Mask.
The question is: does FlexAlgo use this TE-metric (and hence the link)? Or not.
Is this already specified as a MUST or does extra text needs to be written?


   If link attributes are advertised associated with zero-length

   Application Identifier Bit Masks for both standard applications and

   user-defined applications, then any standard application and/or any

   user-defined application is permitted to use that set of link

   attributes so long as there is not another set of attributes

   advertised on that same link that is associated with a non-zero-

   length Application Identifier Bit Mask with a matching Application

   Identifier Bit set.



Is there any shipping implementation which reads this the way you interpret it 
and chooses not to apply it at all ?



[BD] I’ll refrain from speaking about implementations.

I’m not sure how much implementations have to do with a comment/question on the 
specification. The reference is the specification. Again, if this is so obvious 
that everyone agree on the behaviour, let’s write down the result in the spec 
or point me to an existing text in the spec.



Thanks,

Bruno



Thx

R.

On Fri, Jun 4, 2021 at 4:12 PM 
mailto:bruno.decra...@orange.com>> wrote:


From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, June 4, 2021 3:35 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>
Cc: 
draft-ietf-lsr-flex-a...@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo


Ok you meant domain wide not locally ... but there is already strong normative 
MUST in Flex Algo as the user of ASLA so no loop will happen.

The "permitted" from ASLA RFC is just to indicate what applications may use 
such attribute with zero-length
   Application Identifier Bit Masks as opposed to rest of the sentence which 
you did not quote which reads:

 ...so long as there is not another set of attributes

   advertised on that same link that is associated with a non-zero-

   length Application Identifier Bit Mask with a matching Application

   Identifier Bit set.



So context of "permitted" is not in the sense use or not use ASLA, but in the 
sense when both use zero length or none zero length app id is present.



Agreed that ASLA MUST be used.

Now ASLA allows two ways to advertise attributes (so both ways _are_ ALSA):

a) inside an ASLA with the X-flag set (attribute specifically for FlexAlgo)

b) inside an ASLA with all flags cleared (attribute that every application MAY 
use, so a priori including FlexAlgo)



My point is that for case “b”, “MAY” does not seem strong enough to ensure 
consistency along the SPT. I gave an example in my original email, you may 
refer to it.

A priori we need FlexAlgo to choose and specify whether the second signalling 
(“b”) MUST or MUST NOT be used. We just need to write this down. If we all 
agree on the choice, that’s easy. If we don’t, that’s harder but even more 
necessary for interop.



Alternatively, I’m wrong and that’s even better.



--Bruno





Thx



On Fri, Jun 4, 2021 at 2:56 PM 
mailto:bruno.decra...@orange.com>> wrote:
Hi Robert,

From: Robert Raszuk [mailto:rob...@raszuk.net]

Hi Bruno,

> I think it’s self-evident that we would end up with a permanent routing loop.

Is that so ? Wouldn't it just result in unidirectional link for a given app ? 
Maybe intentional ?

It seems that what you described may cause asymmetric routing but not a routing 
loop. After all packets belonging to an app are consistently using that app's 
topology in each node.

No, I’m only discussing a single link direction.
Different upstream routers would have a different understanding of this link 
direction.
e.g.
A-B-C
+---+

All links have a metric of 10 except A-C with a metric of 100.


B->C is the link that we are discussing. Some nodes e.g. “A” see a TE –metric, 
some node (e.g. “B”) not see a TE-metric
For traffic toward C:
- A is sending to B (A’s path is A-B-C with a metric of 20)
- B is sending to A (B’s path is B-A-C with a metric of 110)
--> looping between A and B

Cheers,
Bruno

Cheers,
R.





On Fri, Jun 4, 2021 at 11:03 AM 
mailto:bruno.decra...@orange.com>> wrote:
Hi all,

I think that I may have an issue with the 

Re: [Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, June 4, 2021 3:35 PM
To: DECRAENE Bruno INNOV/NET 
Cc: draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo


Ok you meant domain wide not locally ... but there is already strong normative 
MUST in Flex Algo as the user of ASLA so no loop will happen.

The "permitted" from ASLA RFC is just to indicate what applications may use 
such attribute with zero-length
   Application Identifier Bit Masks as opposed to rest of the sentence which 
you did not quote which reads:

 ...so long as there is not another set of attributes

   advertised on that same link that is associated with a non-zero-

   length Application Identifier Bit Mask with a matching Application

   Identifier Bit set.



So context of "permitted" is not in the sense use or not use ASLA, but in the 
sense when both use zero length or none zero length app id is present.



Agreed that ASLA MUST be used.

Now ASLA allows two ways to advertise attributes (so both ways _are_ ALSA):

a) inside an ASLA with the X-flag set (attribute specifically for FlexAlgo)

b) inside an ASLA with all flags cleared (attribute that every application MAY 
use, so a priori including FlexAlgo)



My point is that for case “b”, “MAY” does not seem strong enough to ensure 
consistency along the SPT. I gave an example in my original email, you may 
refer to it.

A priori we need FlexAlgo to choose and specify whether the second signalling 
(“b”) MUST or MUST NOT be used. We just need to write this down. If we all 
agree on the choice, that’s easy. If we don’t, that’s harder but even more 
necessary for interop.



Alternatively, I’m wrong and that’s even better.



--Bruno





Thx



On Fri, Jun 4, 2021 at 2:56 PM 
mailto:bruno.decra...@orange.com>> wrote:
Hi Robert,

From: Robert Raszuk [mailto:rob...@raszuk.net]

Hi Bruno,

> I think it’s self-evident that we would end up with a permanent routing loop.

Is that so ? Wouldn't it just result in unidirectional link for a given app ? 
Maybe intentional ?

It seems that what you described may cause asymmetric routing but not a routing 
loop. After all packets belonging to an app are consistently using that app's 
topology in each node.

No, I’m only discussing a single link direction.
Different upstream routers would have a different understanding of this link 
direction.
e.g.
A-B-C
+---+

All links have a metric of 10 except A-C with a metric of 100.


B->C is the link that we are discussing. Some nodes e.g. “A” see a TE –metric, 
some node (e.g. “B”) not see a TE-metric
For traffic toward C:
- A is sending to B (A’s path is A-B-C with a metric of 20)
- B is sending to A (B’s path is B-A-C with a metric of 110)
--> looping between A and B

Cheers,
Bruno

Cheers,
R.





On Fri, Jun 4, 2021 at 11:03 AM 
mailto:bruno.decra...@orange.com>> wrote:
Hi all,

I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1]

FlexAlgo is distributed routing computation so it’s required that all routers 
use exactly the same data to compute the routes/SPF.

FlexAlgo is clear that ASLA MUST be used:

“Link attribute advertisements that are to be used during Flex-

   Algorithm calculation MUST use the Application-Specific Link

   Attribute (ASLA) advertisements defined in 
[RFC8919] or 
[RFC8920],”

However ASLA provides multiple ways to advertise IGP attributes and does not 
seem precise enough in its specification.
“If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes”

My issue is the use of the term “permitted” which

a) is not a normative keyword

b)IMHO translates to MAY hence also MAY NOT. While we need a MUST to ensure 
a consistent SPF.



One example of issue is when FlexAlgo uses a metric different from the IGP 
(e.g. TE-metric) , and one node advertises this TE-metric in an ASLA with 
zero-length Bit Mask.
- If one node uses this TE-metric (since it is permitted to) it includes that 
link in its SPF
- If another node does not use this TE-metric (since it is not required to) it 
prunes that link from its SPF
I think it’s self-evident that we would end up with a permanent routing loop.

Ideally, I would probably have preferred ALSA to be specific about the 
behaviour but ASLA is already published as RFC so it’s a bit late
So at this point, I think that the burden is on FlexAlgo to specify the precise 
behaviour as a MUST in section 12. [2]

The smallest change from FlexAlgo draft standpoint may be to _require_ the use 
of the ASLA _with the X-Flag set_ . But I’m fine with whatever interoperable 
behaviour (well for me, ideally I’d prefer the behaviour already 

Re: [Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi Robert,

From: Robert Raszuk [mailto:rob...@raszuk.net]


Hi Bruno,

> I think it’s self-evident that we would end up with a permanent routing loop.

Is that so ? Wouldn't it just result in unidirectional link for a given app ? 
Maybe intentional ?

It seems that what you described may cause asymmetric routing but not a routing 
loop. After all packets belonging to an app are consistently using that app's 
topology in each node.

No, I’m only discussing a single link direction.
Different upstream routers would have a different understanding of this link 
direction.
e.g.
A-B-C
+---+

All links have a metric of 10 except A-C with a metric of 100.


B->C is the link that we are discussing. Some nodes e.g. “A” see a TE –metric, 
some node (e.g. “B”) not see a TE-metric
For traffic toward C:
- A is sending to B (A’s path is A-B-C with a metric of 20)
- B is sending to A (B’s path is B-A-C with a metric of 110)
à looping between A and B

Cheers,
Bruno

Cheers,
R.





On Fri, Jun 4, 2021 at 11:03 AM 
mailto:bruno.decra...@orange.com>> wrote:
Hi all,

I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1]

FlexAlgo is distributed routing computation so it’s required that all routers 
use exactly the same data to compute the routes/SPF.

FlexAlgo is clear that ASLA MUST be used:

“Link attribute advertisements that are to be used during Flex-

   Algorithm calculation MUST use the Application-Specific Link

   Attribute (ASLA) advertisements defined in 
[RFC8919] or 
[RFC8920],”

However ASLA provides multiple ways to advertise IGP attributes and does not 
seem precise enough in its specification.
“If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes”

My issue is the use of the term “permitted” which

a) is not a normative keyword

b)IMHO translates to MAY hence also MAY NOT. While we need a MUST to ensure 
a consistent SPF.



One example of issue is when FlexAlgo uses a metric different from the IGP 
(e.g. TE-metric) , and one node advertises this TE-metric in an ASLA with 
zero-length Bit Mask.
- If one node uses this TE-metric (since it is permitted to) it includes that 
link in its SPF
- If another node does not use this TE-metric (since it is not required to) it 
prunes that link from its SPF
I think it’s self-evident that we would end up with a permanent routing loop.

Ideally, I would probably have preferred ALSA to be specific about the 
behaviour but ASLA is already published as RFC so it’s a bit late
So at this point, I think that the burden is on FlexAlgo to specify the precise 
behaviour as a MUST in section 12. [2]

The smallest change from FlexAlgo draft standpoint may be to _require_ the use 
of the ASLA _with the X-Flag set_ . But I’m fine with whatever interoperable 
behaviour (well for me, ideally I’d prefer the behaviour already implemented by 
the implementations that I’ve deployed ;-) but that would be a selfish 
requirement).

Note that there are existing implementations and this would impact them. That 
been said, we do need the interop behaviour so if there are already 
inconsistent behaviours, some implementations will need to be changed (and 
hence become non interoperable with themselves)

Thanks,
Regards,
--Bruno


[1] https://www.rfc-editor.org/rfc/rfc8919.html
[2] https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12


_



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

_

Ce message et ses pieces jointes peuvent contenir des 

[Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi all,

I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1]

FlexAlgo is distributed routing computation so it's required that all routers 
use exactly the same data to compute the routes/SPF.

FlexAlgo is clear that ASLA MUST be used:

"Link attribute advertisements that are to be used during Flex-

   Algorithm calculation MUST use the Application-Specific Link

   Attribute (ASLA) advertisements defined in 
[RFC8919] or 
[RFC8920],"

However ASLA provides multiple ways to advertise IGP attributes and does not 
seem precise enough in its specification.
"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes"

My issue is the use of the term "permitted" which

a) is not a normative keyword

b)IMHO translates to MAY hence also MAY NOT. While we need a MUST to ensure 
a consistent SPF.



One example of issue is when FlexAlgo uses a metric different from the IGP 
(e.g. TE-metric) , and one node advertises this TE-metric in an ASLA with 
zero-length Bit Mask.
- If one node uses this TE-metric (since it is permitted to) it includes that 
link in its SPF
- If another node does not use this TE-metric (since it is not required to) it 
prunes that link from its SPF
I think it's self-evident that we would end up with a permanent routing loop.

Ideally, I would probably have preferred ALSA to be specific about the 
behaviour but ASLA is already published as RFC so it's a bit late
So at this point, I think that the burden is on FlexAlgo to specify the precise 
behaviour as a MUST in section 12. [2]

The smallest change from FlexAlgo draft standpoint may be to _require_ the use 
of the ASLA _with the X-Flag set_ . But I'm fine with whatever interoperable 
behaviour (well for me, ideally I'd prefer the behaviour already implemented by 
the implementations that I've deployed ;-) but that would be a selfish 
requirement).

Note that there are existing implementations and this would impact them. That 
been said, we do need the interop behaviour so if there are already 
inconsistent behaviours, some implementations will need to be changed (and 
hence become non interoperable with themselves)

Thanks,
Regards,
--Bruno


[1] https://www.rfc-editor.org/rfc/rfc8919.html
[2] https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12


_

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

Re: [Lsr] RFC 8919 clarification

[bruno.decraene]

Peter,


> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Bruno,
> 
> On 03/06/2021 15:41, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thank you for your answer and for your crystal clear email.
> >
> > As a side note, my reading of RFC 8920 is that this behaviour is
> > different in OSPF.
> 
> my reading is that it is consistent with the ISIS ASLA RFC.

Ah. Not an issue for our deployment as we are using IS-IS. But ideally I'd like 
to understand why we have a different reading.

RFC8920
If link attributes are advertised with zero-length Application Identifier Bit 
Masks for both standard applications and user-defined applications, then any 
standard application and/or any user-defined application is permitted to use 
that set of link attributes

RFC 8919
If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes so long as there is not another 
set of attributes advertised on that same link that is associated with a 
non-zero-length Application Identifier Bit Mask with a matching Application 
Identifier Bit set.


The difference that I'm seeing is that RFC 8919 seems to add an extra condition 
which is not present in OSPF " so long as there is not another set of 
attributes advertised on that same link that is associated with a 
non-zero-length Application Identifier Bit Mask with a matching Application 
Identifier Bit set."

--

RFC 8920
An application-specific advertisement (Application Identifier Bit Mask with a 
matching Application Identifier Bit set) for an attribute MUST always be 
preferred over the advertisement of the same attribute with the zero-length 
Application Identifier Bit Masks for both standard applications and 
user-defined applications on the same link.


- "for an attribute" seems to indicate that the choice is on a per attribute 
basis, rather than a per ASLA basis.
- "preferred over" seems to say the application (FlexAlgo) reads the attributes 
in both the "default" ALSA and the application specific ASLA. Just in case of 
duplicate, the attribute from the application specific ASLA is prefred. 


Thanks,
--Bruno

> 
> thanks,
> Peter
> 
> 
> >
> > “If link attributes are advertised with zero-length Application
> > Identifier Bit Masks for both standard applications and user-defined
> > applications, then any standard application and/or any user-defined
> > application is permitted to use that set of link attributes. If support
> > for a new application is introduced on any node in a network in the
> > presence of such advertisements, these advertisements are permitted to
> > be used by the new application. If this is not what is intended, then
> > existing advertisements MUST be readvertised with an explicit set of
> > applications specified before a new application is introduced.An
> > application-specific advertisement (Application Identifier Bit Mask with
> > a matching Application Identifier Bit set) for an attribute MUST always
> > be preferred over the advertisement of the same attribute with the
> > zero-length Application Identifier Bit Masks for both standard
> > applications and user-defined applications on the same link.”
> >
> > Not sure whether there was a technical reason for this difference, but
> > it didn’t help be clarify by myself the RFC 8919 formulation.
> >
> > Thank you,
> >
> > --Bruno
> >
> >> -Original Message-
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >
> >> Sent: Thursday, June 3, 2021 3:28 PM
> >
> >> To: DECRAENE Bruno INNOV/NET ;
> lsr@ietf.org
> >
> >> Subject: Re: [Lsr] RFC 8919 clarification
> >
> >>
> >
> >> Hi Bruno,
> >
> >>
> >
> >> On 03/06/2021 14:55, bruno.decra...@orange.com wrote:
> >
> >> > Hi all,
> >
> >> >
> >
> >> > In order to (try to) avoid interop issues, I have a clarification
> >
> >> > question on RFC 8919.
> >
> >> >
> >
> >> > “If link attributes are advertised associated with zero-length
> >
> >> > Application Identifier Bit Masks for both standard applications and
> >
> >> > user-defined applications, then any standard application and/or any
> >
> >> > user-defined application is permitted to use that set of link attributes
> >
> >> > so long as there is not another set of attributes advertised on that
> >
> >> > same link that is associated with a non-zero-length Application
> >
> >> > Identifier Bit Mask with a matching Application Identifier Bit set.”
> >
> >> >
> >
> >> > https://www.rfc-editor.org/rfc/rfc8919.html#name-application-specific-link-a
> >
> >> >
> >
> >> > My reading is that if one ALSA “S1” with a specific application bit set
> >
> >> > (e.g. X-Flag/FlexAlgo) advertises a set of attributes (A1, A2), then
> >
> >> > this ALSA (or the set of all ASLA occurrence with the X-Flag set) needs
> >
> >> > to advertise _/all/_ the attributes used by this application.

Re: [Lsr] RFC 8919 clarification

[bruno.decraene]

Hi Peter,



Thank you for your answer and for your crystal clear email.





As a side note, my reading of RFC 8920 is that this behaviour is different in 
OSPF.

“If link attributes are advertised with zero-length Application Identifier Bit 
Masks for both standard applications and user-defined applications, then any 
standard application and/or any user-defined application is permitted to use 
that set of link attributes. If support for a new application is introduced on 
any node in a network in the presence of such advertisements, these 
advertisements are permitted to be used by the new application. If this is not 
what is intended, then existing advertisements MUST be readvertised with an 
explicit set of applications specified before a new application is 
introduced.An application-specific advertisement (Application Identifier Bit 
Mask with a matching Application Identifier Bit set) for an attribute MUST 
always be preferred over the advertisement of the same attribute with the 
zero-length Application Identifier Bit Masks for both standard applications and 
user-defined applications on the same link.”



Not sure whether there was a technical reason for this difference, but it 
didn’t help be clarify by myself the RFC 8919 formulation.





Thank you,

--Bruno



> -Original Message-

> From: Peter Psenak [mailto:ppse...@cisco.com]

> Sent: Thursday, June 3, 2021 3:28 PM

> To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org

> Subject: Re: [Lsr] RFC 8919 clarification

>

> Hi Bruno,

>

> On 03/06/2021 14:55, bruno.decra...@orange.com wrote:

> > Hi all,

> >

> > In order to (try to) avoid interop issues, I have a clarification

> > question on RFC 8919.

> >

> > “If link attributes are advertised associated with zero-length

> > Application Identifier Bit Masks for both standard applications and

> > user-defined applications, then any standard application and/or any

> > user-defined application is permitted to use that set of link attributes

> > so long as there is not another set of attributes advertised on that

> > same link that is associated with a non-zero-length Application

> > Identifier Bit Mask with a matching Application Identifier Bit set.”

> >

> > https://www.rfc-editor.org/rfc/rfc8919.html#name-application-specific-link-a

> >

> > My reading is that if one ALSA “S1” with a specific application bit set

> > (e.g. X-Flag/FlexAlgo) advertises a set of attributes (A1, A2), then

> > this ALSA (or the set of all ASLA occurrence with the X-Flag set) needs

> > to advertise _/all/_ the attributes used by this application.

>

> right.

>

> >

> > So:

> >

> > - if we have another ALSA “S2” advertising zero-length Application

> > Identifier Bit Masks for both standard applications and user-defined

> > applications, that application (FlexAlgo) is not permitted to fall back

> > to “S2” in order to learn a another attribute (A3). Regardless of

> > whether S2 advertises the L-flag (legacy) or its own Link Attribute

> > sub-sub-TLVs.

>

> yes, that is correct.

>

> >

> > - if we don’t have such S2 ASLA, that application (FlexAlgo) is not

> > permitted to fall back to legacy attributes.

>

> well, if you have S1 as you mentioned above, S2 becomes irrelevant from

> the flex-algo perspective. So you are right, flex-algo is not allowed to

> use legacy advertisement in this case.

>

> >

> > IOW, an ALSA for application X, does not advertise additional/more

> > specific attributes for application X, but _/all/_ the attributes that

> > application X is allowed to read.

>

> correct.

>

>

> > As a consequence, if an attribute is

> > common to N set of applications, it needs to be advertised N times in N

> > ASLA.

>

> depends. If the set of attributes that are common across N applications

> represent the full set of attributes for all these N applications, you

> simply advertise them once with SAMB/UDAMB including the bits for all N

> applications. If the set of attributes for each application is

> different, but there is one attribute that is common, you need to

> include that attribute in ASLA advertisement for every app.

>

>

> thanks,

> Peter

>

>

>

>

>

> >

> > Thanks for correcting/confirming.

> >

> > Thanks,

> >

> > Regards,

> >

> > Bruno

> >

> >

> __

> ___

> >

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

> 

[Lsr] RFC 8919 clarification

[bruno.decraene]

Hi all,

In order to (try to) avoid interop issues, I have a clarification question on 
RFC 8919.

"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes so long as there is not another 
set of attributes advertised on that same link that is associated with a 
non-zero-length Application Identifier Bit Mask with a matching Application 
Identifier Bit set."
https://www.rfc-editor.org/rfc/rfc8919.html#name-application-specific-link-a

My reading is that if one ALSA "S1"  with a specific application bit set (e.g. 
X-Flag/FlexAlgo) advertises a set of attributes (A1, A2), then this ALSA (or 
the set of all ASLA occurrence with the X-Flag set) needs to advertise _all_ 
the attributes used by this application.

So:
- if we have another ALSA "S2" advertising zero-length Application Identifier 
Bit Masks for both standard applications and user-defined applications, that 
application (FlexAlgo) is not permitted to fall back to "S2" in order to learn 
a another attribute (A3). Regardless of whether S2 advertises the L-flag 
(legacy) or its own Link Attribute sub-sub-TLVs.
- if we don't have such S2 ASLA, that application (FlexAlgo) is not permitted 
to fall back to legacy attributes.

IOW, an ALSA for application X, does not advertise additional/more specific 
attributes for application X, but _all_ the attributes that application X is 
allowed to read. As a consequence, if an attribute is common to N set of 
applications, it needs to be advertised N times in N ASLA.

Thanks for correcting/confirming.

Thanks,
Regards,
Bruno


_

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] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi all,

Better safe than sorry, I guess. 

FYI, in -08 (a year ago) draft introduced one single iteration of the FA 
acronym: "The scope of the FA computation is an area"

Do we really want to create that FA acronym for Flex Algo?

FA has already been used for  Forwarding Adjacency (e.g., [1]) and this could 
create some ambiguity (e.g., FA link, enable FA...), especially as the domain 
is the same (IGP routing, TE). 

Alternatively, FX or FxA could be used for FlexAlgo (athough this would not 
match with FAD), or no acronym defined since we did not used one for the first 
3 years.

[1] https://datatracker.ietf.org/doc/html/draft-saad-sr-fa-link

Regards,
--Bruno



_

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

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[bruno.decraene]

Acee, Chris,

I’m not aware of non-disclosed IPR.

Thanks,
--Bruno

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, May 12, 2021 11:09 PM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Esteemed Members of the LSR WG,

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

 https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/

Please indicate your support or objection by May 27th, 2021.

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

Thanks,
Chris and Acee



_

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

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[bruno.decraene]

Hi Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Hi Bruno,
> 
> On 12/05/2021 10:24, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thanks for the answer.
> > Please see inline.
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>
> >> Hi Bruno,
> >>
> >>
> >> On 12/05/2021 09:51, bruno.decra...@orange.com wrote:
> >>> Hi Xuesong,
> >>>
> >>> Clarification question: are you talking about interoperability (between
> >>> two nodes) or compliancy (between an implementation and the RFC)?
> >>
> >> I'm afraid the two are related. If we mandate the Prefix Attribute
> >> Sub-TLV inside the Locator TLV, we would have to say that the Locator
> >> TLV without the Prefix Attribute Sub-TLV MUST be ignored.
> >
> > Mandating the advertisement is one thing (if it's useful, not to mention
> required, let's advertise it).
> > Then why would we have to say that the Locator TLV without the Prefix
> Attribute Sub-TLV MUST be ignored ? On the receiver side, a priori, current
> spec allows for both (presence & non-presence), no? That seem like an error
> handling situation that we can choose.
> 
> if we mandate something we need to say what happens when the mandated
> data is not present 

Absolutely. I could not agree more.
I call this error handling.

>- typically we ignore. 
OK, but here we seem free to define "whatever" error handling we want since 
current version of the draft allows for both presence or non-presence.

Thanks,
--Bruno

> If we don't ignore, then we
> are not really mandating it.
>
> thanks,
> Peter
> 
> 
> >
> > Thanks for the discussion,
> > --Bruno
> >
> >> As a result,
> >> implementations that do not send the Prefix Attribute Sub-TLV would not
> >> just be not compliant, but would also not interoperate with the ones
> >> that follow the specification.
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> If the former, could you please spell out the interop issue?
> >>>
> >>> Thanks,
> >>>
> >>> Best regards,
> >>>
> >>> --Bruno
> >>>
> >>> *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gengxuesong
> >>> (Geng Xuesong)
> >>> *Sent:* Wednesday, May 12, 2021 9:16 AM
> >>> *To:* Les Ginsberg (ginsberg) ; Shraddha Hegde
> >>> ; Alvaro Retana
> >>> ; Peter Psenak (ppsenak)
> >> ;
> >>> lsr@ietf.org
> >>> *Cc:* cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
> >>> Van De Velde, Gunter (Nokia - BE/Antwerp)
> >> 
> >>> *Subject:* Re: [Lsr] Last Call:
> >>>  (IS-IS Extension to Support
> >>> Segment Routing over IPv6 Dataplane) to Proposed Standard
> >>>
> >>> Hi Les,
> >>>
> >>> Prefix Attributes sub-TLV is necessary when locator is leaked.
> >>>
> >>> So we are not against Prefix Attribute sub-TLV implementation. We just
> >>> propose to keep it optional (“should” rather than “must”) for
> >>> interoperability.
> >>>
> >>> Best
> >>>
> >>> Xuesong
> >>>
> >>> *From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> >>> *Sent:* Wednesday, May 12, 2021 6:29 AM
> >>> *To:* Shraddha Hegde  >>> >; Alvaro Retana
> >>> mailto:aretana.i...@gmail.com>>; Peter
> Psenak
> >>> (ppsenak) mailto:ppse...@cisco.com>>;
> >> lsr@ietf.org
> >>> ; Gengxuesong (Geng Xuesong)
> >>> mailto:gengxues...@huawei.com>>
> >>> *Cc:* cho...@chopps.org ;
> >>> draft-ietf-lsr-isis-srv6-extensi...@ietf.org
> >>> ; Van De Velde,
> >>> Gunter (Nokia - BE/Antwerp)  >>> >
> >>> *Subject:* RE: [Lsr] Last Call:
> >>>  (IS-IS Extension to Support
> >>> Segment Routing over IPv6 Dataplane) to Proposed Standard
> >>>
> >>> Shraddha/ Xuesong –
> >>>
> >>> Since Prefix Attributes sub-TLV is required for correct operation when a
> >>> Locator is leaked, would it be safe to assume that your implementations
> >>> either do not leak Locators or you advise your customers not to deploy
> >>> this feature with multiple levels?
> >>>
> >>> The problem with allowing the sub-TLV to be optional is that if the
> >>> sub-TLV is omitted you cannot tell whether the Locator has been leaked
> –
> >>> so you don’t know whether you have a problem or not.
> >>>
> >>> The safest thing to do is require prefix-attributes sub-TLV always –
> >>> then you can guarantee that if the prefix is leaked the necessary
> >>> information will be present.
> >>>
> >>> Anything else leaves us vulnerable.
> >>>
> >>> We all appreciate interoperability considerations, but frankly this is a
> >>> gap that needs to be closed to support correct operation.
> >>>
> >>>      Les
> >>>
> >>> *From:*Lsr mailto:lsr-boun...@ietf.org>> *On
> >>> Behalf Of *Shraddha Hegde
> >>> *Sent:* Tuesday, May 11, 2021 8:21 AM
> >>> *To:* Alvaro Retana  >>> >; Peter Psenak (ppsenak)
> >>> mailto:ppse...@cisco.com>>; lsr@ietf.org
> >>> 
> >>> *Cc:* cho...@chopps.org ;
> >>> 

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[bruno.decraene]

Hi Peter,

Thanks for the answer.
Please see inline.

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Hi Bruno,
> 
> 
> On 12/05/2021 09:51, bruno.decra...@orange.com wrote:
> > Hi Xuesong,
> >
> > Clarification question: are you talking about interoperability (between
> > two nodes) or compliancy (between an implementation and the RFC)?
> 
> I'm afraid the two are related. If we mandate the Prefix Attribute
> Sub-TLV inside the Locator TLV, we would have to say that the Locator
> TLV without the Prefix Attribute Sub-TLV MUST be ignored. 

Mandating the advertisement is one thing (if it's useful, not to mention 
required, let's advertise it).
Then why would we have to say that the Locator TLV without the Prefix Attribute 
Sub-TLV MUST be ignored ? On the receiver side, a priori, current spec allows 
for both (presence & non-presence), no? That seem like an error handling 
situation that we can choose.

Thanks for the discussion,
--Bruno

> As a result,
> implementations that do not send the Prefix Attribute Sub-TLV would not
> just be not compliant, but would also not interoperate with the ones
> that follow the specification.
> 
> thanks,
> Peter
> 
> >
> > If the former, could you please spell out the interop issue?
> >
> > Thanks,
> >
> > Best regards,
> >
> > --Bruno
> >
> > *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gengxuesong
> > (Geng Xuesong)
> > *Sent:* Wednesday, May 12, 2021 9:16 AM
> > *To:* Les Ginsberg (ginsberg) ; Shraddha Hegde
> > ; Alvaro Retana
> > ; Peter Psenak (ppsenak)
> ;
> > lsr@ietf.org
> > *Cc:* cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
> > Van De Velde, Gunter (Nokia - BE/Antwerp)
> 
> > *Subject:* Re: [Lsr] Last Call:
> >  (IS-IS Extension to Support
> > Segment Routing over IPv6 Dataplane) to Proposed Standard
> >
> > Hi Les,
> >
> > Prefix Attributes sub-TLV is necessary when locator is leaked.
> >
> > So we are not against Prefix Attribute sub-TLV implementation. We just
> > propose to keep it optional (“should” rather than “must”) for
> > interoperability.
> >
> > Best
> >
> > Xuesong
> >
> > *From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> > *Sent:* Wednesday, May 12, 2021 6:29 AM
> > *To:* Shraddha Hegde  > >; Alvaro Retana
> > mailto:aretana.i...@gmail.com>>; Peter Psenak
> > (ppsenak) mailto:ppse...@cisco.com>>;
> lsr@ietf.org
> > ; Gengxuesong (Geng Xuesong)
> > mailto:gengxues...@huawei.com>>
> > *Cc:* cho...@chopps.org ;
> > draft-ietf-lsr-isis-srv6-extensi...@ietf.org
> > ; Van De Velde,
> > Gunter (Nokia - BE/Antwerp)  > >
> > *Subject:* RE: [Lsr] Last Call:
> >  (IS-IS Extension to Support
> > Segment Routing over IPv6 Dataplane) to Proposed Standard
> >
> > Shraddha/ Xuesong –
> >
> > Since Prefix Attributes sub-TLV is required for correct operation when a
> > Locator is leaked, would it be safe to assume that your implementations
> > either do not leak Locators or you advise your customers not to deploy
> > this feature with multiple levels?
> >
> > The problem with allowing the sub-TLV to be optional is that if the
> > sub-TLV is omitted you cannot tell whether the Locator has been leaked –
> > so you don’t know whether you have a problem or not.
> >
> > The safest thing to do is require prefix-attributes sub-TLV always –
> > then you can guarantee that if the prefix is leaked the necessary
> > information will be present.
> >
> > Anything else leaves us vulnerable.
> >
> > We all appreciate interoperability considerations, but frankly this is a
> > gap that needs to be closed to support correct operation.
> >
> >     Les
> >
> > *From:*Lsr mailto:lsr-boun...@ietf.org>> *On
> > Behalf Of *Shraddha Hegde
> > *Sent:* Tuesday, May 11, 2021 8:21 AM
> > *To:* Alvaro Retana  > >; Peter Psenak (ppsenak)
> > mailto:ppse...@cisco.com>>; lsr@ietf.org
> > 
> > *Cc:* cho...@chopps.org ;
> > draft-ietf-lsr-isis-srv6-extensi...@ietf.org
> > ; Van De Velde,
> > Gunter (Nokia - BE/Antwerp)  > >
> > *Subject:* Re: [Lsr] Last Call:
> >  (IS-IS Extension to Support
> > Segment Routing over IPv6 Dataplane) to Proposed Standard
> >
> > Juniper has an  implementation of SRv6 that does not support Prefix
> > attributes sub-tlv in locator TLV.
> >
> > We would prefer not to change the optional sub-TLV to MUST.
> >
> > Rgds
> >
> > Shraddha
> >
> > Juniper Business Use Only
> >
> > *From:*Lsr mailto:lsr-boun...@ietf.org>> *On
> > Behalf Of *Alvaro Retana
> > *Sent:* Friday, May 7, 2021 7:23 PM
> > *To:* Peter Psenak mailto:ppse...@cisco.com>>;
> > lsr@ietf.org 
> > *Cc:* cho...@chopps.org ;
> > draft-ietf-lsr-isis-srv6-extensi...@ietf.org

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[bruno.decraene]

Hi Xuesong,

Clarification question: are you talking about interoperability (between two 
nodes) or compliancy (between an implementation and the RFC)?
If the former, could you please spell out the interop issue?

Thanks,
Best regards,
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Wednesday, May 12, 2021 9:16 AM
To: Les Ginsberg (ginsberg) ; Shraddha Hegde 
; Alvaro Retana 
; Peter Psenak (ppsenak) ; 
lsr@ietf.org
Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De 
Velde, Gunter (Nokia - BE/Antwerp) 
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

Hi Les,

Prefix Attributes sub-TLV is necessary when locator is leaked.
So we are not against Prefix Attribute sub-TLV implementation. We just propose 
to keep it optional ("should" rather than "must") for interoperability.

Best
Xuesong

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, May 12, 2021 6:29 AM
To: Shraddha Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>;
 Alvaro Retana mailto:aretana.i...@gmail.com>>; Peter 
Psenak (ppsenak) mailto:ppse...@cisco.com>>; 
lsr@ietf.org; Gengxuesong (Geng Xuesong) 
mailto:gengxues...@huawei.com>>
Cc: cho...@chopps.org; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
 Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: RE: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

Shraddha/ Xuesong -

Since Prefix Attributes sub-TLV is required for correct operation when a 
Locator is leaked, would it be safe to assume that your implementations either 
do not leak Locators or you advise your customers not to deploy this feature 
with multiple levels?

The problem with allowing the sub-TLV to be optional is that if the sub-TLV is 
omitted you cannot tell whether the Locator has been leaked - so you don't know 
whether you have a problem or not.

The safest thing to do is require prefix-attributes sub-TLV always - then you 
can guarantee that if the prefix is leaked the necessary information will be 
present.
Anything else leaves us vulnerable.

We all appreciate interoperability considerations, but frankly this is a gap 
that needs to be closed to support correct operation.

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Shraddha Hegde
Sent: Tuesday, May 11, 2021 8:21 AM
To: Alvaro Retana mailto:aretana.i...@gmail.com>>; 
Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; 
lsr@ietf.org
Cc: cho...@chopps.org; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
 Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

Juniper has an  implementation of SRv6 that does not support Prefix attributes 
sub-tlv in locator TLV.
We would prefer not to change the optional sub-TLV to MUST.

Rgds
Shraddha




Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Alvaro Retana
Sent: Friday, May 7, 2021 7:23 PM
To: Peter Psenak mailto:ppse...@cisco.com>>; 
lsr@ietf.org
Cc: cho...@chopps.org; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
 Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

[External Email. Be cautious of content]

On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote:

> Technically I agree with you and if everybody agrees, I'm fine to
> enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

So...what does everyone else think?

We need to close on this point before the IESG evaluates the document.  I'm 
requesting it to be put on the May/20 telechat, which means that we should have 
a resolution and updated draft by the end of next week.


Thanks!

Alvaro.



On May 3, 2021 at 5:17:58 AM, Peter Psenak 
(ppse...@cisco.com) wrote:
Hi Gunter,

Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV.
The problem you describe is not specific to Locator TLV, same applies to
regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix
Attribute Flags TLV is not included, one can not tell whether the prefix
has been propagated (L1->L2) or generated as a result of the local
interface attached on the originator. Same applies to redistribution and
R-flag for IPv4 prefix TLVs.

SRv6 Locator TLV has been defined a while back and the Prefix Attribute
Flags Sub-TLV has always been an optional 

Re: [Lsr] When is an IANA Registry Required

[bruno.decraene]

+1
The information needs to be tracked and consolidated. Seems better done by a 
single person than by many persons duplicating the work, not to mention by zero 
person (surely someone else is doing the job).
This may be less important in LSR though, as we have designated experts which 
may already do this work. However:
-IINM, the designated expert is only appointed when there is a registry.
-IMHO there would be value in having the tracking data been public. IANA looks 
good to me. In theory, github may also work.

That also assumes that code point/flags be tracked -hence allocated- soon 
enough, rather than been hidden in a draft or specific implementation.

Thanks,
--Bruno

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, March 18, 2021 6:15 PM
To: Les Ginsberg (ginsberg) ; Tony Li 
Cc: Alvaro Retana ; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr@ietf.org; John Scudder 
; Christian Hopps ; lsr-cha...@ietf.org
Subject: Re: [Lsr] When is an IANA Registry Required

Speaking as WG member:

Hi Les,
My opinion is there is no harm and some advantage in having IANA registries for 
unique IGP protocol bit flag fields. For the existing fields that don’t have 
registries, there is no burning requirement to go back and define an IANA 
registry until such time as that flag field is extended.

Note that for OSPF, we did add these registries in 
https://www.rfc-editor.org/rfc/rfc4940.txt (thanks to Kireeti).
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Thursday, March 18, 2021 at 12:44 PM
To: Tony Li mailto:tony...@tony.li>>
Cc: Alvaro Retana mailto:aretana.i...@gmail.com>>, 
"draft-ietf-lsr-isis-srv6-extensi...@ietf.org"
 
mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>>,
 "lsr@ietf.org" mailto:lsr@ietf.org>>, John 
Scudder mailto:j...@juniper.net>>, Christian Hopps 
mailto:cho...@chopps.org>>, 
"lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] When is an IANA Registry Required
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Resent-Date: Thursday, March 18, 2021 at 12:44 PM

Tony –

In this context I don’t find the use of a registry of value. The primary issue 
for me for these fields is not managing the bit assignments but understanding 
the functionality – and for that I need to look at the document(s) which have 
that definition. A registry in these cases provides little value and adds 
process and a possibility for inconsistency.

But, I am not expecting that there is anything I can say to change your opinion 
– nor vice versa. So I appreciate that you have made your POV clear and the 
reasons for it – and I am not trying to change your opinion.

I started this thread because I did not think a change in WG policy should be 
made solely based on a single document review comment from one individual – 
even one as highly respected as Alvaro.
Thus far we have a handful of opinions – I am hoping more members of the WG 
will respond to the thread and then we can proceed appropriately.

   Les

From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Thursday, March 18, 2021 8:24 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Alvaro Retana mailto:aretana.i...@gmail.com>>; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org;
 lsr@ietf.org; John Scudder 
mailto:j...@juniper.net>>; Christian Hopps 
mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] When is an IANA Registry Required


Les,



IMO, there is no need for registries for the first category. The WG has been 
alive for over 20 years, defined many new TLVs with flags fields, and I am not 
aware of any confusion – so if it ain’t broke don’t fix it.


With all due respect Les, you appear to operate with an eidetic memory of all 
things IS-IS, so I think that you discount the confusion that the rest of us 
live in.

If a field has values defined in two documents, then there’s confusion. Even 
just finding both is a challenge.

Regards,
Tony



_

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 

Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

[bruno.decraene]

Hi Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, March 12, 2021 3:13 PM
> 
> Hi Bruno,
> 
> please see inline:
> 
> On 12/03/2021 11:39, bruno.decra...@orange.com wrote:
> > Peter, Alvaro
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Thursday, March 11, 2021 11:47 AM
> >
> > [...]
> >
> >>> ...
> >>> 221   4.3.  Maximum H.Encaps MSD Type
> >>>
> >>> 223  The Maximum H.Encaps MSD Type specifies the maximum
> number
> >> of SIDs
> >>> 224  that can be included as part of the "H.Encaps" behavior as
> defined
> >> in
> >>> 225  [I-D.ietf-spring-srv6-network-programming].
> >>>
> >>> [nit] s/included/pushed   That is the terminology used in rfc8986.
> >>
> >> ##PP
> >> fixed.
> >>
> >>>
> >>>
> >>> ...
> >>> 229     If the advertised value is zero or no value is advertised
> >>> 230     then the router can apply H.Encaps only by encapsulating
> >>> 231     the incoming packet in another IPv6 header without SRH
> >>> 232     the same way IPinIP encapsulation is performed.
> >>>
> >>> 234     If the advertised value is non-zero then the router
> supports both
> >>> 235     IPinIP and SRH encapsulation subject to the SID limitation
> >>> 236     specified by the advertised value.
> >>>
> >>> [major] rfc8986 doesn't talk about IPinIP encapsulation, but is does say
> this:
> >>>
> >>>      The push of the SRH MAY be omitted when the SRv6 Policy only
> contains
> >>>      one segment and there is no need to use any flag, tag or TLV.
> >>>
> >>> Suggestion (to replace the last two paragraphs)>
> >>>       If the advertised value is zero or no value is advertised then the
> >>>       headend can apply an SR Policy that only contains one segment, by
> >>>       omitting the SRH push.
> >>>
> >>>       A non-zero SRH Max H.encaps MSD indicates that the headend can
> push
> >>>       an SRH up to the advertised value.
> >>
> >> ##PP
> >> done, but used "insert" instead of "push".
> >
> > In SRv6, "Insert" has been used with a different meaning (SRH insertion
> without IP encapsulation) and hence is very connoted. So I would prefer if
> we could avoid the term "insert", to avoid both misunderstanding and
> ambiguities.
> >
> > I'm not sure how many/which  :s/push/insert  you are referring to as I'm
> seen 3  "push". I'll assume you meant the 3 of them. I would suggest the
> following change, but any other formulation would probably work for me.
> >
> > OLD: The push of the SRH MAY be omitted
> > NEW: The SRH MAY be omitted
> >
> > OLD: by omitting the SRH push.
> > NEW by omitting the SRH.
> >
> > OLD: the headend can push an SRH up to the advertised value.
> > NEW: the headend can perform IP encapsulation with an SRH containing up
> to MSD SIDs.
> > (or may be: up to this number of SIDs)
> 
> not sure which document/version do you look at, but I don't see any
> occurrence of "push" or "insert" in the latest published version (11).

I'm referring to the email (above) that you sent yesterday on the LSR mailing 
list in which you said " ##PP done, but used "insert" instead of "push"."
It's not reflected in the latest published version which date from October 8, 
2020

 > The single "push" I added as a response to Alvaro's comment was at:
> 
> 
> The Maximum H.Encaps MSD Type signals the maximum number of SIDs
> that can be pushed as part of the "H.Encaps" behavior as defined in
> [RFC8986]"
> 
> Please let me know how do you prefer that to be modified.
> 
> 
> >
> >
> > [...]
> >
> >
> >> 245  SRH Max End D Type: 45
> >>
> >> 247  If the advertised value is zero or no value is advertised
> >> 248  then it is assumed that the router cannot apply
> >> 249  "End.DX6" or "End.DT6" behaviors if the outer IPv6 header
> >> 250  contains an SRH.
> >
> > Since I've started, I'll continue to nick pick.
> >
> > "assume" does not seem like the right term when talking about an explicit
> signalling.
> > I would suggest
> > OLD: then it is assumed that the router cannot apply
> > NEW: then the router cannot apply
> 
> fixed them all.

Thanks,
--Bruno

 
> Peter
> >
> >
> > *3 (in §4.1, §4.2, §4.4)
> >
> >
> > Thank you,
> > --Bruno
> >
> >
> __
> __
> _
> >
> > 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 

Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

[bruno.decraene]

Peter, Alvaro

> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, March 11, 2021 11:47 AM

[...]

> > ...
> > 221 4.3.  Maximum H.Encaps MSD Type
> >
> > 223    The Maximum H.Encaps MSD Type specifies the maximum number
> of SIDs
> > 224    that can be included as part of the "H.Encaps" behavior as defined
> in
> > 225    [I-D.ietf-spring-srv6-network-programming].
> >
> > [nit] s/included/pushed   That is the terminology used in rfc8986.
> 
> ##PP
> fixed.
> 
> >
> >
> > ...
> > 229       If the advertised value is zero or no value is advertised
> > 230       then the router can apply H.Encaps only by encapsulating
> > 231       the incoming packet in another IPv6 header without SRH
> > 232       the same way IPinIP encapsulation is performed.
> >
> > 234       If the advertised value is non-zero then the router supports both
> > 235       IPinIP and SRH encapsulation subject to the SID limitation
> > 236       specified by the advertised value.
> >
> > [major] rfc8986 doesn't talk about IPinIP encapsulation, but is does say 
> > this:
> >
> >     The push of the SRH MAY be omitted when the SRv6 Policy only contains
> >     one segment and there is no need to use any flag, tag or TLV.
> >
> > Suggestion (to replace the last two paragraphs)>
> >      If the advertised value is zero or no value is advertised then the
> >      headend can apply an SR Policy that only contains one segment, by
> >      omitting the SRH push.
> >
> >      A non-zero SRH Max H.encaps MSD indicates that the headend can push
> >      an SRH up to the advertised value.
> 
> ##PP
> done, but used "insert" instead of "push".

In SRv6, "Insert" has been used with a different meaning (SRH insertion without 
IP encapsulation) and hence is very connoted. So I would prefer if we could 
avoid the term "insert", to avoid both misunderstanding and ambiguities. 

I'm not sure how many/which  :s/push/insert  you are referring to as I'm seen 3 
 "push". I'll assume you meant the 3 of them. I would suggest the following 
change, but any other formulation would probably work for me.

OLD: The push of the SRH MAY be omitted
NEW: The SRH MAY be omitted

OLD: by omitting the SRH push.
NEW by omitting the SRH.

OLD: the headend can push an SRH up to the advertised value.
NEW: the headend can perform IP encapsulation with an SRH containing up to MSD 
SIDs.
(or may be: up to this number of SIDs)



[...]


> 245 SRH Max End D Type: 45
> 
> 247 If the advertised value is zero or no value is advertised
> 248 then it is assumed that the router cannot apply
> 249 "End.DX6" or "End.DT6" behaviors if the outer IPv6 header
> 250 contains an SRH.

Since I've started, I'll continue to nick pick.

"assume" does not seem like the right term when talking about an explicit 
signalling.
I would suggest
OLD: then it is assumed that the router cannot apply
NEW: then the router cannot apply


*3 (in §4.1, §4.2, §4.4)


Thank you,
--Bruno

_

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

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[bruno.decraene]

Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Bruno,
> 
> please see inline:
> 
> 
> 
> On 20/10/2020 11:43, bruno.decra...@orange.com wrote:
> > Peter,
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>
> >> Bruno,
> >>
> >> On 19/10/2020 18:52, bruno.decra...@orange.com wrote:
> >>> Ron, all,
> >>>
> >>> >From a use case standpoint, I have a use case for having both SR-MPLS
> and
> >> IP flexalgo in the same network.
> >>>
> >>> >From a protocol standpoint, I think that the functionality could be
> equally
> >> met by advertising SR-MPLS SID as per RFC 8667 but using a label 3
> (implicit
> >> null) to instruct the LER/LSR to not use a label in the forwarding plane.
> (while
> >> still advertising a label in the control plane because we have to).
> >>
> >> does not work,
> >
> > I could provide more explanations, but reading your email, it seems to me
> that you understood the proposal.
> > So it seems to me that the opinion that you really meant is: it works but it
> would be an nasty hack.
> >
> > Regarding "nasty hack" it could be interesting to have a normative
> definition. This could prove useful in some other contexts.
> > BTW, is "max metric" a hack (vs creating a new tlv if you don't want the 
> > link
> in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the 
> label
> in the NLRI...
> 
> max-metric does not solve the problem, as you would need a prefix metric
> for non 0 algo anyway.

To clarify, my text was not a technical proposal related to that draft. It was 
referring to your email and questioning what exactly was a hack using some 
examples from the past.
But let's forget about this point, at least for the moment.

> > Coming back to technical comments, note that creating yet another TLV to
> carry IP prefix also brings questions that the draft does not answer or even
> raise.
> > - What about the sub-TLVs? Are they shared with the existing registry for
> prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier
> (we would have two algo fields, two ways to signal SIDs...)
> 
> yes, these are details that needs to be addressed, but should not be a
> problem. Look at locator TLV in SRv6, very similar concept here.
> 
> > - for IPv6, the content and meaning of  "ISIS MT IPv6 Flexalgo Prefix
> Reachability TLV" is essentially the same than the "SRv6 Locator TLV".
> > - Only the naming and the ordering of the fields are different.
> > - Why do we need two TLVs to advertise the same thing (essentially a
> Routing Algo)? Duplication means more spec, more code, more features to
> implement, more error and bugs. (and it did not took long: the draft defines
> the MTID field as 8 bits while RFC 5120 defines it a 12 bits.
> 
> well, locator is a construct that is specific to SRv6. Sure you can
> advertise the prefix in a locator TLV without any SRv6 specific Sub-TLVs
> and achieve the same thing - I have already mentioned that in one of my
> responses, but that is again ugly.

So we agree that reusing the SRv6 locator TLV would work and provide the 
functionality. Good.
Now here comes again the "ugly" argument. If it's now becoming a technical 
argument, in my opinion, it's ugly to define two TLVs in order to advertise the 
same information and to provide the same functionality.

 
> > - What is the functional different between FlexAlgo for SRv6 and
> FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and
> the IPv6 FIB in the router.
> 
> they are functionally the same.

Good to agree on this.
 
> I believe that having a clean encoding is preferable in a long run.

What do you mean by "clean encoding"? The only differences between both TLVs 
are the naming and the ordering of the fields.

> One
> can not advertise a prefix as SRv6 locator as well as IP flex-algo
> prefix (that would be an error), so duplication of data is not an
> issues.

So one should not advertise both TLVs? If so this becomes an error/issue? This 
feels like my point. There is no such issue with a single TLV.

> And having a dedicated TLV for each is better from both
> deployment and implementation perspective.

I can't see how implementing the same functionality twice would be better from 
an implementation perspective, but I leave this to you. I would suspect that 
you may consider only implementing one, not both.
I disagree on the deployment perspective. We would have two TLVs to advertise 
the same information and provide the exactly same functionality.  I can only 
see that this would bring deployment issues. e.g. one vendor implementing TLV A 
while another vendor implementing TLV B; hence no interoperability or a large 
delay to have both vendors implement both TLVs (or at least one vendor 
implementing both, presumably the smaller vendor).

Thanks,
--Bruno
 
> thanks,
> Peter
> 
> 
> 
> 
> >
> > Thanks,
> > Bruno
> >
> >> as it does not allow you to associate the prefix with
> >> Flex-algo without advertising the 

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[bruno.decraene]

Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Bruno,
> 
> On 19/10/2020 18:52, bruno.decra...@orange.com wrote:
> > Ron, all,
> >
> >>From a use case standpoint, I have a use case for having both SR-MPLS and
> IP flexalgo in the same network.
> >
> >>From a protocol standpoint, I think that the functionality could be equally
> met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit
> null) to instruct the LER/LSR to not use a label in the forwarding plane. 
> (while
> still advertising a label in the control plane because we have to).
> 
> does not work,

I could provide more explanations, but reading your email, it seems to me that 
you understood the proposal.
So it seems to me that the opinion that you really meant is: it works but it 
would be an nasty hack.

Regarding "nasty hack" it could be interesting to have a normative definition. 
This could prove useful in some other contexts. 
BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link 
in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the 
label in the NLRI...


Coming back to technical comments, note that creating yet another TLV to carry 
IP prefix also brings questions that the draft does not answer or even raise.
- What about the sub-TLVs? Are they shared with the existing registry for 
prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier 
(we would have two algo fields, two ways to signal SIDs...)
- for IPv6, the content and meaning of  "ISIS MT IPv6 Flexalgo Prefix 
Reachability TLV" is essentially the same than the "SRv6 Locator TLV".
- Only the naming and the ordering of the fields are different.
- Why do we need two TLVs to advertise the same thing (essentially a 
Routing Algo)? Duplication means more spec, more code, more features to 
implement, more error and bugs. (and it did not took long: the draft defines 
the MTID field as 8 bits while RFC 5120 defines it a 12 bits.
- What is the functional different between FlexAlgo for SRv6 and 
FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and the 
IPv6 FIB in the router.

Thanks,
Bruno

> as it does not allow you to associate the prefix with
> Flex-algo without advertising the reachability in algo 0. Making the
> prefix reachability in default algo conditional based on the presence of
> the Prefix SID Sub-TLV with Imnplicit Null would be a nasty hack.
> 
> Not to mention that advertising a Prefix SID in pure IP network would be
> ugly.
> 
> thanks,
> Peter
> 
> 
> 
> > I feel that this would be less change in the protocol (no new tlv), a good 
> > fit
> for network requiring both MPLS and IP flex algo, and would not require
> implementations/network operator to duplicate the "prefix sub-TLV" [1] on
> both advertisements (IP based and SR-MPLS based).
> >
> > That would still requires a protocol extension/STD track RFC as RFC 8667
> does not allow for this. That would still require change to implementations as
> only the signalling is different while the feature/behavior is the same (i.e. 
> no
> magic).
> >
> > Regards,
> > --Bruno
> >
> > [1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability,
> MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"
> >
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> >> Sent: Tuesday, September 29, 2020 3:38 PM
> >> To: lsr@ietf.org
> >> Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-
> flexalgo-
> >> 00.txt
> >>
> >>
> >> Please review and comment
> >>
> >> Ron
> >>
> >>
> >>
> >> Juniper Business Use Only
> >>
> >>> -Original Message-
> >>> From: internet-dra...@ietf.org 
> >>> Sent: Tuesday, September 29, 2020 9:36 AM
> >>> To: Parag Kaneriya ; Shraddha Hegde
> >>> ; Ron Bonica ; Rajesh M
> >>> ; William Britto A J 
> >>> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
> >>>
> >>> [External Email. Be cautious of content]
> >>>
> >>>
> >>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
> >>> has been successfully submitted by Ron Bonica and posted to the IETF
> >>> repository.
> >>>
> >>> Name:   draft-bonica-lsr-ip-flexalgo
> >>> Revision:   00
> >>> Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
> >>> Document date:  2020-09-29
> >>> Group:  Individual Submission
> >>> Pages:  14
> >>> URL:https://urldefense.com/v3/__https://www.ietf.org/id/draft-
> >> bonica-
> >>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> >>> Status:
> >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
> >> bonica-lsr-
> >>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> >>> Htmlized:
> >>>
> 

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[bruno.decraene]

Ron, all,

>From a use case standpoint, I have a use case for having both SR-MPLS and IP 
>flexalgo in the same network.

>From a protocol standpoint, I think that the functionality could be equally 
>met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit 
>null) to instruct the LER/LSR to not use a label in the forwarding plane. 
>(while still advertising a label in the control plane because we have to).
I feel that this would be less change in the protocol (no new tlv), a good fit 
for network requiring both MPLS and IP flex algo, and would not require 
implementations/network operator to duplicate the "prefix sub-TLV" [1] on both 
advertisements (IP based and SR-MPLS based).

That would still requires a protocol extension/STD track RFC as RFC 8667 does 
not allow for this. That would still require change to implementations as only 
the signalling is different while the feature/behavior is the same (i.e. no 
magic).

Regards,
--Bruno

[1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT 
IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"


> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> Sent: Tuesday, September 29, 2020 3:38 PM
> To: lsr@ietf.org
> Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-
> 00.txt
> 
> 
> Please review and comment
> 
>Ron
> 
> 
> 
> Juniper Business Use Only
> 
> > -Original Message-
> > From: internet-dra...@ietf.org 
> > Sent: Tuesday, September 29, 2020 9:36 AM
> > To: Parag Kaneriya ; Shraddha Hegde
> > ; Ron Bonica ; Rajesh M
> > ; William Britto A J 
> > Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
> >
> > [External Email. Be cautious of content]
> >
> >
> > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
> > has been successfully submitted by Ron Bonica and posted to the IETF
> > repository.
> >
> > Name:   draft-bonica-lsr-ip-flexalgo
> > Revision:   00
> > Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
> > Document date:  2020-09-29
> > Group:  Individual Submission
> > Pages:  14
> > URL:https://urldefense.com/v3/__https://www.ietf.org/id/draft-
> bonica-
> > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> > Status:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
> bonica-lsr-
> > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> > Htmlized:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
> > Htmlized:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
> > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
> >
> >
> > Abstract:
> >An IGP Flexible Algorithm computes a constraint-based path and maps
> >that path to an identifier.  As currently defined, Flexalgo can only
> >map the paths that it computes to Segment Routing (SR) identifiers.
> >Therefore, Flexalgo cannot be deployed in the absence of SR.
> >
> >This document extends Flexalgo, so that it can map the paths that it
> >computes to IP addresses.  This allows Flexalgo to be deployed in any
> >IP network, even in the absence of SR.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

_

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

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Hi Bruno,
> 
> please see inline:
> 
> On 07/09/2020 17:31, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >> Sent: Thursday, September 3, 2020 9:55 AM
> >>
> >> Hi Shraddha,
> >>
> >> On 03/09/2020 05:39, Shraddha Hegde wrote:
> >>> Peter,
> >>>
> >>> In order to make the document clearer on this point, I would like the
> text
> >> below to be added
> >>> to section 11 to make it explicit that setting the L-bit is valid for 
> >>> flex-algo
> for
> >> ISIS.
> >>>
> >>> =
> >>> Section 11.
> >>>
> >>> “The ASLA TLV in ISIS supports the L-Bit as described in section 4.2 of
> >>> [draft-ietf-isis-te-app]. When the L-bit is set, applications MUST use
> >>> legacy advertisements for that link. Flex algorithm application MUST
> >> support
> >>> sending and receiving link attributes with ASLA TLV having L-bit set.
> >>
> >>
> >> I can add the above,
> >
> > Yes please. (It's not clear to me whether "can add" means "will add" or
> "could add". So better safe than sorry).
> >
> > Also in §5.1:
> >
> > " 1: Min Unidirectional Link Delay as defined in [RFC8570],
> >   section 4.2, encoded in the Application Specific Link
> >   Attributes Sub-TLV [I-D.ietf-isis-te-app]."
> >
> > It could be read as the delay (value) needs to be encoded in the ASLA
> Attributes Sub-TLV, while when the L-bit is set, the delay (value) is encoded
> in the RFC8570 sub-TLV.
> > So in order to avoid interop issues, I'd appreciate if you could clarify.
> > May be :s/in/as per
> > Or :s/./or in the RFC8570 Sub-TLV when the ASLA L-Flag is set.
> > Or whatever change at your preference.
> 
> 
> what about:
> 
> "Min Unidirectional Link Delay as defined in [RFC8570],
>   section 4.2, encoded as specified in [I-D.ietf-isis-te-app]."
> 
> That covers the L-bit with delay in legacy TLV.

Looks good.

Thank you.

--Bruno

> >
> > Then same comment for Metric-Type 2 (TE Metric), in the next sentence.
> 
> sure.
> 
> thanks,
> Peter
> 
> >
> >
> > Thank you,
> > Regards,
> > --Bruno
> >
> >
> >> although, it's clear from the
> >> draft-ietf-isis-te-app that L-bit with legacy advertisement MAY be used
> >> for any app.
> >>
> >>>
> >>> Note that earlier versions of this document did not mandate use of ASLA
> >> TLVs
> >>> and hence may not inter-operate with early implementations that use
> >> legacy advertisements."
> >>
> >> it is not true that "earlier versions of this document" did not mandate
> >> ASLA.
> >>
> >> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00, which only
> >> supported the include/exclude Admin Groups, clearly stated:
> >>
> >>
> >> 9.  Advertisement of Link Attributes for Flex-Algorithm
> >>
> >>  Various link include or exclude rules can be part of the Flex-
> >>  Algorithm definition.  These rules use Admin Groups (AG) as defined
> >>  in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG)
> >>  as defined in [RFC7308].
> >>
> >>  To advertise a link affinity in a form of the AG or EAG that is used
> >>  during Flex-Algorithm calculation, an Application Specific Link
> >>  Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV
> >>  of Extended Link TLV as described in
> >>  [I-D.ietf-ospf-te-link-attr-reuse] MUST be used.  The advertisement
> >>  MUST indicate that it is usable by the Flex-Algorithm application.
> >>
> >>
> >> thanks,
> >> Peter
> >>
> >>
> >>
> >>> 
> >>>
> >>>
> >>> Rgds
> >>> Shraddha
> >>>
> >>>
> >>> Juniper Business Use Only
> >>>
> >>> -Original Message-
> >>> From: Peter Psenak 
> >>> Sent: Wednesday, September 2, 2020 2:43 PM
> >>> To: Shraddha Hegde ;
> >> olivier.dug...@orange.com; tony...@tony.li; Robert Raszuk
> >> 
> >>> Cc: Christian Hopps ; draft-ietf-lsr-flex-
> >> algo@ietf.org; Les Ginsberg (ginsberg)
> >> ; lsr@ietf.org; lsr-...@ietf.org;
> >> Acee Lindem (acee) 
> >>> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
> >>>
> >>> [External Email. Be cautious of content]
> >>>
> >>>
> >>> Hi Shraddha,
> >>>
> >>> please see inline:
> >>>
> >>>
> >>> On 02/09/2020 06:45, Shraddha Hegde wrote:
>  Peter,
> 
>  It is worthwhile to note the history of the flex-algo draft and the
>  te-app draft and how many  backward incompatible changes have been
>  introduced in the course of the flex-algo draft.
> 
>  The original drafts of flex-algo did not mention the te-app draft and
>  was completely based on legacy advertisements.
>  Two years ago, after the working group adopted the original drafts
>  without the ASLA TLV, the text was changed to require the ASLA TLV.
> >>>
> >>> draft-ietf-lsr-flex-algo-00, which was the initial version of the WG
> >> document already mandated the ASLA usage. I don't believe we have to
> go
> >> back to the individual drafts that predated the WG 

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi Peter,

> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Thursday, September 3, 2020 9:55 AM
> 
> Hi Shraddha,
> 
> On 03/09/2020 05:39, Shraddha Hegde wrote:
> > Peter,
> >
> > In order to make the document clearer on this point, I would like the text
> below to be added
> > to section 11 to make it explicit that setting the L-bit is valid for 
> > flex-algo for
> ISIS.
> >
> > =
> > Section 11.
> >
> > “The ASLA TLV in ISIS supports the L-Bit as described in section 4.2 of
> > [draft-ietf-isis-te-app]. When the L-bit is set, applications MUST use
> > legacy advertisements for that link. Flex algorithm application MUST
> support
> > sending and receiving link attributes with ASLA TLV having L-bit set.
> 
> 
> I can add the above, 

Yes please. (It's not clear to me whether "can add" means "will add" or "could 
add". So better safe than sorry).

Also in §5.1:

" 1: Min Unidirectional Link Delay as defined in [RFC8570],
 section 4.2, encoded in the Application Specific Link
 Attributes Sub-TLV [I-D.ietf-isis-te-app]."

It could be read as the delay (value) needs to be encoded in the ASLA 
Attributes Sub-TLV, while when the L-bit is set, the delay (value) is encoded 
in the RFC8570 sub-TLV.
So in order to avoid interop issues, I'd appreciate if you could clarify.
May be :s/in/as per
Or :s/./or in the RFC8570 Sub-TLV when the ASLA L-Flag is set.
Or whatever change at your preference. 

Then same comment for Metric-Type 2 (TE Metric), in the next sentence.


Thank you,
Regards,
--Bruno


> although, it's clear from the
> draft-ietf-isis-te-app that L-bit with legacy advertisement MAY be used
> for any app.
> 
> >
> > Note that earlier versions of this document did not mandate use of ASLA
> TLVs
> > and hence may not inter-operate with early implementations that use
> legacy advertisements."
> 
> it is not true that "earlier versions of this document" did not mandate
> ASLA.
> 
> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00, which only
> supported the include/exclude Admin Groups, clearly stated:
> 
> 
> 9.  Advertisement of Link Attributes for Flex-Algorithm
> 
> Various link include or exclude rules can be part of the Flex-
> Algorithm definition.  These rules use Admin Groups (AG) as defined
> in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG)
> as defined in [RFC7308].
> 
> To advertise a link affinity in a form of the AG or EAG that is used
> during Flex-Algorithm calculation, an Application Specific Link
> Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV
> of Extended Link TLV as described in
> [I-D.ietf-ospf-te-link-attr-reuse] MUST be used.  The advertisement
> MUST indicate that it is usable by the Flex-Algorithm application.
> 
> 
> thanks,
> Peter
> 
> 
> 
> > 
> >
> >
> > Rgds
> > Shraddha
> >
> >
> > Juniper Business Use Only
> >
> > -Original Message-
> > From: Peter Psenak 
> > Sent: Wednesday, September 2, 2020 2:43 PM
> > To: Shraddha Hegde ;
> olivier.dug...@orange.com; tony...@tony.li; Robert Raszuk
> 
> > Cc: Christian Hopps ; draft-ietf-lsr-flex-
> algo@ietf.org; Les Ginsberg (ginsberg)
> ; lsr@ietf.org; lsr-...@ietf.org;
> Acee Lindem (acee) 
> > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi Shraddha,
> >
> > please see inline:
> >
> >
> > On 02/09/2020 06:45, Shraddha Hegde wrote:
> >> Peter,
> >>
> >> It is worthwhile to note the history of the flex-algo draft and the
> >> te-app draft and how many  backward incompatible changes have been
> >> introduced in the course of the flex-algo draft.
> >>
> >> The original drafts of flex-algo did not mention the te-app draft and
> >> was completely based on legacy advertisements.
> >> Two years ago, after the working group adopted the original drafts
> >> without the ASLA TLV, the text was changed to require the ASLA TLV.
> >
> > draft-ietf-lsr-flex-algo-00, which was the initial version of the WG
> document already mandated the ASLA usage. I don't believe we have to go
> back to the individual drafts that predated the WG version.
> >
> >>
> >>
> >> ASLA TLV had the L-Bit and it was always valid to advertise link
> >> attributes for flex-algo with L-bit set which means the link
> >> attributes could still be sent in legacy TLVs.
> >> In a conversation last year, you had agreed that advertising link
> >> attributes with L-bit set is valid for Flex-algo.
> >
> >
> > what we say in flex-algo draft in section 11 is:
> >
> >  "Link attribute advertisements that are to be used during Flex-
> >  Algorithm calculation MUST use the Application-Specific Link
> >  Attribute (ASLA) advertisements defined in [I-D.ietf-isis-te-app] or
> >  [I-D.ietf-ospf-te-link-attr-reuse]."
> >
> > ietf-isis-te-app clearly allows the app specific value of the attribute to 
> > be
> advertised in legacy 

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[bruno.decraene]

Hi Tony,

Thanks for your reply.
At this point, area proxy spec is clear with regards to nominal behavior. So 
indeed we are discussing error handling / transitions. (and thank you for 
considering those cases, much appreciated).

From memory, my understanding is the area proxy nominal behaviour requires:

-  All routers in the area are L1 & L2

-  All inside routers advertise the area proxy TLV

-  An area leader advertises the Area Proxy System Identifier Sub-TLV

If the above is not fulfilled, what is the expected behaviour? There is a 
priori 2 options:

-  A) Return to regular IS-IS behaviour. i.e. all L2 LSPs from inside 
routers are flooded to L2 outside routers

o   Pro: no new behaviour/code as this is regular IS-IS. Correct transit 
forwarding across the area.

o   Con: suddenly increase size of L2 LSDB

-  B) Keep filtering L2 LSP from inside routers

o   Pro: no sudden increase of L2 LSDB size

o   Con: transit traffic is partially dropped (if area LSP advertised while 
some routers are L1 only), no transit is possible (if area LSP is not 
advertised), or partial transit (some inside edge node do not advertise the 
area proxy TLV).

§  Lack of transit is not an issue if there is a backup proxy area (e.g. a 
proxy area a replace a big single chassis).  It’s likely an issue is there is 
no backup proxy area (e.g. the area has built-in redundancy (e.g. spife/leaf) 
hence there is no need for another/backup proxy area. Network operator needs to 
be well aware in order to choose the correct design (rather than experience a 
bad surprise)

That’s an open question.
As this point I do not have a preference, although naively I had “A” in mind. 
From your below answer, I think that you have “B” in mind.
A priori the choice may be dependent on the missing condition.
Possibly this could be clarified in a “operational consideration” or “error 
handling” section for network operator to be aware of the behaviour under 
failure/transition condition.
FYI, I’m considering such failure to be plausible over the years as all it need 
is one L1 router to boot and not advertise the area proxy TLV or be configured 
as L1 only.

Regards,
--Bruno
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Saturday, September 5, 2020 2:43 AM
To: DECRAENE Bruno TGI/OLN 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi Bruno,



“A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an 
Outside Router. »
Agreed (so far)

“A Level 2 LSP with a source system identifier that is found in the Level 1 
LSDB MUST NOT be flooded to an Outside Router.”
I’m not sure to agree.
If that LSP carries the Area Proxy TLV, the previous rule is enough.
If that LSP does not carry the Area Proxy TLV, then no Area Leader advertise 
the Area Proxy System Identifier Sub-TLV and hence the new Area Proxy is not 
enabled. In which case I feel that normal IS-IS flooding should occur, and 
L1-L2 nodes should have their L2 LSP flooded.
So, I would propose to remove that sentence which doesn’t seem needed.


This was intentional. We are trying to protect against a case where a router 
boots and has not yet processed its full configuration yet.  It could easily 
generate an LSP prior to adding the Area Proxy TLV.
This could also happen during the transition to Area Proxy, where an Inside 
Node has not yet been configured for Area Proxy.

We are trying to prevent flooding of its LSP to the Outside Area because that 
may confuse other L2 nodes.


“A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an 
Outside Router. »
I think we additionally need that an Area Leader advertise the Area Proxy 
System Identifier Sub-TLV.


We already say:

  The Area Leader has several responsibilities.  First, it MUST
   inject the Area Proxy System Identifier into the Level 2
   LSDB.



Otherwise, hence the new Area Proxy is not enabled. I which case I feel that 
normal IS-IS flooding should occur, and L1-L2 nodes should have their L1 & L2 
LSP flooded.
That condition would seem application to the whole section 5.2 or even to the 
whole section 5



Again, we want to restrict flooding if Area Proxy is configured, even if it’s 
not fully enabled.  Again, we’re just trying to make the transition as smooth 
as possible.


Tony



_

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 

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[bruno.decraene]

Hi Tony,

Thanks for your reply.
All good to me.

Thanks,
--Bruno


From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Saturday, September 5, 2020 2:18 AM
To: DECRAENE Bruno TGI/OLN 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi Bruno,

Thank you for your comments.

1)

OLD: The
   advertisement in the Proxy LSP informs the remainder of the network
   that packets directed to the SID will be forwarded by one of the
   Inside Edge Nodes and the Area SID will be consumed.

NEW:

The

   advertisement in the Proxy LSP informs the outside area

   that packets directed to the SID will be forwarded to one of the

   Inside Edge Nodes and the Area SID will be consumed.

Motivation:
1)  More precise/descriptive and use the terminology defined in the draft
2)  The SID is a priori global in the outside area and hence will be 
forwarded by all nodes in the outside area (and not just by the Inside Edge 
Nodes). The destination is anycast to/toward any Inside Edge node.


Ok.



2)
§ 4.3.2.  The Area SID Sub-TLV

The Area SID Sub-TLV allows the Area Leader to advertise a prefix and

   SID



§4.4.13.  The Area SID

  The Area Leader SHOULD advertise the Area SID information in the

   Proxy LSP as a Node SID as defined in [RFC8667] Section 
2.1.


RFC8667 requires that for a Node SID, the prefix be an IP address (/32 or /138) 
(rather than an IP prefix of an arbitrary length) [1].
[1] https://tools.ietf.org/html/rfc8667#section-2.1.1.2

You may want to refer to this restriction when defining the Area SID Sub-TLV in 
section 4.3.2 . e.g. :s/advertise a prefix/advertise an IP address. 
Alternatively open the option to advertise a prefix SID without the N-Flag if 
this is a prefix.


We are implicitly doing that by permitting a prefix.



3)
1 typo in -04 :s/ Inisde/ Inside


Fixed, thanks.



4)
OLD:
The Area Leader will generate a Proxy LSP that must be flooded across
   the Inside Area.  Inside Routers MUST ignore the contents of the
   Proxy LSP other than for flooding

My personal preference would be
NEW
The Area Leader will generate a Proxy LSP that will be flooded across
   the Inside Area.  Inside Routers MUST ignore the contents of LSP(s) 
originated with the Area Proxy System Identifier other than for flooding.

Motivation:
a)  Clarify that no new behavior is involved
b)  Specifies how the proxy LSP is to be identified as a proxy LSP.



?  Ignoring the contents of an LSP is a new behavior.  I propose something 
slightly different:

  The Area Leader will generate a Proxy LSP that will be
  flooded across the Inside Area.  Inside Routers MUST ignore
  the contents of the Proxy LSP other than for flooding.  The
  Proxy LSP uses the Area Proxy System Identifier as its Source
  ID.




5) Open question: is the Area Proxy LSP to be advertised/read from L1 or L2 
LSP/LSDB or both?

“All routers within the Inside Area speak Level 1 and Level 2 IS-IS on all of 
the links within the topology.”
OK.

“A node advertises the Area Proxy TLV in its L2 LSP”
So my reading/guessing is that the Area Proxy TLV is only sent in the L2 LSP of 
all Inside routers. (i.e. not in the L1 LSP).
If so:
-  Can you clarify the behavior when an Area Proxy TLV is received in 
an L1 LSP? (e.g. ignore, and if not, what is the behavior when the TLV is 
different in L1 and L2).


We already say:

   The Area Leader MUST advertise the Area Proxy System
   Identifier Sub-TLV when it observes that all Inside Routers
   are advertising the Area Proxy TLV.

The statement that you quote is pretty clear that the Area Proxy TLV is found 
in the L2 LSP.  I take it that you feel that this is insufficient.
I propose to add:

 Nodes MUST NOT advertise the Area Proxy TLV in a L1 LSP. Nodes MUST
  ignore the Area Proxy TLV if it is found in a L1 LSP.



-  “they will advertise the Area Proxy TLV.” May be adding “in their L2 
LSP”


Ok.



-  “All Inside Edge Routers learn the Area Proxy System Identifier from 
the Level 1 LSDB”. I would have assumed  “from the Area Proxy TLV advertised in 
the level 2 LSDB.  So it may be a typo or I’m missing something, which is very 
possible.


That was a bug, thanks.  I changed it to: “ … from the Area Proxy TLV 
advertised by the Area Leader … “



o   “it MUST inject   the Area Proxy System Identifier into the Level 1 LSDB.” 
Same comment.


Also a bug.  Should be L2.  Fixed.


Thanks for the detailed review!


Tony


_

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 

Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[bruno.decraene]

Hi Tony,

I may have a comment on 5.2.  Filtering LSP information.
This is old text, but new re-reading.

"A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an 
Outside Router. >
Agreed (so far)

"A Level 2 LSP with a source system identifier that is found in the Level 1 
LSDB MUST NOT be flooded to an Outside Router."
I'm not sure to agree.
If that LSP carries the Area Proxy TLV, the previous rule is enough.
If that LSP does not carry the Area Proxy TLV, then no Area Leader advertise 
the Area Proxy System Identifier Sub-TLV and hence the new Area Proxy is not 
enabled. In which case I feel that normal IS-IS flooding should occur, and 
L1-L2 nodes should have their L2 LSP flooded.
So, I would propose to remove that sentence which doesn't seem needed.


"A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an 
Outside Router. >
I think we additionally need that an Area Leader advertise the Area Proxy 
System Identifier Sub-TLV. Otherwise, hence the new Area Proxy is not enabled. 
I which case I feel that normal IS-IS flooding should occur, and L1-L2 nodes 
should have their L1 & L2 LSP flooded.
That condition would seem application to the whole section 5.2 or even to the 
whole section 5

Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, September 4, 2020 2:29 PM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Tony,

I've read the diff for -03 and -04.
The new encoding of the Area SID is good for me.

And thank you for listening to my use case and suggestion.

Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
tony...@tony.li
Sent: Monday, August 24, 2020 7:02 PM
To: lsr@ietf.org
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi folks,

This updated draft has been published for a few weeks now.  We would like to 
solicit your opinion on this.  In particular, we have changed the encoding of 
the Area SID.  Do you find this encoding adequate and appropriate?

Thanks,
Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Date: August 5, 2020 at 1:17:39 PM PDT
To: mailto:i-d-annou...@ietf.org>>
Cc: lsr@ietf.org
Reply-To: internet-dra...@ietf.org, 
lsr@ietf.org


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   : Area Proxy for IS-IS
   Authors : Tony Li
 Sarah Chen
 Vivek Ilangovan
 Gyan S. Mishra
Filename: draft-ietf-lsr-isis-area-proxy-03.txt
Pages   : 19
Date: 2020-08-05

Abstract:
  Link state routing protocols have hierarchical abstraction already
  built into them.  However, when lower levels are used for transit,
  they must expose their internal topologies to each other, leading to
  scale issues.

  To avoid this, this document discusses extensions to the IS-IS
  routing protocol that would allow level 1 areas to provide transit,
  yet only inject an abstraction of the level 1 topology into level 2.
  Each level 1 area is represented as a single level 2 node, thereby
  enabling greater scale.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


_



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. 

Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[bruno.decraene]

Hi Tony,

Please find below some nits/minor comments. Please feel free to silently 
discard.

1)

OLD: The
   advertisement in the Proxy LSP informs the remainder of the network
   that packets directed to the SID will be forwarded by one of the
   Inside Edge Nodes and the Area SID will be consumed.

NEW:

The

   advertisement in the Proxy LSP informs the outside area

   that packets directed to the SID will be forwarded to one of the

   Inside Edge Nodes and the Area SID will be consumed.

Motivation:

1)  More precise/descriptive and use the terminology defined in the draft

2)  The SID is a priori global in the outside area and hence will be 
forwarded by all nodes in the outside area (and not just by the Inside Edge 
Nodes). The destination is anycast to/toward any Inside Edge node.


2)
§ 4.3.2.  The Area SID Sub-TLV

The Area SID Sub-TLV allows the Area Leader to advertise a prefix and

   SID



§4.4.13.  The Area SID

  The Area Leader SHOULD advertise the Area SID information in the

   Proxy LSP as a Node SID as defined in [RFC8667] Section 
2.1.


RFC8667 requires that for a Node SID, the prefix be an IP address (/32 or /138) 
(rather than an IP prefix of an arbitrary length) [1].
[1] https://tools.ietf.org/html/rfc8667#section-2.1.1.2

You may want to refer to this restriction when defining the Area SID Sub-TLV in 
section 4.3.2 . e.g. :s/advertise a prefix/advertise an IP address. 
Alternatively open the option to advertise a prefix SID without the N-Flag if 
this is a prefix.


3)
1 typo in -04 :s/ Inisde/ Inside

4)
OLD:
The Area Leader will generate a Proxy LSP that must be flooded across
   the Inside Area.  Inside Routers MUST ignore the contents of the
   Proxy LSP other than for flooding

My personal preference would be
NEW
The Area Leader will generate a Proxy LSP that will be flooded across
   the Inside Area.  Inside Routers MUST ignore the contents of LSP(s) 
originated with the Area Proxy System Identifier other than for flooding.

Motivation:

a)  Clarify that no new behavior is involved

b)  Specifies how the proxy LSP is to be identified as a proxy LSP.

5) Open question: is the Area Proxy LSP to be advertised/read from L1 or L2 
LSP/LSDB or both?

"All routers within the Inside Area speak Level 1 and Level 2 IS-IS on all of 
the links within the topology."
OK.

"A node advertises the Area Proxy TLV in its L2 LSP"
So my reading/guessing is that the Area Proxy TLV is only sent in the L2 LSP of 
all Inside routers. (i.e. not in the L1 LSP).
If so:

-  Can you clarify the behavior when an Area Proxy TLV is received in 
an L1 LSP? (e.g. ignore, and if not, what is the behavior when the TLV is 
different in L1 and L2).

-  "they will advertise the Area Proxy TLV." May be adding "in their L2 
LSP"

-  "All Inside Edge Routers learn the Area Proxy System Identifier from 
the Level 1 LSDB". I would have assumed  "from the Area Proxy TLV advertised in 
the level 2 LSDB.  So it may be a typo or I'm missing something, which is very 
possible.

o   "it MUST inject   the Area Proxy System Identifier into the Level 1 LSDB." 
Same comment.


Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, September 4, 2020 2:29 PM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Tony,

I've read the diff for -03 and -04.
The new encoding of the Area SID is good for me.

And thank you for listening to my use case and suggestion.

Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
tony...@tony.li
Sent: Monday, August 24, 2020 7:02 PM
To: lsr@ietf.org
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi folks,

This updated draft has been published for a few weeks now.  We would like to 
solicit your opinion on this.  In particular, we have changed the encoding of 
the Area SID.  Do you find this encoding adequate and appropriate?

Thanks,
Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Date: August 5, 2020 at 1:17:39 PM PDT
To: mailto:i-d-annou...@ietf.org>>
Cc: lsr@ietf.org
Reply-To: internet-dra...@ietf.org, 
lsr@ietf.org


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   : Area Proxy for IS-IS
   Authors : Tony Li
 Sarah Chen
 Vivek Ilangovan
 Gyan S. Mishra
Filename: draft-ietf-lsr-isis-area-proxy-03.txt
Pages 

Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[bruno.decraene]

Hi Tony,

I've read the diff for -03 and -04.
The new encoding of the Area SID is good for me.

And thank you for listening to my use case and suggestion.

Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Monday, August 24, 2020 7:02 PM
To: lsr@ietf.org
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi folks,

This updated draft has been published for a few weeks now.  We would like to 
solicit your opinion on this.  In particular, we have changed the encoding of 
the Area SID.  Do you find this encoding adequate and appropriate?

Thanks,
Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Date: August 5, 2020 at 1:17:39 PM PDT
To: mailto:i-d-annou...@ietf.org>>
Cc: lsr@ietf.org
Reply-To: internet-dra...@ietf.org, 
lsr@ietf.org


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   : Area Proxy for IS-IS
   Authors : Tony Li
 Sarah Chen
 Vivek Ilangovan
 Gyan S. Mishra
  Filename: draft-ietf-lsr-isis-area-proxy-03.txt
  Pages   : 19
  Date: 2020-08-05

Abstract:
  Link state routing protocols have hierarchical abstraction already
  built into them.  However, when lower levels are used for transit,
  they must expose their internal topologies to each other, leading to
  scale issues.

  To avoid this, this document discusses extensions to the IS-IS
  routing protocol that would allow level 1 areas to provide transit,
  yet only inject an abstraction of the level 1 topology into level 2.
  Each level 1 area is represented as a single level 2 node, thereby
  enabling greater scale.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


_

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

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[bruno.decraene]

Les,

Please see inline.

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, August 4, 2020 4:50 PM
To: DECRAENE Bruno TGI/OLN ; lsr@ietf.org
Subject: RE: draft-ietf-lsr-isis-area-proxy-02

Bruno -

Please see inline.

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: Tuesday, August 04, 2020 5:45 AM
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi,

I may be missing something but the SR Binding SID TLV extension  is not clear 
to me.

1)  It does not seem compliant with RFC 8667

Draft says that the advertisement has: T-flag set, M & A flags cleared, 
SID/Label sub-TLV present, Prefix-SID sub-TLV NOT present


The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5)



 When T-flag is set:



M and A flag MUST be clear



Range and Prefix are ignored



  Section 2.4.4 of RFC 
8667 is altered to say:



 "The Prefix-SID sub-TLV MUST be present in the SID/Label

 Binding TLV when the M-Flag and T-flag are both clear.  The

 Prefix-SID sub-TLV MUST NOT be present when either the M-Flag

 or T-flag are set."



  Regarding the SID/Label sub-TLV Section 2.4.5 of RFC 
8667 is

  altered to say:



 "It MUST be present in the SID/Label Binding TLV when either

 the M-Flag or T-flag is set in the Flags field of the parent

 TLV."

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#page-14



By definition, legacy L2 external  node will support vanilla RFC 8667, which 
says:
"The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the 
M-Flag is clear."
https://www.rfc-editor.org/rfc/rfc8667.html#name-sid-label-binding-tlv

So it seems that the extension violates the above MUST in RFC8667, as regarding 
the Prefix-SID sub-TLV
-  Area proxy says "MUST NOT be present" (as T-flag is set)
-  RFC 8667 says "MUST be present" (as M-flag is cleared)


In addition to the above, legacy node _will_ interpret the 'Range' and 'Prefix' 
fields. So there is probably a need to specify which values need to be 
advertised for those legacy nodes. A priori range would be one as a single SID 
is advertised. Prefix seems more problematic as you need to find an IP prefix 
to advertise. And please let's avoid SID conflict and Prefix conflict...
[Les:] Format of the Binding TLV when the new T-bit is set is similar to the 
format when the M-bit is set in that Prefix-SID sub-TLV is NOT present.
A legacy node parsing the Binding TLV would be looking for the Prefix-SID 
sub-TLV (M-bit NOT set) and would not find it. The contents of the Binding TLV 
would therefore be unusable to a legacy node.
The correct behaviour for a legacy node would be to (optionally) report an 
"invalid TLV" and to ignore the TLV.
[Bruno]
Clearly, there is a way to advertise the SID without violating a MUST in a RFC. 
e.g. version -00 of this draft
I don't see a reason to define a spec which deliberately violates another spec. 
In the best case, this would report errors forever to the network operator. In 
the worst case, this could fall into a bug.


2)  It's not clear to me whether the segment/SID is global or local.
As per my understanding of the draft-ietf-lsr-isis-area-proxy use case, the 
area-proxy SID would be global (in the external L2): "Area SID which will 
direct traffic to any of the Inside Edge Routers."

But the SID/Label Sub-TLV used by area-proxy has no flag (L-flag) indicating 
whether the SID is global or local. One could argue that if it carries a label 
it's a local SID and if it carries and index it's a global SID. But this has 
not been specified.
It has also no "algorithm" indicating how it needs to be routed global, so at 
minimum would not work with different routing algo/flex algo.
I'm not seeing in RFC 8402 or 8667 any text saying that such SID would be 
global hence globally routed in the L2 domain. (To me, this IS-IS SID was 
local, but arguably also can't find text stating this).

[Les:] There is a subtle difference between the Prefix-SID sub-TLV as defined 
in https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1 and the SID/Label 
sub-TLV defined in https://www.rfc-editor.org/rfc/rfc8667.html#SIDLABELSUBTLV

The Prefix-SID sub-TLV has a flags field which includes V-bit/L-bit to indicate 
whether the variable length field which follows is a 3 byte label (both bits 
set to 1) or a 4 byte index (both bits set to 0).

The SID/Label sub-TLV has no flags field. The length of the sub-TLV indicates 
whether the advertised value has is a label (length = 3)  or an index (length = 
4).

[Bruno] Agreed so far.
Do we agree that 

[Lsr] draft-ietf-lsr-isis-area-proxy-02

[bruno.decraene]

Hi,

I may be missing something but the SR Binding SID TLV extension  is not clear 
to me.


1)  It does not seem compliant with RFC 8667

Draft says that the advertisement has: T-flag set, M & A flags cleared, 
SID/Label sub-TLV present, Prefix-SID sub-TLV NOT present


The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5)



 When T-flag is set:



M and A flag MUST be clear



Range and Prefix are ignored



  Section 2.4.4 of RFC 
8667 is altered to say:



 "The Prefix-SID sub-TLV MUST be present in the SID/Label

 Binding TLV when the M-Flag and T-flag are both clear.  The

 Prefix-SID sub-TLV MUST NOT be present when either the M-Flag

 or T-flag are set."



  Regarding the SID/Label sub-TLV Section 2.4.5 of RFC 
8667 is

  altered to say:



 "It MUST be present in the SID/Label Binding TLV when either

 the M-Flag or T-flag is set in the Flags field of the parent

 TLV."

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#page-14



By definition, legacy L2 external  node will support vanilla RFC 8667, which 
says:
"The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the 
M-Flag is clear."
https://www.rfc-editor.org/rfc/rfc8667.html#name-sid-label-binding-tlv

So it seems that the extension violates the above MUST in RFC8667, as regarding 
the Prefix-SID sub-TLV

-  Area proxy says "MUST NOT be present" (as T-flag is set)

-  RFC 8667 says "MUST be present" (as M-flag is cleared)


In addition to the above, legacy node _will_ interpret the 'Range' and 'Prefix' 
fields. So there is probably a need to specify which values need to be 
advertised for those legacy nodes. A priori range would be one as a single SID 
is advertised. Prefix seems more problematic as you need to find an IP prefix 
to advertise. And please let's avoid SID conflict and Prefix conflict...


2)  It's not clear to me whether the segment/SID is global or local.
As per my understanding of the draft-ietf-lsr-isis-area-proxy use case, the 
area-proxy SID would be global (in the external L2): "Area SID which will 
direct traffic to any of the Inside Edge Routers."

But the SID/Label Sub-TLV used by area-proxy has no flag (L-flag) indicating 
whether the SID is global or local. One could argue that if it carries a label 
it's a local SID and if it carries and index it's a global SID. But this has 
not been specified.
It has also no "algorithm" indicating how it needs to be routed global, so at 
minimum would not work with different routing algo/flex algo.
I'm not seeing in RFC 8402 or 8667 any text saying that such SID would be 
global hence globally routed in the L2 domain. (To me, this IS-IS SID was 
local, but arguably also can't find text stating this).

At minimum, area-proxy would need to specify whether the SID is global and 
local. And if global, with which hard coded algorithm it is routed. (I would 
assume "0")


Thanks,
Regards,
--Bruno


_

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

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

[bruno.decraene]

Les,


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, August 3, 2020 5:22 PM
To: DECRAENE Bruno TGI/OLN ; tony...@tony.li
Cc: lsr@ietf.org
Subject: RE: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Bruno –

The concept of “Area SID” – at least to me – is “please forward to any node in 
the Area advertising the Area SID”.
[Bruno] How is that different from “anycast”? i.e. your option b?

You, however, seem to be asking for either:

a)The node originating the Proxy LSP to advertise a Node SID for a loopback 
address on that node

OR

b)The node originating the Proxy LSP to advertise an anycast SID which is 
shared by the IERs in the Proxy Area

To do so, it seems to me we need not invent a new type of SID, we can simply 
advertise using the existing Prefix Reachability/Prefix SID sub-TLVs.

So it seems you are not interested in an “Area SID”.

Can you please clarify?

[Bruno] I’m interested in the forwarding behavior defined in the draft: “all of 
the Inside Edge Nodes […] should consume this SID at forwarding time.” How we 
call this, I don’t really care. Could be area SID, or proxy SID or anycast SID… 
but for the external L2 nodes, there is no anycast behavior: just one single 
node/LSP/SID, so calling it anycast could be strange.


For me, the reason to invent a new type of SID and new forms of SID 
advertisements is because we were defining a SID with new functionality i.e., 
send this to another area – which entry point into the area is used should not 
matter.
[Bruno] From the external L2 nodes, the “area” is seen as a single node. “which 
entry point into the area is used ” equals “which interface of the (proxy) node 
is used. I’m not sure that we need a new concept.
From within area internal nodes, we do see the detail of the topology and need 
to advertise & agree on the area SID.
This seems like a property which might be useful – and might be useful outside 
of Area Proxy use cases as well. If however, we (the WG) see no need for this 
type of SID then we should remove these definitions and simply use the existing 
Prefix-SID advertisements.
[Bruno] The property is useful. I’m fine with the name & encoding in current 
and past draft.
I’m simply raising the point that this new advertisement will not be understood 
by vanilla external L2 nodes. Hence unless you upgrade all those external 
nodes, you have regression in the network, at least in the following use case: 
replacing a big chassis with a set of smaller nodes grouped in one area.

One other comment regarding your reference to 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03 .

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-2.1 
already specifies that all inside nodes MUST have the “same SRGB”. So I do not 
see that your reference is relevant – unless you are proposing to change that.
[Bruno] You can safely forget about this reference.
I was trying to say that anycast SID is not new. And no, I’m not proposing to 
change that all node must use the same SRGB. (that been said, sometimes you 
need to use the implementation that are on the market. The concept of index + 
SRGB has only been designed because some nodes could not support a common SRGB.)
--Bruno

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: Monday, August 03, 2020 1:10 AM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Hi Tony,

From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of 
tony...@tony.li
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for the clarification.
[Bruno] You are very welcome. Thank you for listening.

 I understand completely what you’re trying to do and I agree that it’s 
valuable.

The downside of your approach is that the Area Leader will now need 
configuration of a new prefix to advertise as the Node SID.
[Bruno] Agreed.
I believe that the Area SID equally needs to be configured, so configuration is 
required in all cases. Given this, the extra effort seems marginal to me.
Not unthinkable.

What do the Inside Nodes do with this prefix, if anything?
[Bruno] good question. 2 options:
-  Drop traffic to control plane (i.e. IP is not supposed to be used)
-  Nothing really new: it’s an anycast IP/SID. There is even a draft 
for the more complex case where the SRGB is different on the anycast nodes . 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03

Regards,
--Bruno

I am open to this approach, either in addition to, or instead of the approach 
currently in the draft.  I await feedback from the WG.

Regards,
Tony



p.s. The fact that the node SID requires a prefix is just a side effect of the 
IP address space excluding hosts from 

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

[bruno.decraene]

Hi Tony,

From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for the clarification.
[Bruno] You are very welcome. Thank you for listening.

 I understand completely what you’re trying to do and I agree that it’s 
valuable.

The downside of your approach is that the Area Leader will now need 
configuration of a new prefix to advertise as the Node SID.
[Bruno] Agreed.
I believe that the Area SID equally needs to be configured, so configuration is 
required in all cases. Given this, the extra effort seems marginal to me.
Not unthinkable.

What do the Inside Nodes do with this prefix, if anything?
[Bruno] good question. 2 options:

-  Drop traffic to control plane (i.e. IP is not supposed to be used)

-  Nothing really new: it’s an anycast IP/SID. There is even a draft 
for the more complex case where the SRGB is different on the anycast nodes . 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03

Regards,
--Bruno

I am open to this approach, either in addition to, or instead of the approach 
currently in the draft.  I await feedback from the WG.

Regards,
Tony



p.s. The fact that the node SID requires a prefix is just a side effect of the 
IP address space excluding hosts from addressing. The one, true
way within IS-IS is the system ID, a separate, independent namespace for nodes 
that simply avoids ALL of these problems.  If RFC 8667
encoded node SIDs as their own TLV without the unnecessary prefix that OSPF’s 
style mandates, this would be trivial.




On Jul 31, 2020, at 2:24 AM, 
bruno.decra...@orange.com wrote:

Hi Tony,

Thank you for your reply.
Top posting the description of the use case that I have in mind.

>  First off, the Area SID is 100% optional. If you choose not to use it, then 
> the Proxy LSP should be 100% compatible with a standard L2 node.
Good. But I think that the idea of the Area SID is a good one, and I choose to 
use it. Then I’d like to get it for free ;-)


Please fine below a network topology:



My understanding is that the L2 topology seen by node S is the following


P been the Proxy LSP.

S wants to protect from the failure of link S-C by using TI-LFA. For the 
destination C, it would push 2 (*) node SIDs: P, C
So S needs a Node SID for P:
a)  If P does not redistribute the Node SIDs from its area members, P does 
not seem to advertise any node SID currently. There is a chance that C’s TI-LFA 
implementation would not like it and hence would not install protection for 
this (link, destination)
b)  If P redistributes the Node SIDs from its area members, P advertises 3 
node SIDs (1,2, 3). S could pick any one at random. If it picks 3, the 
forwarding path would be S, A,B, 1, 2, 3, 2 , 1, C,  which is suboptimal.

Two solutions I could think of:
- when redistributing the node SID, P changes the SIDs values and replace them 
with the value of the Area SID. This works for this use case, but it is 
borderline. (e.g. if some a L2 node learn both the original and ‘NATed’ SID, we 
have some SID conflict. Let’s try to avoid this subject).
- P could advertise its own Node-SID with the Area SID value. This is what I’m 
proposing. Both the IP loopback and the Area SID of this Node SID  are likely 
configured by the network operator so this does not seem like a significant 
effort from the implementation.

As you say, this does not involve any protocol extension. But the goal is to 
improve interop with existing/legacy L2 nodes so this may be valuable in the 
draft. This point could be pushed to a deployment consideration section if you 
don’t want any impact on the protocol extension.

Thanks,
--Bruno

(*) Assuming the right metrics on the links. This is not the subject of this 
thread.


From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of 
tony...@tony.li
Sent: Thursday, July 30, 2020 7:39 PM
To: DECRAENE Bruno TGI/OLN 
mailto:bruno.decra...@orange.com>>
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for your comments.




On Jul 30, 2020, at 9:22 AM, 
bruno.decra...@orange.com wrote:

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.

>  - The Area Segment SID TLV has been replaced by extending the Binding SID 
> TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

[bruno.decraene]

Hi Tony,

Thank you for your reply.
Top posting the description of the use case that I have in mind.


Ø  First off, the Area SID is 100% optional. If you choose not to use it, then 
the Proxy LSP should be 100% compatible with a standard L2 node.
Good. But I think that the idea of the Area SID is a good one, and I choose to 
use it. Then I’d like to get it for free ;-)


Please fine below a network topology:
[cid:image003.jpg@01D6672D.1946D4F0]


My understanding is that the L2 topology seen by node S is the following
[cid:image004.jpg@01D6672D.1946D4F0]

P been the Proxy LSP.

S wants to protect from the failure of link S-C by using TI-LFA. For the 
destination C, it would push 2 (*) node SIDs: P, C
So S needs a Node SID for P:

a)  If P does not redistribute the Node SIDs from its area members, P does 
not seem to advertise any node SID currently. There is a chance that C’s TI-LFA 
implementation would not like it and hence would not install protection for 
this (link, destination)

b)  If P redistributes the Node SIDs from its area members, P advertises 3 
node SIDs (1,2, 3). S could pick any one at random. If it picks 3, the 
forwarding path would be S, A,B, 1, 2, 3, 2 , 1, C,  which is suboptimal.


Two solutions I could think of:
- when redistributing the node SID, P changes the SIDs values and replace them 
with the value of the Area SID. This works for this use case, but it is 
borderline. (e.g. if some a L2 node learn both the original and ‘NATed’ SID, we 
have some SID conflict. Let’s try to avoid this subject).
- P could advertise its own Node-SID with the Area SID value. This is what I’m 
proposing. Both the IP loopback and the Area SID of this Node SID  are likely 
configured by the network operator so this does not seem like a significant 
effort from the implementation.

As you say, this does not involve any protocol extension. But the goal is to 
improve interop with existing/legacy L2 nodes so this may be valuable in the 
draft. This point could be pushed to a deployment consideration section if you 
don’t want any impact on the protocol extension.

Thanks,
--Bruno

(*) Assuming the right metrics on the links. This is not the subject of this 
thread.


From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Thursday, July 30, 2020 7:39 PM
To: DECRAENE Bruno TGI/OLN 
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for your comments.



On Jul 30, 2020, at 9:22 AM, 
bruno.decra...@orange.com wrote:

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.

>  - The Area Segment SID TLV has been replaced by extending the Binding SID 
> TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 
2.4 are used to

   advertise such a SID.



   The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5) »




This works.


Excellent.



However I may have a different deployment environment than the one you have in 
mind. Even if those issues may be mine, allow me to share them with you.
In many WAN networks than I’m used to, there are routers from different 
vendors, platforms, software, generations. Requiring all those routers to 
support the new Binding SID TLV T-Flag will take time. Some platform may even 
be end of engineering (evolutions) so would never support such new features.
In my environment, ideally, I would prefer a solution which do not require any 
new feature on external L2 nodes, while all existing L2 features keep working, 
in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would require the 
Proxy LSP to be not (significantly) different than the LSP of a vanilla L2 node.


First off, the Area SID is 100% optional. If you choose not to use it, then the 
Proxy LSP should be 100% compatible with a standard L2 node.



I cannot claim that we’ve exhaustively tested our implementation against all of 
the features that you cite, so there may still be corner cases, but our intent 
is to make that doable.  For exaple, the Proxy LSP can still contain a node 
SID, adjacency SID, and prefix SID as before. There’s no change there.



For SR, I think that this would require this Proxy LSP to advertise a 
Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID is 
advertised with an IP address that would need to be provisioned.


That’s certainly 

Re: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

[bruno.decraene]

Les,

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, July 30, 2020 7:29 PM
To: DECRAENE Bruno TGI/OLN ; tony...@tony.li; 
lsr@ietf.org
Subject: RE: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Bruno –

One of the reasons to use the Binding TLV to advertise the Area SID was that it 
has been suggested that other use cases for Area SID – unrelated to Area Proxy 
– may come along.
Therefore tying the advertisement to an Area Proxy TLV seems not the best 
option if we want to allow for these other use cases (admittedly currently 
unknown).

Thoughts??

I have no problem with the format or the name of the IS-IS extension used to 
advertise the Area SID to external L2 nodes. Binding TLV works for me.
I think that the area SID is useful to external L2 nodes, including to nodes 
not supporting this extension. Hence the proposal to (also) advertise it in a 
regular Node SID. I’ll detail the use case in a subsequent email to be sent 
today. Writing it done will also be beneficial to me.

Thanks,
--Bruno


   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: Thursday, July 30, 2020 9:22 AM
To: tony...@tony.li; lsr@ietf.org
Subject: Re: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.

Ø  - The Area Segment SID TLV has been replaced by extending the Binding SID 
TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 
2.4 are used to

   advertise such a SID.



   The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5) »




This works.
However I may have a different deployment environment than the one you have in 
mind. Even if those issues may be mine, allow me to share them with you.
In many WAN networks than I’m used to, there are routers from different 
vendors, platforms, software, generations. Requiring all those routers to 
support the new Binding SID TLV T-Flag will take time. Some platform may even 
be end of engineering (evolutions) so would never support such new features.
In my environment, ideally, I would prefer a solution which do not require any 
new feature on external L2 nodes, while all existing L2 features keep working, 
in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would require the 
Proxy LSP to be not (significantly) different than the LSP of a vanilla L2 
node. For SR, I think that this would require this Proxy LSP to advertise a 
Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID is 
advertised with an IP address that would need to be provisioned.

Both approaches are not mutually exclusives. I’d be happy enough with an option 
for the Proxy LSP to advertise an Area Node SID with the Area SID attached.

Finally, there is no requirement to make me happy ;-) . The above could also be 
a local implementation knob not mentioned in the draft.

Thanks,
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
tony...@tony.li
Sent: Sunday, July 26, 2020 3:49 AM
To: lsr@ietf.org
Subject: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi folks,

This version of the draft reflects major changes in line with the discussions 
that we’ve had so far.

To wit:
- The Area Proxy TLV is now moved to be in L2 LSPs and indicates that the 
advertising node is an Inside Node and Area Proxy is active.
- The Area Proxy Router Capability has been removed.
- The Inside Node TLV has been removed.
- The Area Segment SID TLV has been replaced by extending the Binding SID TLV.

We know that some folks disagree with this last point, so we welcome discussion 
on this. We would like to reach consensus as quickly as possible.

Thanks,
Tony


Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt
Date: July 25, 2020 at 6:46:05 PM PDT
To: "Vivek Ilangovan" mailto:ilango...@arista.com>>, 
"Sarah Chen" mailto:sarahc...@arista.com>>, "Gyan S. 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Gyan 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Yunxia 
Chen" mailto:sarahc...@arista.com>>, "Tony Li" 
mailto:tony...@tony.li>>


A new version of I-D, 

[Lsr] draft-ietf-lsr-isis-area-proxy-02

[bruno.decraene]

Hi authors,

Please find below some feedback for information. Feel free to ignore.

4.4.13.  The Area SID  
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.13

   "The following extensions to the Binding TLV are defined in order to
   support Area SID:

  A new flag is defined:

 T-flag: The SID directs traffic to an area.  (Bit 5)

 When T-flag is set:

M and A flag MUST be clear"

My understanding is that the Area SID is installed in the FIB of all inside 
edge routers. Based on this, I would argue that the  A flag could and SHOULD be 
set

https://www.rfc-editor.org/rfc/rfc8667.html#name-flags-2
"A-Flag: Attached Flag. The originator of the SID/Label Binding TLV MAY set the 
A bit in order to signal that the prefixes and SIDs advertised in the SID/Label 
Binding TLV are directly connected to their originators."
---
4.4.7.  Reachability TLVs   
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.7


   If the Inside Area supports Segment Routing and the selected TLV

   includes a Prefix Segment Identifier sub-TLV (3) 
[RFC8667], then the

   sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the

   copy of the sub-TLV to indicate that penultimate hop popping SHOULD

   NOT be performed for this prefix.  The E-Flag SHOULD be reset in the

   copy of the sub-TLV to indicate that an explicit NULL is not

   required. The R-Flag SHOULD simply be copied.




May be it would be more generic to say that those prefix are handled as 
redistributed prefix.
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1.2 and 
https://www.rfc-editor.org/rfc/rfc8667.html#EANDPFLAGS already defines the 
behaviour for respectively Prefix-SID propagation and P and E flags handling, 
so probably no need to re-specify:
When propagating (from either Level-1 to Level-2 or Level-2 to Level-1) a 
reachability advertisement originated by another IS-IS speaker, the router MUST 
set the P-Flag and MUST clear the E-Flag of the related Prefix-SIDs.
That would also cover for the handling of Prefix Attribute Flags sub-TLV 
RFC7794.

I would argue that the R-Flag MUST be set (rather than simply copied). As per 
https://www.rfc-editor.org/rfc/rfc8667.html#name-r-flag-and-n-flag

Best regards,
--Bruno


_

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

Re: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

[bruno.decraene]

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.


Ø  - The Area Segment SID TLV has been replaced by extending the Binding SID 
TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 
2.4 are used to

   advertise such a SID.



   The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5) »




This works.
However I may have a different deployment environment than the one you have in 
mind. Even if those issues may be mine, allow me to share them with you.
In many WAN networks than I’m used to, there are routers from different 
vendors, platforms, software, generations. Requiring all those routers to 
support the new Binding SID TLV T-Flag will take time. Some platform may even 
be end of engineering (evolutions) so would never support such new features.
In my environment, ideally, I would prefer a solution which do not require any 
new feature on external L2 nodes, while all existing L2 features keep working, 
in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would require the 
Proxy LSP to be not (significantly) different than the LSP of a vanilla L2 
node. For SR, I think that this would require this Proxy LSP to advertise a 
Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID is 
advertised with an IP address that would need to be provisioned.

Both approaches are not mutually exclusives. I’d be happy enough with an option 
for the Proxy LSP to advertise an Area Node SID with the Area SID attached.

Finally, there is no requirement to make me happy ;-) . The above could also be 
a local implementation knob not mentioned in the draft.

Thanks,
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Sunday, July 26, 2020 3:49 AM
To: lsr@ietf.org
Subject: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi folks,

This version of the draft reflects major changes in line with the discussions 
that we’ve had so far.

To wit:
- The Area Proxy TLV is now moved to be in L2 LSPs and indicates that the 
advertising node is an Inside Node and Area Proxy is active.
- The Area Proxy Router Capability has been removed.
- The Inside Node TLV has been removed.
- The Area Segment SID TLV has been replaced by extending the Binding SID TLV.

We know that some folks disagree with this last point, so we welcome discussion 
on this. We would like to reach consensus as quickly as possible.

Thanks,
Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt
Date: July 25, 2020 at 6:46:05 PM PDT
To: "Vivek Ilangovan" mailto:ilango...@arista.com>>, 
"Sarah Chen" mailto:sarahc...@arista.com>>, "Gyan S. 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Gyan 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Yunxia 
Chen" mailto:sarahc...@arista.com>>, "Tony Li" 
mailto:tony...@tony.li>>


A new version of I-D, draft-ietf-lsr-isis-area-proxy-02.txt
has been successfully submitted by Tony Li and posted to the
IETF repository.

Name:   draft-ietf-lsr-isis-area-proxy
Revision:   02
Title: Area Proxy for IS-IS
Document date:2020-07-25
Group:  lsr
Pages:   20
URL:
https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-02.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
Htmlized:   https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-02

Abstract:
  Link state routing protocols have hierarchical abstraction already
  built into them.  However, when lower levels are used for transit,
  they must expose their internal topologies to each other, leading to
  scale issues.

  To avoid this, this document discusses extensions to the IS-IS
  routing protocol that would allow level 1 areas to provide transit,
  yet only inject an abstraction of the level 1 topology into level 2.
  Each level 1 area is represented as a single level 2 node, thereby
  enabling greater scale.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[bruno.decraene]

Another data point about advertising more detailed reachability/unreachability: 
https://tools.ietf.org/html/draft-swallow-isis-detailed-reach-01

(for IPv6 some form of compression may be beneficial).

--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, July 28, 2020 11:18 AM
To: Acee Lindem (acee) 
Cc: Aijun Wang ; Zhibo Hu ; Yaqun 
Xiao ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hello Acee,

I would like to question your assessment that signalling unreachable routes is 
unnecessary.

Imagine hierarchical network with areas. Under no failures area 1 advertises to 
area 0 summary LSA with 1.1.1.0/24. That block covers PE's 
loopbacks which within the area are /32s. Those loopbacks are also BGP next 
hops.

Now imagine PE1 with 1.1.1.1/32 fails. Well till BGP 
reconverges all paths advertised by this PE with 1.1.1.1/32 
are still valid as this next hop is still reachable entire network wide. That 
means that traffic is being sent to this failed PE1 for relatively long period 
of time.

It seems natural that without breaking benefits of summarization across areas 
or domains in the above scenario we could continue to advertise 
1.1.1.0/24 - 1.1.1.1/32. That is when I 
see most benefits of advertising unreachability aka negative routing.

Of course said all of the above - if you search your employer's archives - you 
will see a proposal where the above mechanism can be done within BGP itself 
with no touch to the IGP - just using a bit of twisted next hop validation 
steps and BGP native recursion. I am not going to make any judgements here 
which method is better or easier - naturally I personally like BGP one more :).

But I hope this is clear why at least discussion on the subject is important. 
It also illustrates why the below statement is not necessarily correct:

"Note that the unreachability of a given summarized prefix is only relevant if 
it is reachable through another ABR. "

Kind regards,
Robert.


On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries.

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" 
mailto:lsr-boun...@ietf.org> on behalf of 
wang...@chinatelecom.cn> wrote:

Hi, LSR experts:

We have uploaded the new version of this PUA(Prefix Unreachable 
Announcement) draft. The main updates are the followings:
1) Describes the solution that using tunnel to redirect traffic among ABRs, 
when all ABRs reaches the PUA limit.
2) Describe fast rerouting to avoid routing black hole.
3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.

There are also some arguments about the current solution for PUA, for 
example:
1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to 
indicate the prefix is unreachable?
2) if not, what's the consideration? What's the other convincible solution?

Wish to hear comments and suggestions on the above issues. We will also 
have the presentation on the coming IETF LSR meeting.

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: internet-dra...@ietf.org 
[mailto:internet-dra...@ietf.org]
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; Yaqun Xiao 
mailto:xiaoya...@huawei.com>>
Subject: New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt


A new version of I-D, draft-wang-lsr-prefix-unreachable-annoucement-03.txt
has been successfully submitted by Aijun Wang and posted to the IETF 
repository.

Name:   draft-wang-lsr-prefix-unreachable-annoucement
Revision:   03
Title:  Prefix Unreachable Announcement
Document date:  2020-07-27
Group:  Individual Submission
Pages:   

Re: [Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Hi Bruno,
> 
> On 30/06/2020 18:08, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thanks for your reply.
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>
> >> Hi Bruno,
> >>
> >> please see inline:
> >>
> >> On 30/06/2020 16:53, bruno.decra...@orange.com wrote:
> >>> Hi all,
> >>>
> >>> I can live with the current text, but I'm just raising the point for
> discussion
> >> (better safe than sorry).
> >>>
> >>> "16.1.1.  IGP Algorithm Types Registry
> >>>
> >>>  This document makes the following registrations in the "IGP Algorithm
> >> Types" registry:
> >>>
> >>> Type: 128-255.
> >>>
> >>> Description: Flexible Algorithms.
> >>> "
> >>> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07#section-16.1.1
> >>>
> >>> This is essentially burning half of the registry for flex-algo. Indeed, 
> >>> any
> >> network operator could use any value, e.g. 222, hence the IETF could
> never
> >> define a different usage for this value without creating interop issues for
> the
> >> network operator.
> >>
> >> what is the real problem? Is the space 2-127 that is free not sufficient
> >> for other standardized algorithms that may come?
> >>
> >>>
> >>> We could discuss whether we really need 127 values for this. (i.e. a
> >> network operator requiring 127 flex algo, typically multiplying its IGP FIB
> >> entries by 127...).
> >>
> >> above is not necessarily true and more importantly completely irrelevant
> >> to the number of algos we reserve for FA.
> >>
> >>
> >>> We could also discuss whether this range could be change to the IANA
> well-
> >> known "Private Use" [1]. This would allow for alternative private usages in
> >> the future (e.g. Flexible Alorithms v2).
> >>> [1] https://tools.ietf.org/html/rfc8126#section-4.1
> >>>
> >>> It seems to me that the latter would equally work for flex algo, but
> would
> >> provide more flexibility :-) for the future.
> >>
> >> I don't think so. We need an allocated range of algos for FA for
> >> compatibility.
> >
> > The allocated range of algos for FA would be the same. Just not dedicated
> to FA.
> 
> this would not work. If I have a mix of routers, one set using value 222
> for flex-algo and another set for something else, how are they going to
> interoperate?

My understanding is that the value of the flexalgo is chosen by the network 
operator and configured on the router. 

" We want the mapping between the Flex-Algorithm and it's meaning to be 
flexible and defined by the user."
[...]
" Flexible-Algorithm is a numeric identifier in the range 128-255 that
   is associated via provisioning with the Flexible-Algorithm
   Definition."


IOW, "private or local use only, with the type and
   purpose defined by the local site.  No attempt is made to prevent
   multiple sites from using the same value in different (and
   incompatible) ways.  IANA does not record assignments from registries
   or ranges with this policy (and therefore there is no need for IANA
   to review them) and assignments are not generally useful for broad
   interoperability.  It is the responsibility of the sites making use
   of the Private Use range to ensure that no conflicts occur (within
   the intended scope of use)."

Which is the definition of Private Use by IANA.


> We need a standardized range, using Private Use is not an option here.

Yes we need a standardized range.
I'm not sure that this range needs to be dedicated to FA. But I leave this to 
you/the WG.

And thanks again for your active engagement in the discussion.

-- Bruno

> thanks,
> Peter
> 
> >
> > --Bruno
> >
> >>
> >> thanks,
> >> Peter
> >>>
> >>> Regards,
> >>> --Bruno
> >>>
> >>>
> >>
> __
> >>
> __
> >> _
> >>>
> >>> 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
> >>> 

Re: [Lsr] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi Peter,

Thanks for your reply.

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Hi Bruno,
> 
> please see inline:
> 
> On 30/06/2020 16:53, bruno.decra...@orange.com wrote:
> > Hi all,
> >
> > I can live with the current text, but I'm just raising the point for 
> > discussion
> (better safe than sorry).
> >
> > "16.1.1.  IGP Algorithm Types Registry
> >
> > This document makes the following registrations in the "IGP Algorithm
> Types" registry:
> >
> >Type: 128-255.
> >
> >Description: Flexible Algorithms.
> > "
> > https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07#section-16.1.1
> >
> > This is essentially burning half of the registry for flex-algo. Indeed, any
> network operator could use any value, e.g. 222, hence the IETF could never
> define a different usage for this value without creating interop issues for 
> the
> network operator.
> 
> what is the real problem? Is the space 2-127 that is free not sufficient
> for other standardized algorithms that may come?
> 
> >
> > We could discuss whether we really need 127 values for this. (i.e. a
> network operator requiring 127 flex algo, typically multiplying its IGP FIB
> entries by 127...).
> 
> above is not necessarily true and more importantly completely irrelevant
> to the number of algos we reserve for FA.
> 
> 
> > We could also discuss whether this range could be change to the IANA well-
> known "Private Use" [1]. This would allow for alternative private usages in
> the future (e.g. Flexible Alorithms v2).
> > [1] https://tools.ietf.org/html/rfc8126#section-4.1
> >
> > It seems to me that the latter would equally work for flex algo, but would
> provide more flexibility :-) for the future.
> 
> I don't think so. We need an allocated range of algos for FA for
> compatibility.

The allocated range of algos for FA would be the same. Just not dedicated to FA.

--Bruno
 
> 
> thanks,
> Peter
> >
> > Regards,
> > --Bruno
> >
> >
> __
> __
> _
> >
> > 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
> >
> >


_

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] draft-ietf-lsr-flex-algo

[bruno.decraene]

Hi all,

I can live with the current text, but I'm just raising the point for discussion 
(better safe than sorry).

"16.1.1.  IGP Algorithm Types Registry

   This document makes the following registrations in the "IGP Algorithm Types" 
registry:

  Type: 128-255.

  Description: Flexible Algorithms.
"
https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07#section-16.1.1

This is essentially burning half of the registry for flex-algo. Indeed, any 
network operator could use any value, e.g. 222, hence the IETF could never 
define a different usage for this value without creating interop issues for the 
network operator.

We could discuss whether we really need 127 values for this. (i.e. a network 
operator requiring 127 flex algo, typically multiplying its IGP FIB entries by 
127...).
We could also discuss whether this range could be change to the IANA well-known 
"Private Use" [1]. This would allow for alternative private usages in the 
future (e.g. Flexible Alorithms v2).
[1] https://tools.ietf.org/html/rfc8126#section-4.1

It seems to me that the latter would equally work for flex algo, but would 
provide more flexibility :-) for the future.

Regards,
--Bruno

_

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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

[bruno.decraene]

Hi Chris, Acee,

I support adoption.
I've provided comments on the draft a couple of days ago.

Regards,
--Bruno

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Wednesday, June 10, 2020 9:28 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps
Subject: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

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

  https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/

The draft would be adopted on the Experimental track.

Please indicate your support or objection by June 24, 2020.

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

Thanks,
Chris and Acee.

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

_

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] FW: New Version Notification for draft-decraene-lsr-isis-flooding-speed-04.txt

[bruno.decraene]

Hi WG,

Following our presentation at the latest LSR interim meeting, we have updated 
the draft as presented and discussed during the meeting.

High level changes are:
o  Adding general introduction on flow control, congestion control, loss 
detection and recovery.
o  Reorganizing sections as per the high level functions: flow control, 
congestion control, loss detection and recovery.
o  Adding a section on congestion control.

Low level diff are: 
https://www.ietf.org/rfcdiff?url2=draft-decraene-lsr-isis-flooding-speed-04

Comments are welcomed.
Thanks,
--Bruno

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Wednesday, June 10, 2020 5:37 PM
To: Gunter Van de Velde; Chris Bowers; Tony Li; Jayesh J; DECRAENE Bruno TGI/OLN
Subject: New Version Notification for 
draft-decraene-lsr-isis-flooding-speed-04.txt


A new version of I-D, draft-decraene-lsr-isis-flooding-speed-04.txt
has been successfully submitted by Bruno Decraene and posted to the
IETF repository.

Name:   draft-decraene-lsr-isis-flooding-speed
Revision:   04
Title:  IS-IS Flooding Parameters advertisement
Document date:  2020-06-10
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/internet-drafts/draft-decraene-lsr-isis-flooding-speed-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
Htmlized:   
https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-decraene-lsr-isis-flooding-speed-04

Abstract:
   This document proposes a mechanism that can be used to increase the
   speed at which link state information is exchanged between two
   routers when multiple LSPs need to be flooded, such as in case of a
   node failure.  It also reduces the likelihood of overloading the
   router receiving the LSPs, causing LSPs losses and delayed
   retransmission.  This document defines a new TLV to be advertised in
   SNP and/or Hello messages.  This TLV may carry a set of parameters
   indicating the performance capacity to receive LSPs: the number of
   LSPs which can the received back to back, the minimum delay between
   further two consecutive LSPs and the minimum delay before
   retransmission of an LSP.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_

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] draft-li-lsr-isis-area-proxy-06 & draft-przygienda-lsr-flood-reflection-01

[bruno.decraene]

Hi all,

I've quickly read both drafts.
In general, I don't think that I have spent enough time on the subject to 
provide any feedback on the list, but I've been suggested that some feedback is 
better than none. So providing some feedback for what it worth (2 cents).

I think that the use case is valid and worth working on.

In general, I think that a single solution would be better than two or one per 
vendor. Especially since the design choice of using a set of standard routers 
in the area/clos (rather than a proprietary chassis or a proprietary switch 
matrix) is an indication that interoperability is seen as a benefit. Yet the 
outcomes of both solutions are different so maybe they may also be considered 
as independent.

I'm personally fine with the approach chosen in draft-li-lsr-isis-area-proxy, 
which seems a good fit for the use case.
I think that the document could better highlight, to the reader and especially 
to a casual network operator reader, that the use of one proxy LSP/node to 
represent all Inside Edge Router/whole introduces some tradeoff. IOW this is 
not magic/transparent. In particular I'm thinking of router capability TLV and 
more generally (new) TLV: when different inside (edge) nodes advertise 
different capabilities/TLV there is a difficulty in aggregating all for the 
proxy node/LSP. I appreciate that the authors have considered the Segment 
Routing (SR) case, but there are others, both past and future. For existing 
TLV/capabilities, maybe I would favor that the document define the behavior for 
all TLV/capability (along "you fix what you break"). I understand that this is 
a significant work and that different people may have different opinion. In 
particular I'm concerned when both primary and backup area leaders are from 
different implementations and switching from one to another would create a chang
 e in the characteristic of the proxy node, which could impact L2 routing (e.g. 
change in node admin tag). For future TLV/work, I think that the document 
should highlight that the behavior for proxy LSP need to be considered and 
specified.


I've read draft-przygienda-lsr-flood-reflection. It is well written and works.
Regarding flooding:
a) IMHO I'm a bit scared with L2 flooding over tunnel: during L1 IGP 
convergence IP packet may be dropped including L2 LSP over IP tunnels. I don't 
feel that IS-IS is so good today to recover from lost LSP, in term of time 
required. The use of a TCP/SCTP tunnel may help, in which case there would be 
the question of not also using TCP for P2P adjacency, in order to handle flow 
control and congestion control and improve flooding speed. [1] proposes a 
modest improvement on faster recovery of lost LSP but this is also an 
individual document and will not completely remove the issue.
b) the use of configured flood reflector in order to simplify the flooding 
topology may possibly be replaced by an existing flooding graph reduction e.g. 
[2] The properties are a bit different, such as the requirement for new feature 
on all nodes. However given the proposed L1 topology, we could also considerer 
that dynamic flooding would also be useful/used in L1. This would avoid the 
definition of another mechanism to reduce the flooding graph.

Regarding L2 topology:
a) the outcome and the scaling seem different between both drafts. Flood 
reflection keeps all L1/L2 edge nodes in the L2 topology. This allows for 
better description of those nodes capabilities in the L2 LSDB. However the gain 
in term of number of nodes/LSP in the LS2DB seem limited (only the spine nodes 
are hidden, while area proxy hide both spine and leaf nodes). So the main 
benefit seems to be related to flooding graph reduction rather than reduction 
of the L2 topology/LSDB. Yet we already have solution for reducing the flooding 
graph [2].
b) I think that the document should also discuss the TLV/capabilities 
advertised by the Flood Reflector in the L2 topology. In particular when 
Segment Routing is enabled.

[1] 
https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-03#section-5
[2] https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding

Regards,
--Bruno


_

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 

Re: [Lsr] Rtgdir last call review of draft-ietf-isis-te-app-13

[bruno.decraene]

Les,

Thanks for the updated draft.
Looks ok to me except the point on interoperability. 

Indeed, I was asking to reinforce the requirement for interoperability with 
existing attributes, as this interop issue is created by this 
specification/extension. But you chose the opposite direction by calling 
existing routers "legacy routers" and by removing the "must" in the below 
sentence from -13 "must be able to co-exist with use  of the legacy 
advertisements by routers which do not support the extensions defined in this 
document.".
IMHO this document was primarily motivated by interoperability issues with 
implementations. This was correctly pointed out in [1], more specifically " 
Existing IS-IS standards do not provide a mechanism to explicitly indicate 
whether or not RSVP has been enabled on a link.  Instead, different RSVP-TE 
implementations have used the presence of certain traffic engineering sub-TLVs 
in IS-IS to infer that RSVP signalling is enabled on a given link."

In such condition, IMHO draft-ietf-isis-te-app should not have the potential to 
create new interop issues in the future, otherwise its net gain with regards to 
existing ("legacy") attributes seems debatable to me.

Moving the requirement for interoperability on the deployment side (i.e., 
network operator) as per -14, may prove difficult or impossible if implementers 
are not willing to accommodate. Given that, as you state it, there motivation 
is what's good for _their_ business, it seems a possibility that such vendor 
would argue that the network operator should just replace all their "older" 
routers with new ones, and as a matter of luck, they do have a very good deal 
to propose. I have seen this movie before (e.g. with LDP & TDP).

I also understand your point as a vendor.
After thinking about it for a while, I'd propose a resolution around indicating 
that interoperability is required but only for implementations supporting both 
new and current attributes. This cover my point for interop and a priori cover 
your point to allow implementation to only support the new attributes.

e.g. with the below text in §6.1
OLD:
Under the conditions defined above, implementations which support the
   extensions defined in this document have the choice of using legacy
   advertisements or application specific advertisements in support of
   SRTE and/or LFA.  This will require implementations to provide
   controls specifying which type of advertisements are to be sent/
   processed on receive for these applications.

NEW:
Under the conditions defined above, implementations which support 
both the legacy advertisements and the extensions defined in this document MUST 
provide controls  specifying which type of
advertisements are to be sent and which type of advertisements are to be 
processed on receive for these applications.

Or possibly much closer to your original text
NEW2
Under the conditions defined above, implementations which support
 both the legacy advertisements and the extensions defined in this document
have the choice of using legacy
   advertisements or application specific advertisements in support of
   SRTE and/or LFA.  Implementations are REQUIRED to provide
   controls specifying which type of advertisements are to be sent/
   processed on receive for these applications.


I would also revert the text in section 6.3 to the one present in version -13.

Thank you
--Bruno

[1] 
https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-protocols-03#section-1
  
 
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> 
> Bruno -
> 
> Thanx again for your review.
> V14 of the draft has been posted to address your comments.
> 
> Please let me know if you believe there are still outstanding issues.
> 
> A few more remarks inline.
> 
> > -Original Message-
> > From: bruno.decra...@orange.com 
> > Sent: Tuesday, June 02, 2020 9:33 AM
> > To: Les Ginsberg (ginsberg) 
> > Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org; 
> > rtg-
> > d...@ietf.org
> > Subject: RE: Rtgdir last call review of draft-ietf-isis-te-app-13
> > 
> > Les,
> > 
> > Thanks for your answers.
> > Comments inline
> > 
> > > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> > > Sent: Saturday, May 30, 2020 12:09 AM
> > >
> > > Bruno -
> > >
> > > Thanx for your (as always) meticulous review.
> > > Responses inline.
> > > Once we have reached agreement I will send out an updated version.
> > >
> > > > -Original Message-
> > > > From: Bruno Decraene via Datatracker 
> > > > Sent: Friday, May 29, 2020 10:18 AM
> > > > To: rtg-...@ietf.org
> > > > Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; 
> > > > lsr@ietf.org
> > > > Subject: Rtgdir last call review of draft-ietf-isis-te-app-13
> > > >
> > > > Reviewer: Bruno Decraene
> > > > Review result: Has Issues
> > > >
> > > >  Hello,
> > > >
> > > > I have been selected as the Routing Directorate reviewer for this draft.
> > The

Re: [Lsr] Rtgdir last call review of draft-ietf-isis-te-app-13

[bruno.decraene]

Les,

Thanks for your answers.
Comments inline

> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> Sent: Saturday, May 30, 2020 12:09 AM
> 
> Bruno -
> 
> Thanx for your (as always) meticulous review.
> Responses inline.
> Once we have reached agreement I will send out an updated version.
> 
> > -Original Message-
> > From: Bruno Decraene via Datatracker 
> > Sent: Friday, May 29, 2020 10:18 AM
> > To: rtg-...@ietf.org
> > Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org
> > Subject: Rtgdir last call review of draft-ietf-isis-te-app-13
> > 
> > Reviewer: Bruno Decraene
> > Review result: Has Issues
> > 
> >  Hello,
> > 
> > I have been selected as the Routing Directorate reviewer for this draft. The
> > Routing Directorate seeks to review all routing or routing-related drafts as
> > they pass through IETF last call and IESG review, and sometimes on special
> > request. The purpose of the review is to provide assistance to the Routing
> > ADs.
> > For more information about the Routing Directorate, please see
> > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> > 
> > Although these comments are primarily for the use of the Routing ADs, it
> > would
> > be helpful if you could consider them along with any other IETF Last Call
> > comments that you receive, and strive to resolve them through discussion or
> > by
> > updating the draft.
> > 
> > Document: draft-ietf-isis-te-app-13
> > Reviewer: Bruno Decraene
> > Review Date: 2020-05-29
> > IETF LC End Date: 2020-05-29
> > Intended Status: Standards Track
> > 
> > Summary:
> > I have some minor concerns about this document that I think should be
> > resolved before publication.
> > 
> > Comments:
> >   Draft is clear.
> > 
> > Minor Issues:
> > 
> > §4.1
> > *2 (for SABM & UDABM fields)
> > OLD: The length SHOULD be the minimum required to send all bits which are
> > set.
> > I'd propose
> > NEW: The length SHOULD be the minimum required to send all the
> > meaningful bits
> > which are set.
> > 
> > Motivation; the 'bits which are sent' are the bits in the SABM field. (they 
> > do
> > include non-meaningful and padding bits)
> > 
> 
> [Les:] The definition of what is "meaningful" and what is "padding"  to me is 
> ambiguous.
> Meaningful could be only those bits which are currently defined in the 
> registry (speaking of SABM here). But if there are 10 bits defined in the 
> registry and I only intend to set Bit 5, I do not need to send all 10 bits - 
> I only need to send one octet - because we state:
> 
> "Bits that are NOT transmitted MUST be treated as if they
   > are set to 0 on receipt.  "
> 
> Also, an implementation written when there were only 4 bits defined in the 
> registry might think that "meaningful" is different than an implementation 
> written when more than 8 bits were defined in the registry. Yet they can 
> still interoperate.
> 
> I believe the current language is best.

[Bruno]
I withdraw my comment. Sorry for the noise.
I had read "bits which are sent", while the text is "bits which are set".


> > 
> > 
> > OLD: Undefined bits MUST be transmitted as 0
> > NEW: Undefined transmitted bits MUST be cleared (0)
> > 
> > Motivation: currently the number of undefined bits is 8*8-3. They SHOULD
> > not be
> > transmitted (beyond the first ones fitting in the first N required octet). 
> > The
> > sentence "Undefined bits MUST be transmitted as 0" could be read as all
> > defined
> > bits MUST be transmitted (as 0).
> > ---
> [Les:] I do not see how that could be a valid interpretation given that we 
> state:
> 
> " The length SHOULD  be the minimum required to send all bits which are set."

[Bruno]
So we have
1) The length SHOULD  be the minimum required to send all bits which are set
2) Undefined bits MUST be transmitted as 0

Given the "MUST"  vs "SHOULD" and "transmitted" (which means "sent"), I do 
believe my proposal is better. But I won't insist.

 
> And (repeating)
> 
> "Bits that are NOT transmitted MUST be treated as if they
   > are set to 0 on receipt.  "
> 
> And again, you assume that "defined bits" is the same for all implementations 
> - which isn't guaranteed as I discussed above.

[Bruno] I don't think that this matter as the behavior is specific to the 
sender.
In addition, the term " Undefined bits" is yours.
 
> 
> > User Defined Application Identifier Bits have no name. I'd propose to call
> > them
> > UDABM[0], UDABM[1]... This may avoid that different implementation use
> > different names and, more problematic, that some implementations starting
> > with
> > 1 (the first, the second) while while some other implementations starts as 
> > 0,
> > creating interop issues (SABM[1] on node A is SABM[0] on node B)
> > ---
> 
> [Les:] What implementations may name bits they assign from the User space is 
> out of scope of this document.
> If I were implementing a non-standard User App I likely would give it a 
> meaningful name both in my code and in any 

Re: [Lsr] Flooding across a network

[bruno.decraene]

> From: Christian Hopps [mailto:cho...@chopps.org] 
> 
> Bruno persistence has made me realize something fundamental here.
> 
> The minute the LSP originator changes the LSP and floods it you have LSDB 
> inconsistency. 

Exactly my point. Thank you Chris.
I would even say: "The minute the LSP originator changes the LSP then you have 
LSDB inconsistency." But no big deal if there is disagreement on this detail.

> That is going to last until the last node in the network has updated it's 
> LSDB.

Absolutely.
So the faster we flood, the shorter the LSBD inconsistency.

Now IMO, even if a single/few nodes flood faster, there is a chance of 
shortening the LSDB inconsistency. But in all cases, I don't see how this could 
make the LSDB inconsistency longer.

 
> Les is pointing out that LSDB inconsistency can be bad in certain 
> circumstances e.g., if a critical node is slow and thus inconsistent.
> 
> I believe the right way to fix this is a simple one, help the operator flag 
> the broken router software/hardware for replacement, but otherwise IS-IS 
> should just try to do the best job it can do to which is to flood around the 
> problem (i.e., flood as optimally as possible).

+1
On a side note, I would not call a router flooding slowly as "broken". I find 
it understandable that in a given network there are different type of routers 
(core vs aggregation), different roles (P having 50 IGP adjacencies with 50 PEs 
vs PE having only 2 IGP adjacencies with 2 P), different hardware generations, 
different software, different vendors with different perspectives/markets.

Thank you Chris.

--Bruno
> 
> Thanks,
> Chris.
> [as WG member]
> 
> 
> > On May 6, 2020, at 10:33 AM, bruno.decra...@orange.com wrote:
> > 
> > Les,
> >  
> > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> > Sent: Wednesday, May 6, 2020 4:14 PM
> > To: DECRAENE Bruno TGI/OLN
> > Cc: lsr@ietf.org
> > Subject: RE: Flooding across a network
> >  
> > Bruno –
> >  
> > I am somewhat at a loss to understand your comments.
> > The example is straightforward and does not need to consider FIB update 
> > time nor the ordering of prefix updates on different nodes.
> > [Bruno] The example is straightforward but you are referring to FIB and IP 
> > packets forwarding as per those FIBs.
> > I’d like we focus on LSP flooding and LSDB consistency.
> >  
> > Consider the state of Node B and Node D at various time points from the 
> > trigger event.
> >  
> > T+ 2 seconds:
> > -
> > B has received all LSP Updates. It triggers an SPF and for all Northbound 
> > destinations previously reachable via C it installs paths via D.
> > Let’s assume it take 5 seconds to update the forwarding plane.
> >  
> > D has received 40 of the 1000 LSP updates. It triggers an SPF and finds 
> > that all Northbound destinations are reachable via B-C. It makes no changes 
> > to the forwarding plane.
> >  
> > T+7 seconds
> > -
> > B has completed FIB updates. Traffic to all Northbound destinations is 
> > being forwarded via D.
> >  
> > D has now received 140 of the 1000 LSP updates. Entries in its forwarding 
> > plane for Northbound destinations still point to B.
> >  
> > We have a loop.
> >  
> > T + 30 seconds
> > 
> > D has now received 600 of the 1000 LSP updates. Still no changes to its 
> > forwarding plane.
> > Traffic to Northbound destinations is still looping.
> >  
> > T+ 50 seconds
> > ---
> > D has finally received all 1000 LSP updates..
> > It triggers (another) SPF and calculates paths to Northbound destinations 
> > via E. It begins to update its forwarding plane.
> > Let’s assume this will take 5 seconds..
> >  
> > T + 55 seconds
> > 
> > D has completed forwarding plane updates – no more looping.
> >  
> > That is all I am trying to illustrate.
> >  
> > If you want to start arguing that node protecting LFAs + microloop 
> > avoidance could help (NOTE I explicitly  took those out of the example for 
> > simplicity) – it is easy enough to change the example to include multiple 
> > node failures or a node failure plus some northbound link failures on other 
> > nodes.
> > [Bruno] I’m not talking about LFA/FRR. And with regards to microloops 
> > avoidance, some algorithms can handle any graph transition so including 
> > multiple node failures.
> >  
> > But again, let’s stick to LSP flooding and LSDB consistency. (you are the 
> > one speaking about microloops in the forwarding plane).
> >  
> > The point here is to look at the impact of long-lived LSDB inconsistency 
> > which results when some nodes support flooding an order of magnitude faster 
> > flooding than other nodes – which is what you asked me to clarify.
> > [Bruno] No. I asked you to clarify why having a node with faster flooding 
> > could prolongs the period of LSDB inconsistency.
> >  
> > Again, with you own words: “when only some nodes in the network support 
> > faster flooding the 

Re: [Lsr] Flooding across a network

[bruno.decraene]

Les,

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, May 6, 2020 1:35 AM
To: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Subject: RE: Flooding across a network


Bruno -



Seems like it was not too long ago that we were discussing this in person.  
Ahhh...the good old days...

[Bruno] Indeed, may be not to the point of concluding. Indeed.



First, let's agree that the interesting case does not involve 1 or even a small 
number of LSPs. For those cases flooding speed does not matter.

The interesting cases involve a large number of LSPs (hundreds or thousands). 
And in such cases LFA/microloop avoidance techniques are not applicable.



Take the following simple topology:



   |  | ... ||

 +---+ +---+

 | C | | E |

 +---+ +---+

   | | 1000

 +---+ +---+

 | B |-| D |

 +---+   1000  +---+

   | |

   | |

\   /

 \/

  \ /

   \  /

 +---+

 | A |

 +---+



There is a topology northbound of C and E (not shown) and a topology southbound 
of A (not shown).

Cost on all links is 10 except B-D and D-E where cost is high.



C is a node with 1000 neighbors.

When all links are up, shortest path for all northbound destinations is via C.

All nodes in the network support fast flooding except for Node D.

Let's say fast flooding is 500 LSPs/second and slow flooding (Node D) is 20 
LSPs/seconds.

If  Node C fails we have 1000 LSPs to flood.

All nodes except for D can receive these in 2 seconds (plus internode delay 
time).

D can receive LSPs in 50 seconds.



[Bruno] Thanks for your example. Agreed so far.



When A and B and all southbound nodes receive/process the LSP updates they will 
start sending traffic to Northbound destinations via D.

But for the better part of 50 seconds, Node D has yet to receive all LSP 
updates and still believes that shortest path is via B-C. It will loop traffic.



[Bruno] May I remind you that we are discussing IS-IS flooding in order to sync 
LSDB (LSP database). That is already a big enough subject. It does not 
including FIB (updates), nor IP forwarding.



Quoting you "when only some nodes in the network support faster flooding the 
behavior of the whole network may not be "better" when faster flooding is 
enabled because it prolongs the period of LSDB inconsistency."



Taking your own examples, in both cases (all nodes support fast flooding; all 
nodes but D support fast flooding) the period of LSDB inconsistency is 50 
seconds. Hence this example does not illustrate your statement.



Hence I'm restating my questions:



> > when only some nodes in the network support faster flooding the behavior

> of the whole network may not be "better" when faster flooding is enabled

> because it prolongs the period of LSDB inconsistency.

>

> 1) Do you have data on this?

>

> 2) If not, can you provide an example where increasing the flooding rate on

> one adjacency prolongs the period of LSDB inconsistency across the

> network?





Had all nodes used slow flooding, it still would have taken 50 seconds to 
converge, but there would be significantly less looping. There could be a good 
amount of blackholing, but this is preferable to looping.

[Bruno] You are using an example where ordering FIB updates across the network, 
e.g. as per [1], allows to reduce _FIB_ inconsistency across the path/network. 
And you seem to conclude from this that this translates to LSDB update 
ordering. Those are two different things. In this thread, I'd suggest that we 
focus on IGP flooding and LSDB sync only. (*)

[1] https://tools.ietf.org/html/rfc6976

(*) We can discuss loop free IGP converge in a different thread if you want.. 
IMO, the use of segment routing/source routing is better than oFIB. But at some 
point, it still relies on fast flooding when multiple LSPs are involved. (and I 
mean _fast_ not _ordered_)



--Bruno



One can always come up with examples - based on a specific topology and a 
specific failure - where things might be better/worse/unchanged in the face of 
inconsistent flooding speed support.

But I hope this simple example illustrates the pitfalls.



Les



> -Original Message-

> From: bruno.decra...@orange.com 

> Sent: Tuesday, May 05, 2020 8:28 AM

> To: Les Ginsberg (ginsberg) ; lsr@ietf.org

> Subject: Flooding across a network

>

> Les,

>

> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg

> (ginsberg)

> > Sent: Monday, May 4, 2020 4:39 PM

> [...]

> > when only some nodes in the network support faster flooding the behavior

> of the whole network may not be "better" when faster flooding is enabled

> because it prolongs the period of LSDB inconsistency.

>

> 1) Do you have data on this?

>

> 2) If not, can you provide an example where 

[Lsr] Flooding across a network

[bruno.decraene]

Les,

> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
> Sent: Monday, May 4, 2020 4:39 PM
[...]
> when only some nodes in the network support faster flooding the behavior of 
> the whole network may not be "better" when faster flooding is enabled because 
> it prolongs the period of LSDB inconsistency.  

1) Do you have data on this?

2) If not, can you provide an example where increasing the flooding rate on one 
adjacency prolongs the period of LSDB inconsistency across the network?

3) In the meantime, let's try the theoretical analysis on a simple scenario 
where a single LSP needs to be flooded across the network.

- Let's call Dij the time needed to flood the LSP from node i to the adjacent 
node j. Clearly Dij>0.
- Let's call k the node originating this LSP at t0=0s

>From t0, the LSDB is inconsistent across the network as all nodes but k are 
>missing the LSP and hence only know about the 'old' topology.

Let's call  SPT(k) the SPT rooted on k, using Dij as the metric between 
adjacent nodes i and j. Let's call SP(k,i) the shortest path from k to i; and 
D(k,i) the shortest distance between k and i.

It seems that the time needed:
- for node j to learn about the LSP, and get in sync with k, is D(k,j)
- for all nodes across the network to learn about the LSP, and get in sync with 
k, is Max[for all j] D(k,j)

Then how can reducing the flooding delay on one adjacency could prolongs the 
period of LSDB inconsistency?
It seems to me that it can only improve/decrease it. Otherwise, this would mean 
that decreasing the cost on a link can increase the cost of the shortest path.

Note: I agree that there are other cases, such as  multiple LSPs originated by 
the same node, and multiple LSPs originated by multiple nodes, but let's start 
with the simple case. 

Thanks,
--Bruno

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
> Sent: Monday, May 4, 2020 4:39 PM
> 
> Henk -
> 
> Thanx for your thoughtful posts.
> I have read your later posts on this thread as well - but decided to reply to 
> this one.
> Top posting for better readability.
> 
> There is broad agreement that faster flooding is desirable.
> There are now two proposals as to how to address the issue - neither of which 
> is proposing to use TCP (or equivalent).
> 
> I have commented on why IS-IS flooding requirements are significantly 
> different than that for which TCP is used.
> I think it is also useful to note that even the simple test case which Bruno 
> reported on in last week's interim meeting demonstrated that without any 
> changes to the protocol at all IS-IS was able to flood an order of magnitude 
> faster than it commonly does today.
> This gives me hope that we are looking at the problem correctly and will not 
> need "TCP".
> 
> Introducing a TCP based solution requires:
> 
> a)A major change to the adjacency formation logic
> 
> b)Removal of the independence of the IS-IS protocol from the address families 
> whose reachability advertisements it supports - something which I think is a 
> great strength of the protocol - particularly in environments where multiple 
> address family support is needed
> 
> I really don't want to do either of the above.
> 
> Your comments regarding PSNP response times are quite correct - and both of 
> the draft proposals discuss this - though I agree more detail will be 
> required.
> It is intuitive that if you want to flood faster you also need to ACK faster 
> - and probably even retransmit faster when that is needed.
> The basic relationship between retransmit interval and PSNP interval is 
> expressed in ISO 10589:
> 
> " partialSNPInterval - This is the amount of time between periodic
> action for transmission of Partial Sequence Number PDUs.
> It shall be less than minimumLSPTransmission-Interval."
> 
> Of course ISO 10589 recommended values (2 seconds and 5 seconds respectively) 
> associated with a much slower flooding rate and implementations I am aware of 
> use values in this order of magnitude. These numbers need to be reduced if we 
> are to flood faster, but the relationship between the two needs to remain the 
> same.
> 
> It is also true - as you state - that sending ACKs more quickly will result 
> in additional PDUs which need to be received/processed by IS-IS - and this 
> has some impact. But I think it is reasonable to expect that an 
> implementation which can support sending and receiving LSPs at a faster rate 
> should also be able to send/receive PSNPs at a faster rate. But we still need 
> to be smarter than sending one PSNP/one LSP in cases where we have a burst.
> 
> LANs are a more difficult problem than P2P - and thus far 
> draft-ginsberg-lsr-isis-flooding-scale has been silent on this - but not 
> because we aren't aware of this - just have focused on the P2P behavior first.
> What the best behavior on a LAN may be is something I am still considering. 
> 

[Lsr] Research acitivity on IS-IS flooding

[bruno.decraene]

Hi all,

Following the meeting today, and the first results with existing algorithm, it 
would a priori be interesting to have simulations or implementations tests 
results on the proposed algorithms.

This email is a call to for info / contribution on this.

-  Do you know research team(s) which would have the required 
knowledge/capability?

-  Would you be interested in contributing (simulation or 
implementation or testing)?

-  Are you aware of open source IS-IS implementation(s) that could be 
used to implement this?

-  ...

Also I'm biased, I'd agree with John that this would make a good paper. With 
real interest from the industry, from both vendors and operators.

Thanks,
--Bruno

_

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

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Ø  ISIS flooding churn (and room for optimization) becomes a problem when node 
boots up (IMHO this is not a problem) and when node fails while having many 
neighbors attached. Yes maybe second case could be improved but well designed 
and operated network should have pre-programmed bypass paths against such cases 
so IMO stressing IGP to "converge" faster while great in principle may not be 
really needed in practice.


I don’t think that FRR is a replacement for “fast” (I’d rather say adequate) 
IGP convergence & flooding.

For multiple reasons such as:

-  Multiple ‘things’ depends on the IGP, such as BGP best path 
selection, CSPF/TE/PCE computations, FRR computations

-  Slow flooding increase the likelihood of multiple IGP SPF 
computations which is harmful for other computations which are typically 
heavier and manifolds (cf above)

-  Multiple IGP SPF computations also create multiple transient 
forwarding loops. There are some techniques to remove forwarding loops but this 
is still an advanced topic and some implementations do not handle consecutives 
IGP SPF (with ‘overlapping’ convergences and combined distributed forwarding 
loops)

-  For FRR, you mostly need to pre-decide/configure whether you want to 
protect link or node failures. Tradeoff are involved and given probability of 
events, link protection is usually enabled (hence not node protection)

-  …

Also, given the current “state of the art”, there is no stressing involved. 
Really. Using TCP, my 200€ mobile running on battery and over 
wifi+ADSL+Internet can achieve better communication throughput than a n*100k€ 
high end IS-IS router.
I think many persons agree that IS-IS could do better in term of flooding. 
(possibly not as good as a brand new approach, but incremental improvement also 
have some benefits). Eventually, we don’t need everyone to agree on this.



Ø  PS. Does anyone have a pointer to any real data showing that performance of 
real life WAN ISIS deployments is bad ?

In some of our ASes, we do monitor IS-IS by listening to and recording flooded 
LSPs. I can’t share any data.
Next question could be what is “good enough”. I guess this may depend on the 
size of your network, its topology, and your requirements.

We also ran tests in labs. I may share some results during my presentation. (no 
names, possibly no KPI, but some high level outcomes).

Regards,
Bruno


From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, April 24, 2020 12:42 PM
To: DECRAENE Bruno TGI/OLN
Cc: Tony Przygienda; Les Ginsberg (ginsberg); lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Hi Bruno  & all,

[Bruno] On my side, I’ll try once and I think the LSR WG should also try to 
improve IS-IS performance. May be if we want to move, we should first release 
the brakes.

Well from my observations releasing the breaks means increasing the risks.

Take BGP - breaks are off and see what happens :)

My personal observation is that ISIS implementations across vendors are just 
fine for vast majority of deployments today. That actually also includes vast 
majority of compute clusters as they consists of max 10s of racks.

Of course there are larger clusters with 1000+ or 10K and above network 
elements itself and x 20 L3 computes, but is there really a need to stretch 
protocol to accommodate those ? Those usually run BGP anyway. And also there is 
DV+LS hybrid too now.

ISIS flooding churn (and room for optimization) becomes a problem when node 
boots up (IMHO this is not a problem) and when node fails while having many 
neighbors attached. Yes maybe second case could be improved but well designed 
and operated network should have pre-programmed bypass paths against such cases 
so IMO stressing IGP to "converge" faster while great in principle may not be 
really needed in practice.

Last I am worried that when IETF defines changes to core protocol behaviour the 
quality of the implementations of those changes may really differ across 
vendors overall resulting in much worse performance and stability as compared 
to where we are today.

I am just not sure if possible gains for few deployments are greater then risk 
for 1000s of today's deployments. Maybe one size does not fit all and for 
massive scale ISIS we should define a notion of "ISIS-DC-PLUGIN" which can be 
optionally in run time added when/if needed. If that requires protocol changes 
to accommodate such dynamic plugins - that work should take place.

Many thx,
R.

PS. Does anyone have a pointer to any real data showing that performance of 
real life WAN ISIS deployments is bad ?


On Fri, Apr 24, 2020 at 11:26 AM 
mailto:bruno.decra...@orange.com>> wrote:
Tony

From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Thursday, April 23, 2020 7:29 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org; Les Ginsberg (ginsberg)
Subject: Re: [Lsr] Flow Control Discussion for 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Tony

From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Thursday, April 23, 2020 7:29 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org; Les Ginsberg (ginsberg)
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

I was refering to RFC4960. Bruno, for all practical purposes I think that seems 
to go down the path of trying to reinvent RFC4960 (or ultimately use it).
[Bruno] I don’t think that SCTP (RC4960) is a better fit than TCP. Many more 
features and options than TCP, way more than needed given existing IS-IS 
flooding mechanism. Much less implementations experience and improvement than 
TCP.
Or, changing the packet formats heavily to incorporate all the control loop 
data you need to the point you have a different control channel along those 
lines since you'll find most of the problems RFC4960 is describing (minus stuff 
like multiple paths).
[Bruno] Really, adding one sub-TLV in IS-IS is not “changing the packet formats 
heavily”.
Nothing wrong with that but it's ambitious on a 30 years old anitque artefact 
we're nursing forward here ;-)
[Bruno] I’m perfectly fine with revolution approaches. I think that we can also 
provide incremental improvement to IS-IS.
As entertaining footnote, I saw in last 20 years at least 3 attempts to allow 
multiple TCP sessions in BGP between peers to speed/prioritize things up. All 
failed, after the first one I helped to push I smarted up ;-)
 [Bruno] On my side, I’ll try once and I think the LSR WG should also try to 
improve IS-IS performance. May be if we want to move, we should first release 
the brakes. I’m seen some progress, e.g., from “there is no need to improve 
flooding” to “we all agree to improve flooding”, or from “Network operator just 
need to configure existing CLI” to “We agree that we need something more 
automated/dynamic”. But this has been very slow progress over a year.

--Bruno

As another footnote: I looked @ all the stuff in RIFT (tcp, quic, 4960, more 
ephemeral stuff). I ended up adding to rift bunch very rudimentary things and 
do roughly what Les/Peter/Acee started to write (modulo algorith I contributed 
and bunch things that would be helpful but we can't fit into existing packet 
format). This was as much decision as to "what's available & well debugged" as 
well as "does it meet requirements" as "how complex is that vs. rtx in flooding 
architecture  we have today + some feedback". Not on powerpoint, in real 
production code ;-) rift draft shows you the outcome of that as IMO best 
trade-off to achieve high flooding speeds ;-)

my 2c

-- tony

On Thu, Apr 23, 2020 at 10:15 AM 
mailto:bruno.decra...@orange.com>> wrote:
Tony,
Thanks for engaging.
Please inline [Bruno2]



From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 9:25 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org; Les Ginsberg (ginsberg)
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed



On Wed, Apr 22, 2020 at 11:03 AM 
mailto:bruno.decra...@orange.com>> wrote:
Tony, all,

Thanks Tony for the technical and constructive feedback.
Please inline [Bruno]

From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 1:19 AM
To: Les Ginsberg (ginsberg)
Cc: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

neither am I aware of anything like this (i.e. per platform/product flooding 
rate constants) in any major vendor stack for whatever that's worth. It's 
simply unmaintanable, point. All major vendors have extensive product lines 
over so many changing hardware configuration/setups it is simply not viable to 
attempt precise measurements (and even then, user changing config can throw the 
stuff off in a millisecond). There may have been here and there per deployment 
scenario some "recommended config" (not something I immediately recall either) 
but that means very fixed configuration of things & how they go into networks 
and even then I'm not aware of anyone having had a "precise model of the chain 
in the box". yes, probes to measure lots and lots of stuff in the boxes exist 
but again, those are chip/linecard/backplane/chassis/routing engine specific 
and mostly used in complex test/peformance scenarios and not to derive some 
kind of equations that can predict anything much ...
[Bruno] Good points.
Yet, one of the information that we propose to advertise by the LSP receiver to 
the LSP sender is the Receive Window.

-  This is a very common parameter and algorithm. Nothing fancy nor 
reinvented. In particular it’s a parameter used by TCP.

-  I would argue that TCP implementations also run on a variety of 
hardware and systems, must wider range than IS-IS platform. And those TCP 
implementations on all those platform manage to advertise this parameter (TCP 
window)

-  I fail to understand that when some WG 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Tony,
Thanks for engaging.
Please inline [Bruno2]



From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 9:25 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org; Les Ginsberg (ginsberg)
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed



On Wed, Apr 22, 2020 at 11:03 AM 
mailto:bruno.decra...@orange.com>> wrote:
Tony, all,

Thanks Tony for the technical and constructive feedback.
Please inline [Bruno]

From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 1:19 AM
To: Les Ginsberg (ginsberg)
Cc: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

neither am I aware of anything like this (i.e. per platform/product flooding 
rate constants) in any major vendor stack for whatever that's worth. It's 
simply unmaintanable, point. All major vendors have extensive product lines 
over so many changing hardware configuration/setups it is simply not viable to 
attempt precise measurements (and even then, user changing config can throw the 
stuff off in a millisecond). There may have been here and there per deployment 
scenario some "recommended config" (not something I immediately recall either) 
but that means very fixed configuration of things & how they go into networks 
and even then I'm not aware of anyone having had a "precise model of the chain 
in the box". yes, probes to measure lots and lots of stuff in the boxes exist 
but again, those are chip/linecard/backplane/chassis/routing engine specific 
and mostly used in complex test/peformance scenarios and not to derive some 
kind of equations that can predict anything much ...
[Bruno] Good points.
Yet, one of the information that we propose to advertise by the LSP receiver to 
the LSP sender is the Receive Window.

-  This is a very common parameter and algorithm. Nothing fancy nor 
reinvented. In particular it’s a parameter used by TCP.

-  I would argue that TCP implementations also run on a variety of 
hardware and systems, must wider range than IS-IS platform. And those TCP 
implementations on all those platform manage to advertise this parameter (TCP 
window)

-  I fail to understand that when some WG contributors proposed the use 
of TCP, nobody said that determining and advertising a Receive Window would be 
an issue, difficult or even impossible. But when we propose to advertise a 
Receive Window in an IS-IS TLV, this becomes difficult or even impossible for 
some platforms. Can anyone help me understand the technical difference?


Bruno, I was waiting for that ;-)
[Bruno2] Good ;-)

Discounted for the fact that I'm not a major TCP expert: TCP is a very 
different beast. it has a 100-200msec fast timer & 500msec slow (which have to 
be quite accurate, it's really one timer for all connections + mbuf and other 
magic) and it sends a _lot_ of packets back and forth with window size 
indications so the negotiation can happen very quickly.  Also, TCP can detect 
losses based on sequence number received contrary to routing protocols (that's 
one of the things we added in RIFT BTW) and it can retransmit quickly when it 
sees a "hole". Contrary to that in ISIS ACKs may or may not come, they may be 
bundled, hellos may or may not come and we can't retransmit stuff on 100msec 
timers either. It's an utterly different transport channel.
[Bruno2] I would distinguish two things, which I think we have done in 
https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-03

-  How fast you can adapt the sending rate. This seems mostly dependent 
on the speed of the feedback loop, rather than the format of message. E.g. In 
IS-IS the receiver can give a feedback more or less quickly (e.g. depending on 
how fast/bundled it sends the PSNP). In theory, I don’t see a major different. 
From an in implementation standpoint, I’m guessing that the difference is 
probably bigger (e.g. TCP is probably lower level/closer to the 
system/hardware, than IS-IS which is more user space and possibly Platform 
Independent in some organizations))

-  How fast you can detect packet loss. I agree that TCP & IS-IS are 
very different on this. We have proposed to improve this by allowing the 
receiver to advertise to the sender how fast it will ack the LSP. Currently the 
timer/behavior is known to receiver but no to the sender. Hence the sender 
needs to assume the wort case (ISO default).

In more abstract terms, TCP is a sliding N-window protocol (where N is adjusted 
all the time & losses can be efficiently detected) whereas LSR flooding is not 
a windowing protocol (or rather LSDB-size window protocol with selective 
retransmission but no detection of loss [or only very slow based on lack of ACK 
& CSNPs]). Disadvantage of something like TCP (I think I sent out the RFC with 
UDP control protocol work to make it more TCP like)
[Bruno2]  If you are referring to 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Peter,
 
> From: Peter Psenak [mailto:ppse...@cisco.com] 
> 
> Bruno,
> 
> On 22/04/2020 20:04, bruno.decra...@orange.com wrote:
> > Les,
> > 
> > Pleasesee inline
> > 
> > *From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> > *Sent:* Tuesday, April 21, 2020 11:48 PM
> > *To:* DECRAENE Bruno TGI/OLN
> > *Cc:* lsr@ietf.org
> > *Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed
> > 
> > Bruno –
> > 
> > You have made an assumption that historically vendors have tuned LSP 
> > transmission rates to a platform specific value.
> > 
> > [Bruno] I don’t think so. What makes you think so?
> > 
> > In all cases, that is not my assumption, and for multiple reasons.
> > 
> > That certainly is not true in the case of my employer (happy to hear 
> > what other vendors have been doing for the past 20 years).
> > 
> > The default value is based on minimumBroadcastLSPTransmissionInterval 
> > specified in ISO10589.
> > 
> > A knob is available to allow tuning (faster or slower) in a given 
> > deployment – though in my experience this knob is rarely used.
> > 
> > *//*[Bruno] I would agree on both. More interestingly is the why: why 
> > aren’t those existing sending parameters tuned, while we agree that 
> > default configuration are suboptimal?
> > 
> > My take is that:
> > 
> > -We don’t want to overload the receiver and create loss of LSP (as this 
> > will delay the LSDB synchronization and decrease the goodput). Hence 
> > this (the parameters) is receiver dependent (e.g., platform type, number 
> > of IGP adjacencies, …).
> > 
> > -We don’t know which value to configure : difficult for the network 
> > operator to evaluate without a significant knowledge of the receiver 
> > implementation (in particular QoS parameters for incoming LSP), vendors 
> > are not really proposing value or guidance, especially since the sending 
> > behavior is not standardized and slightly different between vendors. So 
> > everyone stay safe with default 20 years old values.
> > 
> > We already discuss in 
> > https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02#section-2
> >  
> > that this common interpretation isn’t the most appropriate, but 
> > historically the concern has been to avoid flooding too fast – not to 
> > optimize flooding speed.
> > 
> > Obviously, we are revisiting that approach and saying it needs to change 
> > – which is something I think we have consensus on.
> > 
> > I have provided a description in my recent response as to why it is 
> > difficult to derive an optimal value on a per platform basis. You may 
> > disagree – but please do not claim that we actually have been doing this 
> > for years. We haven’t been.
> > 
> > *//*[Bruno] I’m not sure how to rephrase my below email so that we could 
> > understand each other, have an answer from your side (I mean employer 
> > side), and progress.
> > 
> > More succinctly: How do network operator correctly configure the 
> > flooding parameters value on the implementation of your employer? In 
> > particular given the variety of conditions on the LSP receiver side.
> 
> the answer is test and see which value fits best in your specific 
> environment.

I don't think that's good enough, or even feasible given the very diverse set 
of platforms and environments in large networks, and/or the availability of 
human resources in smaller networks.
Since Les is reporting that virtually nobody is changing the default value 
-although we now all agree that they are suboptimal- I think that this is an 
indication that this strategy is not working.
That's why I brought this to the LSR WG.

We need the IS-IS protocol to work adequately without requiring constant or 
personalized tuning from the network operator. Coming back to TCP, general 
user/terminals are not been asked to run test per terminal and per 
destination/server. It just work relatively adequately.
 
> One reason to have some sort of feedback mechanism (being it tx or rx 
> based) is to avoid the need to tune today's static parameters and flood 
> as fast as the receiver is able to consume and slow down if the receiver 
> is not able to cope with the rate we flood.

+1
 
Thanks,
Bruno

> thanks,
> Peter
> 
> 
> 
> 
> 
> 
> > 
> > --Bruno
> > 
> >Les
> > 
> > *From:*bruno.decra...@orange.com 
> > *Sent:* Monday, April 20, 2020 4:47 AM
> > *To:* Les Ginsberg (ginsberg) 
> > *Cc:* lsr@ietf.org
> > *Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed
> > 
> > Les,
> > 
> > After nearly 2 months, can we expect an answer from your side?
> > 
> > More specifically, the below question
> > 
> > [Bruno] _Assuming_ that the parameters are static, the parameters 
> > proposed in draft-decraene-lsr-isis-flooding-speed are the same as the 
> > one implemented (configured) on multiple implementations, including the 
> > one from your employer.
> > 
> > Now do you believe that those parameters can be determined?
> > 
> > §  If yes, how do you do _today_ on your 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Les,

Please see inline

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, April 21, 2020 11:48 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed

Bruno -

You have made an assumption that historically vendors have tuned LSP 
transmission rates to a platform specific value.
[Bruno] I don't think so. What makes you think so?
In all cases, that is not my assumption, and for multiple reasons.

That certainly is not true in the case of my employer (happy to hear what other 
vendors have been doing for the past 20 years).

The default value is based on minimumBroadcastLSPTransmissionInterval specified 
in ISO10589.
A knob is available to allow tuning (faster or slower) in a given deployment - 
though in my experience this knob is rarely used.
[Bruno] I would agree on both. More interestingly is the why: why aren't those 
existing sending parameters tuned, while we  agree that default configuration 
are suboptimal?
My take is that:

-  We don't want to overload the receiver and create loss of LSP (as 
this will delay the LSDB synchronization and decrease the goodput). Hence this 
(the parameters) is receiver dependent (e.g., platform type,  number of IGP 
adjacencies, ...).

-  We don't know which value to configure : difficult for the network 
operator to evaluate without a significant knowledge of the receiver 
implementation (in particular QoS parameters for incoming LSP), vendors are not 
really proposing value or guidance, especially since the sending behavior is 
not standardized and slightly different between vendors. So everyone stay safe 
with default 20 years old values.

We already discuss in 
https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02#section-2 
that this common interpretation isn't the most appropriate, but historically 
the concern has been to avoid flooding too fast - not to optimize flooding 
speed.
Obviously, we are revisiting that approach and saying it needs to change - 
which is something I think we have consensus on.

I have provided a description in my recent response as to why it is difficult 
to derive an optimal value on a per platform basis. You may disagree - but 
please do not claim that we actually have been doing this for years. We haven't 
been.
[Bruno] I'm not sure how to rephrase my below email so that we could understand 
each other, have an answer from your side (I mean employer side), and progress.
More succinctly: How do network operator correctly configure the flooding 
parameters value on the implementation of your employer? In particular given 
the variety of conditions on the LSP receiver side.

--Bruno

  Les

From: bruno.decra...@orange.com 
Sent: Monday, April 20, 2020 4:47 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed

Les,

After nearly 2 months, can we expect an answer from your side?

More specifically, the below question

[Bruno] _Assuming_ that the parameters are static, the parameters proposed in 
draft-decraene-lsr-isis-flooding-speed are the same as the one implemented 
(configured) on multiple implementations, including the one from your employer.
Now do you believe that those parameters can be determined?

§  If yes, how do you do _today_ on your implementation? (this seems to 
contradict your statement that you have no way to figure out how to find the 
right value)

§  If no, why did you implement those parameters, and ask network operator to 
configure them?


Thank you,
--Bruno

From: DECRAENE Bruno TGI/OLN
Sent: Wednesday, February 26, 2020 8:03 PM
To: 'Les Ginsberg (ginsberg)'
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed

Les,

Please see inline[Bruno]

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, February 19, 2020 3:32 AM
To: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Base protocol operation of the Update process tracks the flooding of
LSPs/interface and guarantees timer-based retransmission on P2P interfaces
until an acknowledgment is received.

Using this base protocol mechanism in combination with exponential backoff of 
the
retransmission timer provides flow control in the event of temporary overload
of the receiver.

This mechanism works without protocol extensions, is dynamic, operates
independent of the reason for delayed acknowledgment (dropped packets, CPU
overload), and does not require additional signaling during the overloaded
period.

This is consistent with the recommendations in RFC 4222 (OSPF).

Receiver-based flow control (as proposed in 
https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ )
requires protocol extensions and introduces additional signaling during
periods of high load. The asserted reason for this is to optimize throughput -
but there is no evidence 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Tony, all,

Thanks Tony for the technical and constructive feedback.
Please inline [Bruno]

From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 1:19 AM
To: Les Ginsberg (ginsberg)
Cc: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

neither am I aware of anything like this (i.e. per platform/product flooding 
rate constants) in any major vendor stack for whatever that's worth. It's 
simply unmaintanable, point. All major vendors have extensive product lines 
over so many changing hardware configuration/setups it is simply not viable to 
attempt precise measurements (and even then, user changing config can throw the 
stuff off in a millisecond). There may have been here and there per deployment 
scenario some "recommended config" (not something I immediately recall either) 
but that means very fixed configuration of things & how they go into networks 
and even then I'm not aware of anyone having had a "precise model of the chain 
in the box". yes, probes to measure lots and lots of stuff in the boxes exist 
but again, those are chip/linecard/backplane/chassis/routing engine specific 
and mostly used in complex test/peformance scenarios and not to derive some 
kind of equations that can predict anything much ...
[Bruno] Good points.
Yet, one of the information that we propose to advertise by the LSP receiver to 
the LSP sender is the Receive Window.

-  This is a very common parameter and algorithm. Nothing fancy nor 
reinvented. In particular it’s a parameter used by TCP.

-  I would argue that TCP implementations also run on a variety of 
hardware and systems, must wider range than IS-IS platform. And those TCP 
implementations on all those platform manage to advertise this parameter (TCP 
window)

-  I fail to understand that when some WG contributors proposed the use 
of TCP, nobody said that determining and advertising a Receive Window would be 
an issue, difficult or even impossible. But when we propose to advertise a 
Receive Window in an IS-IS TLV, this becomes difficult or even impossible for 
some platforms. Can anyone help me understand the technical difference?

Bruno, if you're so deeply interested in that stuff we can talk 1:1 off-line 
about implementation work on rift towards adapatable flooding rate
[Bruno] Sure. My pleasure. Please propose me some timeslot offline. Please note 
that I’m based in Europe (CEST), so a priori during your morning and my evening.
If you can also extend the offer to discuss the implementation work on the 
IS-IS implementation of your employer with regards to adaptable flooding rate, 
and/or how network operator can configure the CLI parameters of the LSP senders 
so as to improve flooding rate without overloading the Juniper receiver 
(possibly depending on the capability of the receiver, its number of IS-IS 
neighbors… and/or whatever parameter that you feel are relevant) that would be 
most appreciated. And if you believe that the Juniper LSP receiver can handle 
any rate from any reasonable (e.g. 50)  number of IGP neighbors, without 
(significantly) dropping the received LSPs, that would be even simpler, please 
advise.

--Bruno
(algorithm you see in the -02 draft Les put out is a _very rough_ approximation 
of that BTW. I joined as co-author after we had some very fruitful discussions 
and I consider the draft close to what can be _realistically_ done  today in 
ISIS. I don't consider further details generic enough to merit wide forum 
discussions). And RIFT put a couple of things into packet formats we can't put 
into ISIS (I talked with Les about it) to improve the adaptability of the 
flooding rate BTW and some interesting, coarse indication from receiver. Again, 
this is not a constant that is calculated, it's all adaptive driven almost 
completely from the transmitter side and the feedback it gathers.

all my very own 2c

-- tony

On Tue, Apr 21, 2020 at 2:48 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Bruno –

You have made an assumption that historically vendors have tuned LSP 
transmission rates to a platform specific value.
That certainly is not true in the case of my employer (happy to hear what other 
vendors have been doing for the past 20 years).

The default value is based on minimumBroadcastLSPTransmissionInterval specified 
in ISO10589.
A knob is available to allow tuning (faster or slower) in a given deployment – 
though in my experience this knob is rarely used.

We already discuss in 
https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02#section-2 
that this common interpretation isn’t the most appropriate, but historically 
the concern has been to avoid flooding too fast – not to optimize flooding 
speed.
Obviously, we are revisiting that approach and saying it needs to change – 
which is something I think we have consensus on.

I have provided a description in my recent response as to 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Les,

Thank you for this first answer. This is inline with my understanding of the 
behavior.
I wish some of the behaviors and values (e.g. queue size, rate limiting) could 
be shared. At minimum a range of typical values for platform which are not end 
of sale. I don't think this is secret. Actually, this is something that network 
provider would need in order to configure the right value for the parameters 
which are implemented on the platforms of your employer, so this should be on 
the public documentation of your employer. One could also think that you may be 
proud of your implementations and eager to show that it performs well.

Waiting some more details, as per you below email, the IS-IS receiver does have 
a queue, sometimes dedicated to IS-IS, but in general relatively dedicated to 
very important and time sensitive traffic to the control plane. Details are 
indeed implementation specific. But in general, this queue is designed to 
protect the IS-IS traffic from lower priority traffic, e.g. bursty BGP. So can 
we assume that the receiver have (or at least may have) such a queue, and work 
with this?

--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, April 17, 2020 10:41 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed

Bruno -

Returning to this old thread...

The following is a generic description of how receive path for IS-IS PDUs 
functions today - based on examination of implementations on a variety of 
platforms from my employer. It is, for obvious reasons,  generic and 
intentionally omits any discussion of implementation details.
But it is hopefully detailed enough to illustrate some of the challenges in 
regards to providing real-time  accurate feedback to the control plane that 
could be used by a receiver based flow control mechanism.

Stage 1: Input Policing

As a first step, a policer operates at ingress to rate limit the number of 
packets which will be punted for local processing. This typically operates in 
an interface independent manner - limiting the total number of packets per 
second across all interfaces.
The policer may rate limit different classes of packets or simply limit all 
types of packets. A given platform may apply a limit specific to IS-IS PDUs or 
apply a limit to a class of packets (e.g., OSPF+BGP+IS-IS combined).

Stage 2: Punt Queue Shaping

Received packets are then placed in a queue for eventual transfer to the 
control plane. The number of queues varies. In some cases a single queue for 
all packet types is used. In other cases packets are placed on different queues 
based on packet classes.
Each queue is typically bounded to a maximum number of packets. As the queue 
usage approaches a limit, shaping policies are applied to prioritize certain 
packet types over others.
An upper limit specific to IS-IS packets may be employed - or a limit may be 
applied to a larger class of packet types of which IS-IS is only one of the 
packet types in the class.

Stage 3: Transfer to control Plane

Packets are then transferred to the control plane. Control plane input queues 
may map 1-1 with the data plane queues or map many to 1.
If the incoming packets are encapsulated (for example GRE) they may be 
transferred to a media specific control plane queue to process the 
encapsulation header. In some cases encapsulation may be processed in the data 
plane prior to transfer to the control plane.

Stage 4: Transfer to IS-IS

Packets are then transferred to a queue which is read directly by IS-IS. In the 
event there are multiple IS-IS instances, implementations may choose to have a 
shared queue which drives the execution of all instances or have instance 
specific queues filtered based on incoming interface.

A single queue is typically used for all interfaces and all IS-IS packet types. 
Subsequent processing may requeue packets based on packet type e.g., separating 
processing of hellos from processing of LSPs/SNPs.

*

A receiver based flow control mechanism which attempts to make dynamic 
adjustments needs to obtain real-time feedback from one or more of the above 
stages. Monitoring the state of the input queue to IS-IS is easy to do, but 
would not account for drops at previous stages.
Obtaining feedback from earlier stages requires real-time updates from data 
plane to IS-IS in the control plane. This is much more challenging. 
Idiosyncrasies of platforms will have a significant impact on how to 
meaningfully interpret and use the data. How to integrate data from the various 
stages - especially when the numbers are not specific to IS-IS packets - is not 
intuitive.

https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-03 provides 
no guidance on how information from the dataplane could be used.
As an alternative, it suggests that static parameters derived from offline 
tests could be advertised. But static parameters would necessarily have to be 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Les,

After nearly 2 months, can we expect an answer from your side?

More specifically, the below question

[Bruno] _Assuming_ that the parameters are static, the parameters proposed in 
draft-decraene-lsr-isis-flooding-speed are the same as the one implemented 
(configured) on multiple implementations, including the one from your employer.
Now do you believe that those parameters can be determined?

§  If yes, how do you do _today_ on your implementation? (this seems to 
contradict your statement that you have no way to figure out how to find the 
right value)

§  If no, why did you implement those parameters, and ask network operator to 
configure them?


Thank you,
--Bruno

From: DECRAENE Bruno TGI/OLN
Sent: Wednesday, February 26, 2020 8:03 PM
To: 'Les Ginsberg (ginsberg)'
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed

Les,

Please see inline[Bruno]

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, February 19, 2020 3:32 AM
To: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Base protocol operation of the Update process tracks the flooding of
LSPs/interface and guarantees timer-based retransmission on P2P interfaces
until an acknowledgment is received.

Using this base protocol mechanism in combination with exponential backoff of 
the
retransmission timer provides flow control in the event of temporary overload
of the receiver.

This mechanism works without protocol extensions, is dynamic, operates
independent of the reason for delayed acknowledgment (dropped packets, CPU
overload), and does not require additional signaling during the overloaded
period.

This is consistent with the recommendations in RFC 4222 (OSPF).

Receiver-based flow control (as proposed in 
https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ )
requires protocol extensions and introduces additional signaling during
periods of high load. The asserted reason for this is to optimize throughput -
but there is no evidence that it will achieve this goal.

Mention has been made to TCP-like flow control mechanisms as a model - which
are indeed receiver based. However, there are significant differences between
TCP sessions and IGP flooding.

TCP consists of a single session between two endpoints. Resources
(primarily buffer space) for this session are typically allocated in the
control plane and current usage is easily measurable..

IGP flooding is point-to-multi-point, resources to support IGP flooding
involve both control plane queues and dataplane queues, both of which are
typically not per interface - nor even dedicated to a particular protocol
instance. What input is required to optimize receiver-based flow control is not 
fully specified.

https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ 
suggests (Section 5) that the values
to be advertised:

"use a formula based on an off line tests of
   the overall LSPDU processing speed for a particular set of hardware
   and the number of interfaces configured for IS-IS"

implying that the advertised value is intentionally not dynamic. As such,
it could just as easily be configured on the transmit side and not require
additional signaling. As a static value, it would necessarily be somewhat
conservative as it has to account for the worst case under the current
configuration - which means it needs to consider concurrent use of the CPU
and dataplane by all protocols/features which are enabled on a router - not all 
of whose
use is likely to be synchronized with peak IS-IS flooding load.
[Bruno] _Assuming_ that the parameters are static, those parameters

o   are the same as the one implemented (configured) on multiple 
implementations, including the one from your employer. Now do you believe that 
those parameters can be determined?

§  If yes, how do you do _today_ on your implementation? (this seems to 
contradict your statement that you have no way to figure out how to find the 
right value)

§  If no, why did you implement those parameters, and ask network operator to 
configure them?

§  There is also the option to reply: I don't know but don't care as I leave 
the issue to the network operator.

o   can still provide some form of dynamicity, by using the PSNP as dynamic 
acknowledgement.

o   are really dependent on the receiver, not the sender.

§  the sender will never overload itself.

§  The receiver has more information,  knowing its processing power (low end, 
high end, 80s, 20s (currently we are stuck with 20 years old value assuming the 
worst possible receiver (and worst there were, including with packet processing 
partly done in the control plane processor)), its expected IS-IS load 
(#neighbors), its preference for bursty LSP reception (high delay between IS-IS 
CPU allocation cycles, memory not an issue up to x kilo-octet...), its expected 
control plane load if IS-IS traffic has not higher priority over other control 

Re: [Lsr] problem joining interim [Re: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02]

[bruno.decraene]

Chris, 

Please see inline.


> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Friday, April 3, 2020 12:00 AM
> To: Robert Raszuk
> 
> 
> 
> > On Apr 2, 2020, at 5:17 PM, Robert Raszuk  wrote:
> > 
> > Many thx,
> > R.
> > 
> > PS. As we are talking LSR here it is strange that joining virtual LSR 
> > meeting is not for everyone. I was waiting and tried three times today for 
> > host approval to join which was not granted. 
> > 
> 
> I am very sorry to hear this! We had 64 participants, at least at one point 
> that I saw. I set the meeting up, and I don't believe there is any way to 
> exclude anyone in particular, I certainly would never have chosen to do that.
> 
> However, Webex has a password requirement when setting up meetings (I guess, 
> I tried to not have one, it wouldn't let me) which we included in all the 
> details wherever the details were posted, it was "linkstate".
> 
> I did notice an email, from webex, during the meeting about a request from 
> Bruno to join as guest, but he was in the participant list when I then 
> checked.
> 

So may be my experience may help for next time(s). See below.

An email from the IESG secretary was sent on 2020-03-19, saying "Information 
about remote participation: https://ietf.webex.com/meet/lsr "
Hence I used that URL.
On this webex, the meeting did not start on time so I've waited for some time. 
Then 10-15 minutes past the start, I decided to 'notify the host', but never 
got accepted on the webex.
At that point I assumed a technical issue with webex and monitored the mailing 
list, but no one was complaining, which is not inline with typical IETF 
reaction ;-) .
So I assumed the error was only on my side and I searched for more emails and 
found one from Chris (2020-03-31) saying that the URL was 
https://ietf.webex.com/ietf/j.php?MTID=mbef20efa9e66c7e97f9d6b18ea84eca8 
And this one worked fine.
My guess is that the 'interim' webex did not use the 'lsr' webex. Also the 
'official' notification from the IESG secretary with the incorrect webex URL 
did not helped.

--Bruno
 
> I didn't receive any other emails like that (and FWIW I had 5 windows over 2 
> monitors going at once trying to manage all this, so noticing the 1 email was 
> lucky).
> 
> Did it let you skip entering a password (or did it not offer the option in 
> the first place)?
> 
> It would be good to figure this out before the next interim.
>
> Thanks,
> Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

_

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

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

With regards to punting to TCP, I think that TCP (stacks) enforce packet 
ordering.
i.e. if you receive packets 1, 3,4, …,N, then you can only use packet 1 until 
you receive packet 2. In the meantime, you cannot use the (N-2) packets that 
you did received.
That seems like a regression for IS-IS which doesn’t requiring LSPs ordering. 
(vs BGP).

Also, from what I’ve been told from BGP implementers, TCP is not magic and 
can’t be treated as a black box (if you want scale/performance).

1 cent
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Tony Przygienda
Sent: Tuesday, March 10, 2020 4:23 PM
To: Christian Hopps
Cc: lsr@ietf.org; tony...@tony.li; Tony Li; Peter Psenak (ppsenak)
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Hey Christian, MaxTX is not that hard to derive since it's basically limited by 
the local system and its CPU/prioritization/queing architecture.

For the rest of your email, in short, you have my observations in the previous 
email what I think is useful and can be done ... BTW, timestamps are useless 
unless you synchronize clocks and with all the queing that ISIS does through 
the system normally to get stuff done it is very hard to account for delays 
between packet being generated (or rx'ed on interface) and last queue it's 
pulled from usually. More musings below backed by good amount of work & 
empirical experience ;-)

If we try to punt to TCP (like BGP did in its time which I argued wasn't the 
optimal idea that has bitten us back endless amount of times for the shortcut 
it was ;-) then de facto, no real heavy duty IP box is using stock TCP stack, 
at least in the scope of experience I have across bunch of leading vendors. If 
you worked on mod'ing TCP for convergence speed with BGP and cute little things 
like GR/NSR you will know the practical problems and also why stock TCP is 
actually fairly underwhelming when it comes to push large amounts of control 
data around (mod' distro, mod rusty 2c, mod etc but that's my data)..

And agreed, control theory is a wonderful thing and transfer windowing 
protocols etc are long research if you know where to look and lots of the stuff 
is e.g. present in TCP, QUIC or https://tools.ietf.org/html/rfc4340 and so on. 
All of them are quite a lot of stuff to put into ISIS/link-state and mostly do 
not do precisely what we need or precondition things we can't afford under 
heavy load (very fast, non slip timers which are absolutely non trivial if 
you're not in kernel). On top of that you'd need to drag 2 protocol transports 
around now with old ISIS flooding with RE-TX and and the new thing that should 
be doing the stuff by itself (and negotiate transport on top and so on). To 
give you a rought idea DDCP which is probably smallest is ~ 10KLOC of C in user 
space in BETA and zero docs ;-) I looked @ the practically existing stuff 2+ 
years ago in detail when doing RIFT ;-) and with all what I practically found I 
ended up carving out the pieces we need for fast flooding without introducing 
fast-acks which IMO would be a non-starter for high scale link-state or rather, 
if we really want that, the loop closes and we should go practically speaking 
to TCP (or 4340 which looked like a better choice to me but  just like e.g. 
Open-R did and be done with it) or wait for the mythical QUIC 
all-singing-all-dancing public domain implementation maybe. For many reasons I 
do not think it would be a particularly good development entangling a control 
protocol again with a user transport in the whole ball of yarn that IP is 
already.

kind of all I had to say, next thing ;-)

--- tony

On Tue, Mar 10, 2020 at 7:48 AM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> writes:

> Tony –
>
> If you have a suggestion for Tx back-off algorithm please feel free to share.
> The proposal in the draft is just a suggestion.
> As this is a local matter there is no interoperability issue, but certainly 
> documenting a better algorithm is worthwhile.

[as WG member]

The main thing I'm afraid of is we're just making up some new overly simple 
congestion control algorithm (are there CC experts reviewing this?); maybe 
simulate it a few ways, deploy it, and have it work poorly or make things 
worse. In any case, damn the torpedos...

In this current algorithm how does MaxLSPTx get set? What happens if MaxLSPTx 
is too high? If its too low we could be missing a much faster convergence 
capability.

What if we had more quality information from the receiver, could we do a better 
job here? Maybe faster ACKs, or could we include a timestamp somehow to 
calculate RTT? This is the type of data that is used by existing CC algorithms 
(https://tools.ietf.org/html/rfc4342, https://tools.ietf.org/html/rfc5348). Of 
course going through these documents (which I've had to do for in another area) 
can start making one think "Punt to TCP" :)

What would be nice, if we're going to attempt 

[Lsr] New Version Notification for draft-decraene-lsr-isis-flooding-speed-03.txt

[bruno.decraene]

Hi all,

Following many interesting discussions on the mailing list, during IETF 
meetings 105 & 106 and of-list, please find below an updated version. 

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-decraene-lsr-isis-flooding-speed-03

Main changes are:
   Flooding Parameters TLV: name changed, advertised in both Hello and SNP 
rather than just Hello, contains sub-TLVs, parameters encoded in 4 octets.
   Terminology: upstream/downstream terms removed, in favor of terms from ISO 
specification (transmitter, receiver); burst-size rename to receive-window.
   Significant editorials changes.
   New section on the faster acknowledgment of LSPs.
   New section on the faster retransmission of lost LSPs.


Comments are welcomed.

Thank you,
Regards,
--Bruno on behalf of all co-authors

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, March 9, 2020 3:11 PM
To: Jayesh J; Tony Li; Chris Bowers; Gunter Van de Velde; DECRAENE Bruno TGI/OLN
Subject: New Version Notification for 
draft-decraene-lsr-isis-flooding-speed-03.txt


A new version of I-D, draft-decraene-lsr-isis-flooding-speed-03.txt
has been successfully submitted by Bruno Decraene and posted to the
IETF repository.

Name:   draft-decraene-lsr-isis-flooding-speed
Revision:   03
Title:  IS-IS Flooding Parameters advertisement
Document date:  2020-03-09
Group:  Individual Submission
Pages:  13
URL:
https://www.ietf.org/internet-drafts/draft-decraene-lsr-isis-flooding-speed-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
Htmlized:   
https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-decraene-lsr-isis-flooding-speed-03

Abstract:
   This document proposes a mechanism that can be used to increase the
   speed at which link state information is exchanged between two
   routers when multiple LSPs need to be flooded, such as in case of a
   node failure.  It also reduces the likelihood of overloading the
   router receiving the LSPs.  This document defines a new TLV to be
   advertised in SNP and or Hello messages.  This TLV may carry a set of
   parameters indicating the performance capacity to receive LSPs: the
   number of LSPs which can the received back to back, the minimum delay
   between further two consecutive LSPs and the minimum delay before
   retransmission of an LSP.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_

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

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

Hi Ketan,

Thanks fort the follow up.
Clarification inline [Bruno]

From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Friday, February 28, 2020 11:11 AM
To: DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
Cc: lsr@ietf.org; SPRING WG List; draft-ietf-spring-srv6-network-programming; 
Peter Psenak (ppsenak)
Subject: RE: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Hi Bruno,

I believe the description and usage of Locator is very well described and 
covered in the net-pgm draft as also the corresponding IGP extensions. Is the 
question is more about the “block” part of it (what is not in the block part is 
in the node part as per the text in the net-pgm draft)?

The “block” is again not a new thing. Please check the following:
Under 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5 
… look for “block”
https://tools.ietf.org/html/rfc8402#section-2 … look under SRGB for SRv6

[Bruno]
To clarify, my question was not specific to “block” but related to the usage, 
by the receiver, of the following piece of information:

  LB Length: SRv6 SID Locator Block length
  LN Length: SRv6 SID Locator Node length
  Fun. Length: SRv6 SID Function length
  Arg. Length: SRv6 SID Arguments length


So perhaps I don’t get Chris’s point and would wait for him to clarify.
[Bruno] I’ll leave this to Chris.

Thanks,
Ketan

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: 28 February 2020 14:34
To: Ketan Talaulikar (ketant) ; Chris Bowers 

Cc: lsr@ietf.org; SPRING WG List ; 
draft-ietf-spring-srv6-network-programming 
; Peter Psenak (ppsenak) 

Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Hi Ketan,



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, February 28, 2020 6:30 AM

Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol 
specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says 
what locator block and locator node are. What more details do you think are 
required?

[Bruno] Speaking as an individual, the draft could possibly clarify the usage 
of these information/fields by the receiver. Possibly using the same name/term 
(e.g. SRv6 SID Locator Block length) to ease the references between both drafts.

Thanks,
--Bruno

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
mailto:spr...@ietf.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Subject: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

SPRING and LSR WGs,

I think that we need a much more detailed description of the locator block and 
locator node in either draft-ietf-spring-srv6-network-programming or 
draft-ietf-lsr-isis-srv6-extensions.  See original email below.

Thanks,
Chris

On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Chris,

On 27/02/2020 17:54, Chris Bowers wrote:
> LSR WG,
>
> Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6
> SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> locator block length and the locator node length.  The text refers to
> [I-D.ietf-spring-srv6-network-programming] for the definition of these
> concepts.
>
> As far as I can tell, the only reference to locator block and locator
> node in draft-ietf-spring-srv6-network-programming-10 is section 3.1
> which has the following text:
>
> A locator may be represented as B:N where B is the SRv6 SID block
> (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
> identifier of the parent node instantiating the SID..
>
> I think that we need a much more detailed description of the locator
> block and locator node.

sure, but that would be in the
draft-ietf-spring-srv6-network-programming-10, not in
draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol
specific constructs.

thanks,
Peter

>
> Thanks,
>
> Chris
>

_



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 

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

Hi Ketan,



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, February 28, 2020 6:30 AM


Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol 
specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says 
what locator block and locator node are. What more details do you think are 
required?

[Bruno] Speaking as an individual, the draft could possibly clarify the usage 
of these information/fields by the receiver. Possibly using the same name/term 
(e.g. SRv6 SID Locator Block length) to ease the references between both drafts.

Thanks,
--Bruno

Thanks,
Ketan

From: Lsr  On Behalf Of Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
Cc: Peter Psenak (ppsenak) 
Subject: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

SPRING and LSR WGs,

I think that we need a much more detailed description of the locator block and 
locator node in either draft-ietf-spring-srv6-network-programming or 
draft-ietf-lsr-isis-srv6-extensions.  See original email below.

Thanks,
Chris

On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Chris,

On 27/02/2020 17:54, Chris Bowers wrote:
> LSR WG,
>
> Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6
> SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> locator block length and the locator node length.  The text refers to
> [I-D.ietf-spring-srv6-network-programming] for the definition of these
> concepts.
>
> As far as I can tell, the only reference to locator block and locator
> node in draft-ietf-spring-srv6-network-programming-10 is section 3.1
> which has the following text:
>
> A locator may be represented as B:N where B is the SRv6 SID block
> (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
> identifier of the parent node instantiating the SID..
>
> I think that we need a much more detailed description of the locator
> block and locator node.

sure, but that would be in the
draft-ietf-spring-srv6-network-programming-10, not in
draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol
specific constructs.

thanks,
Peter

>
> Thanks,
>
> Chris
>

_

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

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Les,

Please see inline[Bruno]

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, February 19, 2020 3:32 AM
To: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Base protocol operation of the Update process tracks the flooding of
LSPs/interface and guarantees timer-based retransmission on P2P interfaces
until an acknowledgment is received.

Using this base protocol mechanism in combination with exponential backoff of 
the
retransmission timer provides flow control in the event of temporary overload
of the receiver.

This mechanism works without protocol extensions, is dynamic, operates
independent of the reason for delayed acknowledgment (dropped packets, CPU
overload), and does not require additional signaling during the overloaded
period.

This is consistent with the recommendations in RFC 4222 (OSPF).

Receiver-based flow control (as proposed in 
https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ )
requires protocol extensions and introduces additional signaling during
periods of high load. The asserted reason for this is to optimize throughput -
but there is no evidence that it will achieve this goal.

Mention has been made to TCP-like flow control mechanisms as a model - which
are indeed receiver based. However, there are significant differences between
TCP sessions and IGP flooding.

TCP consists of a single session between two endpoints. Resources
(primarily buffer space) for this session are typically allocated in the
control plane and current usage is easily measurable..

IGP flooding is point-to-multi-point, resources to support IGP flooding
involve both control plane queues and dataplane queues, both of which are
typically not per interface - nor even dedicated to a particular protocol
instance. What input is required to optimize receiver-based flow control is not 
fully specified.

https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ 
suggests (Section 5) that the values
to be advertised:

"use a formula based on an off line tests of
   the overall LSPDU processing speed for a particular set of hardware
   and the number of interfaces configured for IS-IS"

implying that the advertised value is intentionally not dynamic. As such,
it could just as easily be configured on the transmit side and not require
additional signaling. As a static value, it would necessarily be somewhat
conservative as it has to account for the worst case under the current
configuration - which means it needs to consider concurrent use of the CPU
and dataplane by all protocols/features which are enabled on a router - not all 
of whose
use is likely to be synchronized with peak IS-IS flooding load.
[Bruno] _Assuming_ that the parameters are static, those parameters

o   are the same as the one implemented (configured) on multiple 
implementations, including the one from your employer. Now do you believe that 
those parameters can be determined?

§  If yes, how do you do _today_ on your implementation? (this seems to 
contradict your statement that you have no way to figure out how to find the 
right value)

§  If no, why did you implement those parameters, and ask network operator to 
configure them?

§  There is also the option to reply: I don't know but don't care as I leave 
the issue to the network operator.

o   can still provide some form of dynamicity, by using the PSNP as dynamic 
acknowledgement.

o   are really dependent on the receiver, not the sender.

§  the sender will never overload itself.

§  The receiver has more information,  knowing its processing power (low end, 
high end, 80s, 20s (currently we are stuck with 20 years old value assuming the 
worst possible receiver (and worst there were, including with packet processing 
partly done in the control plane processor)), its expected IS-IS load 
(#neighbors), its preference for bursty LSP reception (high delay between IS-IS 
CPU allocation cycles, memory not an issue up to x kilo-octet...), its expected 
control plane load if IS-IS traffic has not higher priority over other control 
plane traffic...), it's expected level of QoS prioritization [1]

·  [1] looks for "Extended SPD Headroom". E.g. "Since IGP and link 
stability are more tenuous and more crucial than BGP stability, such packets 
are now given the highest priority and are given extended SPD headroom with a 
default of 10 packets. This means that these packets are not dropped if the 
size of the input hold queue is lower than 185 (input queue default size + spd 
headroom size + spd extended headroom)."

o   And this is for distributed architecture, 15 years ago. So what about using 
the above number (in the router configuration), applies Tony's proposal 
(*oversubscription/number of IS neighbhors), and advertise this value to your 
LSP sender?



[1] 
https://www.cisco.com/c/en/us/support/docs/routers/12000-series-routers/29920-spd.html


-
--Bruno


Unless a good case 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Les,


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, February 19, 2020 6:49 PM
To: Robert Raszuk
Cc: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Robert –

Thanx for your input.

Note that one of the suggestions in 
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/  is to 
prioritize the reception of SNPs over LSPs so that we are less likely to drop 
ACKs.
It is not clear to me why you think SNP generation would be an issue.
Once a received LSP is processed one of the outputs is to set a per interface 
flag indicating that an ACK (PSNP) needs to be sent (SSN flag). Implementations 
usually implement some small delay so that multiple ACKs can be sent in a 
single PSNP – but I do not see why this should be viewed as a bottleneck.

If your concern is that we need to emphasize the importance of sending timely 
ACKs, I think we could look at text that makes that point.
[Bruno]
So you need a new behavior on the Rx side (Rx with respect to LSP).  This is 
_not_ Tx only with no need for protocol change.
And BTW, this is called a feedback from the Rx to the Tx.

As we change the protocol on the Rx side, we have the opportunity to report 
more information from Rx to the Tx.

--Bruno

   Les


From: Lsr  On Behalf Of Robert Raszuk
Sent: Wednesday, February 19, 2020 1:07 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Hi Les & all,

Watching this discussion I would like to state that IMO going with transmitter 
based rate limiting (I would not call it flow control) is much easier option to 
deploy and operate. It also has no dependency across other side of p2p adj 
which is a very important factor. The only issue here is if generation of 
[P|C]SNPs is fast enough.

Receiver based flow control is simple in flow theory however I have a feeling 
that if we are to go that path we would be much better to actually run ISIS 
flooding over DC-TCP and avoid reinventing the wheel.

Thx,
Robert.

On Wed, Feb 19, 2020 at 3:26 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Two recent drafts advocate for the use of faster LSP flooding speeds in IS-IS:

https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/

There is strong agreement on two key points:

1)Modern networks require much faster flooding speeds than are commonly in use 
today

2)To deploy faster flooding speeds safely some form of flow control is needed

The key point of contention between the two drafts is how flow control should 
be implemented.

https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ 
advocates for a receiver based flow control where the receiver advertises in 
hellos the parameters which indicate the rate/burst size which the receiver is 
capable of supporting on the interface. Senders are required to limit the rate 
of LSP transmission on that interface in accordance with the values advertised 
by the receiver.

https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/  
advocates for a transmit based flow control where the transmitter monitors the 
number of unacknowledged LSPs sent on each interface and implements a backoff 
algorithm to slow the rate of sending LSPs based on the length of the per 
interface unacknowledged queue.

While other differences between the two drafts exist, it is fair to say that if 
agreement could be reached on the form of flow control  then it is likely other 
issues could be resolved easily.

This email starts the discussion regarding the flow control issue.



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

_

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

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

> From: Peter Psenak [mailto:ppse...@cisco.com] 
> 
> Hi Bruno,
> 
> On 28/01/2020 18:05, bruno.decra...@orange.com wrote:
> > Hi Peter,
> > 
> > Thank you.
> > Looks good.
> > 
> > Just one follow up
> > 
> >>> §9
> >>>
> >>> A priori the sum of all 4 sizes must be 128 bits. Could you specify the
> >>> error handling when this is not the case? (a choice could be to ignore
> >>> this Sub-Sub-TLV; but given the error handling specified for another
> >>> error, you seem to prefer to ignore the whole parent TLV.
> >>
> >> ##PP
> >> the sum may not need to be 128, some fields may be advertised as 0 -
> >> e.g. not all SIDs have arguments.
> > 
> > You are correct.
> > Let me rephrase:
> > 
> > A priori the sum of all 4 sizes must be lower or equal 128 bits.
> > Could you specify the error handling when this is not the case?
> > Especially since there seem to be two possible responses:
> > a) ignore this Sub-Sub-TLV
> > b) ignore the whole parent TLV (as specified for another error condition)
> 
> I would go for (b) and ignore the parent sub-TLV.
> Will update accordingly.

Thank you Peter.

--Bruno

> thanks,
> Peter
> 
> 
> 
> > 
> > Thank you
> > --Bruno
> > 
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Monday, January 27, 2020 1:43 PM
> >> To: DECRAENE Bruno TGI/OLN; lsr@ietf.org
> >> Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee)
> >> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
> >>
> >> Hi Bruno,
> >>
> >> please see inline (##PP):
> >>
> >> On 24/01/2020 16:24, bruno.decra...@orange.com wrote:
> >>> Hi authors, WG,
> >>>
> >>> I've re-read the draft. Please find below some minor comments and nits.
> >>>
> >>> Best regards,
> >>>
> >>> --Bruno
> >>>
> >>> Minors:
> >>>
> >>> ==
> >>>
> >>> " A node indicates that it has support for SRv6 by advertising a new
> >>> SRv6 Capabilities sub-TLV"
> >>>
> >>> I'm not completely certain that "support for SRv6" is perfectly defined.
> >>> Do you have a reference? Otherwise may be "is an SRv6 Segment Endpoint
> >>> Node" would be better.
> >>>
> >>> Cfhttps://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3
> >>
> >> ##PP
> >> I changed to "SR Segment Endpoint Node"
> >>
> >>
> >>
> >>>
> >>> ---
> >>>
> >>> §4.3
> >>>
> >>> "The Maximum H.Encaps MSD Type specifies the maximum number of SIDsthat
> >>> can be included as part of the "H.Encaps" behavior"
> >>>
> >>> This is not crystal clear to me when the "reduced encapsulation" is
> >>> used. In such case we have:
> >>>
> >>> a) the number of SID included (N)
> >>>
> >>> b) the number of SID included in the SRH (N-1)
> >>>
> >>> Could you clarify which one you are referring to?
> >>>
> >>> I assume that this is "b" given the text:
> >>>
> >>> "If the advertised value is zero then the router can apply H.Encaps only
> >>> by encapsulating the incoming packet in anotherIPv6 header without SRH
> >>> the same way IPinIP encapsulation is performed."
> >>>
> >>> But to avoid interop issue, I'd prefer the spec to be non ambiguous.
> >>> (typically by saying "SIDs in a SRH" as indicated in §4.4
> >>
> >> ##PP
> >> the Maximum H.Encaps MSD Type specifies the maximum number of segments
> >> that a node can use as part of the encapsulation operation, regardless
> >> of whether that is H.Encaps or H.Encaps.Red. If the node advertises N it
> >> can either do H.Encaps with N SIDs in SRH or do H.Encaps.Red with (N-1)
> >> in the SRH +1 in the IPv6 DA.
> >>
> >>
> >>>
> >>> ---
> >>>
> >>> §4.2
> >>>
> >>> "inthe top SRH in an SRH stack to which the router can apply "PSP"
> >>> orUSP" as defined in [I-D.ietf-spring-srv6-network-programming]flavors"
> >>>
> >>> [I-D.ietf-spring-srv6-network-programming] does not define (anymore)
> >>> "SRH stack", nor "top SRH". Please remove those two terms.
> >>
> >>>
> >>> ##PP
> >>> Changed to:
> >>>
> >>> "The Maximum End Pop MSD Type specifies the maximum number of SIDs in
> >>> the SRH to which the router can apply "PSP" or USP" behavior, as defined
> >>> in [I-D.ietf-spring-srv6-network-programming] flavors."
> >>>
> 
>  ---
> 
>  §4.4
> 
>  "If the advertised value is zero or no value is advertised
> 
>  then it is assumed that the router cannot apply
> 
>  "End.DX6" or "End.DT6" behaviors if the extension
> 
>  header right underneath the outer IPv6 header is an SRH."
> 
>  There is no requirement for the SRH to be "right underneath the outer
>  IPv6 header".
> >>>
> >>> ##PP
> >>> Changed to:
> >>>
> >>> "If the advertised value is zero or no value is advertised
> >>> then it is assumed that the router cannot apply
> >>> "End.DX6" or "End.DT6" behaviors if the outer IPv6 header contains an 
> >>> SRH."
> >>>
> >>>
> 
>  Cfhttps://tools.ietf.org/html/rfc8200#section-4.1
> 
>  Please clarify what is meant precisely. E.g.:
> 
>  a) if there is an SRH
> 
>  b) if there is a IPv6 routing header