Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Shraddha:

 

If the traffic is steered via the SRv6 policy, the intermediate points
should also be protected. There are already one draft to propose the
solution( please refer to
https://datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protect
ion-05.)  In such situation, if the intermediate points located in different
areas, how then know the liveness of each other if ABR has the summary
address advertised? We will not consider to configure BFD on every
intermediate points.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Shraddha
Hegde
Sent: Wednesday, November 24, 2021 1:20 PM
To: Tony Li ; Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra
; Christian Hopps ; lsr ; Acee Lindem (acee) ; Tony Przygienda 
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR
Meeting Minutes

 

WG,

 

MPLS egress protection framework RFC 8679 provides a mechanism to locally
protect the traffic during

PE failures. The concepts can be applied to SRv6 as well. This mechanism is
much more efficient and quick because it locally provides fast protection

And switchover to the other PE.

If you compare this  to  the mechanisms being discussed in this thread where
the failure information is being

propagated by the egress PE to ABR and then  ABR to the ingress, the
failover is going to be much slower.

The egress protection technology does not flood any information outside of
the domain and hence does not

affect the IGP scale.

 

This is a valid alternate solution to solve the problem at hand IMO.

I would be interested to see if people have use cases where egress
protection can’t be applied.

 

Rgds

Shraddha

 

 

 

Juniper Business Use Only

From: Lsr mailto:lsr-boun...@ietf.org> > On Behalf Of
Tony Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>
>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>
>; Gyan Mishra mailto:hayabusa...@gmail.com> >;
Christian Hopps mailto:cho...@chopps.org> >; lsr
mailto:lsr@ietf.org> >; Acee Lindem (acee) mailto:a...@cisco.com> >; Tony Przygienda mailto:tonysi...@gmail.com> >
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR
Meeting Minutes

 

[External Email. Be cautious of content]

 

 

Hi Aijun, 

 

I object to adding negative liveness to the LSDB because of the scale and
because it adds scale during failures.

[WAJ] If we have no such mechanism, operator should either advertise the
host routes across areas(which has scale problem), or lose the fast
convergences for some overlay services(which defeat the user experiences).

Within the real network, there is very rare chance for the massive failure.
And even such thing happen accidently, the information about node liveness
is countable, is there any router can’t process such information?

The received unreachable information does not trigger the SPF calculation.
Will they influence intensively the performance of the router?

 

 

If the scale is equal, then I would prefer to see flooding positive
information rather than negative information.  Operationally this is key: if
there is a failure and positive information doesn’t propagate, then it’s a
bug that will be found in due course and the operator can react outside of a
failure scenario.

 

Having a scale failure on top of a topology failure is a far more painful
scenario.

 

The odds of a mass failure may be low. The fact of the matter is that they
still happen. It is our job to ensure that the IGP performs well when it
does.  

 

Increasing the size of the LSDB always affects performance. It slows
flooding. Some nodes may not realize that SPF is not needed.  When LSP
fragments are rearranged, inferring that SPF is not necessary is
non-trivial. Impacting router and network performance is a given.

 

 

My understanding is that N node failures would result in O(N) bytes added to
the LSDB.  If someone has a way to compress that information to O(1), I (and
Claude Shannon) would be interested.

[WAJ] Do you have other determined solutions except the PUB/SUB mechanism
that does not exist in current IGP?

 

 

None of the mechanisms being discussed currently exist.

 

I have no objections to Robert’s BGP propagation ideas if that’s workable.

 

This is simply not the IGP’s job and the IGP is not a dump truck.

 

Tony

 

 

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Shraddha Hegde]

WG,

MPLS egress protection framework RFC 8679 provides a mechanism to locally 
protect the traffic during
PE failures. The concepts can be applied to SRv6 as well. This mechanism is 
much more efficient and quick because it locally provides fast protection
And switchover to the other PE.
If you compare this  to  the mechanisms being discussed in this thread where 
the failure information is being
propagated by the egress PE to ABR and then  ABR to the ingress, the failover 
is going to be much slower.
The egress protection technology does not flood any information outside of the 
domain and hence does not
affect the IGP scale.

This is a valid alternate solution to solve the problem at hand IMO.
I would be interested to see if people have use cases where egress protection 
can’t be applied.

Rgds
Shraddha




Juniper Business Use Only
From: Lsr  On Behalf Of Tony Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
; Christian Hopps ; lsr 
; Acee Lindem (acee) ; Tony Przygienda 

Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

[External Email. Be cautious of content]


Hi Aijun,

I object to adding negative liveness to the LSDB because of the scale and 
because it adds scale during failures.
[WAJ] If we have no such mechanism, operator should either advertise the host 
routes across areas(which has scale problem), or lose the fast convergences for 
some overlay services(which defeat the user experiences).
Within the real network, there is very rare chance for the massive failure. And 
even such thing happen accidently, the information about node liveness is 
countable, is there any router can’t process such information?
The received unreachable information does not trigger the SPF calculation. Will 
they influence intensively the performance of the router?


If the scale is equal, then I would prefer to see flooding positive information 
rather than negative information.  Operationally this is key: if there is a 
failure and positive information doesn’t propagate, then it’s a bug that will 
be found in due course and the operator can react outside of a failure scenario.

Having a scale failure on top of a topology failure is a far more painful 
scenario.

The odds of a mass failure may be low. The fact of the matter is that they 
still happen. It is our job to ensure that the IGP performs well when it does.

Increasing the size of the LSDB always affects performance. It slows flooding. 
Some nodes may not realize that SPF is not needed.  When LSP fragments are 
rearranged, inferring that SPF is not necessary is non-trivial. Impacting 
router and network performance is a given.


My understanding is that N node failures would result in O(N) bytes added to 
the LSDB.  If someone has a way to compress that information to O(1), I (and 
Claude Shannon) would be interested.
[WAJ] Do you have other determined solutions except the PUB/SUB mechanism that 
does not exist in current IGP?


None of the mechanisms being discussed currently exist.

I have no objections to Robert’s BGP propagation ideas if that’s workable.

This is simply not the IGP’s job and the IGP is not a dump truck.

Tony


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

Re: [Lsr] IPR Poll for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

[Guillaume Solignac]

LSR,

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

Thanks,
Guillaume
‐‐‐ Original Message ‐‐‐
On Monday, November 22nd, 2021 at 3:12 PM, Acee Lindem (acee)  
wrote:

> Draft Authors and Contributors,
>
> Are you aware of any IPR that applies to 
> draft-decraeneginsberg-lsr-isis-fast-flooding-00?
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
>
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as a document author or contributor please respond
>
> to this email regardless of whether or not you are aware of any
>
> relevant IPR. *The response needs to be sent to the LSR WG mailing
>
> list.* The document will not advance to the next stage until a
>
> response has been received from each author and contributor.
>
> If you are on the LSR WG email list but are not listed as an author or
>
> contributor, then please explicitly respond only if you are aware of
>
> any IPR that has not yet been disclosed in conformance with IETF rules.
>
> Thanks,
>
> Acee___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Hi Aijun,

> I object to adding negative liveness to the LSDB because of the scale and 
> because it adds scale during failures.
> [WAJ] If we have no such mechanism, operator should either advertise the host 
> routes across areas(which has scale problem), or lose the fast convergences 
> for some overlay services(which defeat the user experiences).
> Within the real network, there is very rare chance for the massive failure. 
> And even such thing happen accidently, the information about node liveness is 
> countable, is there any router can’t process such information?
> The received unreachable information does not trigger the SPF calculation. 
> Will they influence intensively the performance of the router?


If the scale is equal, then I would prefer to see flooding positive information 
rather than negative information.  Operationally this is key: if there is a 
failure and positive information doesn’t propagate, then it’s a bug that will 
be found in due course and the operator can react outside of a failure scenario.

Having a scale failure on top of a topology failure is a far more painful 
scenario.

The odds of a mass failure may be low. The fact of the matter is that they 
still happen. It is our job to ensure that the IGP performs well when it does.  

Increasing the size of the LSDB always affects performance. It slows flooding. 
Some nodes may not realize that SPF is not needed.  When LSP fragments are 
rearranged, inferring that SPF is not necessary is non-trivial. Impacting 
router and network performance is a given.


> My understanding is that N node failures would result in O(N) bytes added to 
> the LSDB.  If someone has a way to compress that information to O(1), I (and 
> Claude Shannon) would be interested.
> [WAJ] Do you have other determined solutions except the PUB/SUB mechanism 
> that does not exist in current IGP?


None of the mechanisms being discussed currently exist.

I have no objections to Robert’s BGP propagation ideas if that’s workable.

This is simply not the IGP’s job and the IGP is not a dump truck.

Tony


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

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Acee Lindem (acee)]

Speaking as a WG member:

I support publication of this experimental extension to IS-IS.
Thanks,
Acee

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

Date: Monday, November 22, 2021 at 2:48 PM
To: "lsr@ietf.org" 
Subject: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05

This begins the WG Last for draft-ietf-lsr-isis-flood-reflection-05. Please 
post your support or objection to this list by 12:00 AM UTC on Dec 14th , 2021. 
Also please post your comments on the draft. I’m allowing as extra week as I 
like to get some additional reviews – although my comments have been addressed.

Thanks,
Acee

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

> [WAJ] What I want to express is the overall time from the failures occur to 
> the ABR notice it via only IGP procedures. Shouldn’t it be within millisecond 
> within one area? 
> 
> No. Not at all. 
> 
> OSPF hello def timer is 10 sec in some implementations I just checked. 
> 
> So unless you can quickly detect the failure, all works discussed are 
> pointless. That's why your statement that no BFD is needed is just not 
> correct. 
> 
> And if BFD is there as a prerequisite it can equally bring IGP adj down or 
> BGP session down. 

Furthermore, once there is detection, the adjacencies need to update LSAs/LSPs 
and flood them. Flooding may require many hops to get to the ABR.

If your requirement really is one millisecond, then nothing that we’ve 
discussed is even the right order of magnitude.

Tony


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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

> On Nov 23, 2021, at 6:56 AM, Aijun Wang  wrote:
> 
> For BFD configuration, I think central control has less help for the work. 
> Let’s consider the SRv6 tunnel, would you configure on every intermediate 
> node to detect the liveness of destination via BFD?


Normally, BFD would be configured on each hop individually.

Tony

___
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

[Acee Lindem (acee)]

Speaking as WG member:

I support WG adoption. My inclination is that this should be experimental track 
and this feel this will allow for faster publication.

Thanks,
Acee

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

Date: Monday, November 22, 2021 at 9:12 AM
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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

[Acee Lindem (acee)]

Speaking as a contributor, I’m not aware of any undisclosed IPR.
Thanks,
Acee

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

Date: Monday, November 22, 2021 at 9:14 AM
To: "draft-decraeneginsberg-lsr-isis-fast-flood...@ietf.org" 

Cc: "lsr@ietf.org" 
Subject: [Lsr] IPR Poll for "IS-IS Fast Flooding" - 
draft-decraeneginsberg-lsr-isis-fast-flooding-00

Draft Authors and Contributors,

Are you aware of any IPR that applies to 
draft-decraeneginsberg-lsr-isis-fast-flooding-00?

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

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

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

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Christian Hopps]

Aijun Wang  writes:


Hi, Chris:

For BFD configuration, I think central control has less help for the work. Let’s
consider the SRv6 tunnel, would you configure on every intermediate node to
detect the liveness of destination via BFD?


I was replying to you saying you wanted to use IGP neighbor down detection b/c 
BFD was too hard to configure. I'm not sure what use case you are talking about 
above.

Configuring things is not hard, and isn't a reason to invent new technology by 
itself, is what I'm saying. Operators of large networks generally have central 
management systems where they enable services and the mgmt system then 
automatically generates configuration files as complex as they need to be which 
the system then loads onto the devices.

Thanks,
Chris.
[wg member hat]




Aijun Wang
China Telecom


On Nov 23, 2021, at 20:44, Christian Hopps  wrote:


Aijun Wang  writes:


Hi, Robert:

Aijun Wang
China Telecom


   On Nov 23, 2021, at 20:00, Robert Raszuk 
   wrote:


   Dear Aijun,


   [WAJ] Once there is a link/node failure, upon receiving the
   updated LSA, the ABR 


   That node failure will need to be detected fast.

   The entire discussion here is to do it reasonably fast or as fast
   as possible.

[WAJ] And also as less configuration as possible. We have invested
several tools to increase the speed of LSA flooding.


You keep mentioning less configuration or less configuration complexity when 
people mention BFD. This isn't any sort of justification for not using BFD.

Operators use central management systems now a days, that generate a routers
configuration, they aren't hand typing configuration into routers anymore.
There's no problem at all with enabling BFD through configuration, and it's
use is absolutely not predicated based on how one has to configure it.

Saying BFD is hard to configure is not valid to me. If you are advocating for 
something that would replace BFD, I hope you have a stronger argument against 
using BFD.

Thanks,
Chris.
[WG member hat - for previous emails on this thread too -- forgot to include]



   That is why such detection must happen quickly via LOS or BFD or
   CFM etc That is way before ABR will receive any LSA/LSP from
   the adjacent nodes informing it of the failed adj. And in fact
   all such adj nodes MUST do it fast as ABR will not react till it
   hears bad news from every node previously connected to such PE.

[WAJ] The reaction time depend on the IGP convergence time after one
node is detached from the network. It should be in milliseconds
within one area? Right?


   In every solution we work on we must see a full picture, not just
   single pieces of the puzzle.

   Thx,
   R.




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


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




signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

> Such results can be deducted from active LSA updates.

That is great !

With just a little caveat ... those active LSA updates arriving on ABRs
must be triggered by some network event. And that is precisely what we are
talking about here.

Kind regards,
R.


On Tue, Nov 23, 2021 at 4:14 PM Aijun Wang 
wrote:

> Hi, Robert:
>
> Aijun Wang
> China Telecom
>
> On Nov 23, 2021, at 21:22, Robert Raszuk  wrote:
>
> 
>
> [WAJ] What I want to express is the overall time from the failures occur
>> to the ABR notice it via only IGP procedures. Shouldn’t it be within
>> millisecond within one area?
>>
>
> No. Not at all.
>
> OSPF hello def timer is 10 sec in some implementations I just checked.
>
> So unless you can quickly detect the failure, all works discussed are
> pointless. That's why your statement that no BFD is needed is just not
> correct.
>
> And if BFD is there as a prerequisite it can equally bring IGP adj down or
> BGP session down.
>
> [WAJ] we do not care the liveness of OSPF instance. What we want to know
> is the reachable or unreachable status of some host routes. Such results
> can be deducted from active LSA updates.
>
> Thx a lot,
> R.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 23, 2021, at 21:22, Robert Raszuk  wrote:
> 
> 
> 
>> [WAJ] What I want to express is the overall time from the failures occur to 
>> the ABR notice it via only IGP procedures. Shouldn’t it be within 
>> millisecond within one area? 
> 
> No. Not at all. 
> 
> OSPF hello def timer is 10 sec in some implementations I just checked. 
> 
> So unless you can quickly detect the failure, all works discussed are 
> pointless. That's why your statement that no BFD is needed is just not 
> correct. 
> 
> And if BFD is there as a prerequisite it can equally bring IGP adj down or 
> BGP session down. 
> 
[WAJ] we do not care the liveness of OSPF instance. What we want to know is the 
reachable or unreachable status of some host routes. Such results can be 
deducted from active LSA updates.

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Chris:

For BFD configuration, I think central control has less help for the work. 
Let’s consider the SRv6 tunnel, would you configure on every intermediate node 
to detect the liveness of destination via BFD?

Aijun Wang
China Telecom

> On Nov 23, 2021, at 20:44, Christian Hopps  wrote:
> 
> 
> Aijun Wang  writes:
> 
>> Hi, Robert:
>> 
>> Aijun Wang
>> China Telecom
>> 
>> 
>>On Nov 23, 2021, at 20:00, Robert Raszuk 
>>wrote:
>> 
>> 
>>Dear Aijun,
>> 
>> 
>>[WAJ] Once there is a link/node failure, upon receiving the
>>updated LSA, the ABR 
>> 
>> 
>>That node failure will need to be detected fast.
>> 
>>The entire discussion here is to do it reasonably fast or as fast
>>as possible.
>> 
>> [WAJ] And also as less configuration as possible. We have invested
>> several tools to increase the speed of LSA flooding.
> 
> You keep mentioning less configuration or less configuration complexity when 
> people mention BFD. This isn't any sort of justification for not using BFD.
> 
> Operators use central management systems now a days, that generate a routers 
> configuration, they aren't hand typing configuration into routers anymore. 
> There's no problem at all with enabling BFD through configuration, and it's 
> use is absolutely not predicated based on how one has to configure it.
> 
> Saying BFD is hard to configure is not valid to me. If you are advocating for 
> something that would replace BFD, I hope you have a stronger argument against 
> using BFD.
> 
> Thanks,
> Chris.
> [WG member hat - for previous emails on this thread too -- forgot to include]
> 
>> 
>>That is why such detection must happen quickly via LOS or BFD or
>>CFM etc That is way before ABR will receive any LSA/LSP from
>>the adjacent nodes informing it of the failed adj. And in fact
>>all such adj nodes MUST do it fast as ABR will not react till it
>>hears bad news from every node previously connected to such PE.
>> 
>> [WAJ] The reaction time depend on the IGP convergence time after one
>> node is detached from the network. It should be in milliseconds
>> within one area? Right?
>> 
>> 
>>In every solution we work on we must see a full picture, not just
>>single pieces of the puzzle.
>> 
>>Thx,
>>R.
>> 
>> 
>> 
>> 
>>___
>>Lsr mailing list
>>Lsr@ietf.org
>>https://www.ietf.org/mailman/listinfo/lsr
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] WG Adoption Call for "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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

> [WAJ] What I want to express is the overall time from the failures occur
> to the ABR notice it via only IGP procedures. Shouldn’t it be within
> millisecond within one area?
>

No. Not at all.

OSPF hello def timer is 10 sec in some implementations I just checked.

So unless you can quickly detect the failure, all works discussed are
pointless. That's why your statement that no BFD is needed is just not
correct.

And if BFD is there as a prerequisite it can equally bring IGP adj down or
BGP session down.

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:


Aijun Wang
China Telecom

> On Nov 23, 2021, at 20:41, Robert Raszuk  wrote:
> 
> 
> Aijun,
> 
> You are mixing flooding speed with area convergence and with failure 
> detection. Those are completely orthogonal elements. 
[WAJ] What I want to express is the overall time from the failures occur to the 
ABR notice it via only IGP procedures. Shouldn’t it be within millisecond 
within one area? 
> 
> You questioned use of BFD - all I am stating that there is no easy way to 
> detect failure of the neighbour when LOS trigger is not an option. 
> 
> Thx,
> R.
> 
>> On Tue, Nov 23, 2021 at 1:26 PM Aijun Wang  wrote:
>> Hi, Robert:
>> 
>> Aijun Wang
>> China Telecom
>> 
 On Nov 23, 2021, at 20:00, Robert Raszuk  wrote:
 
>>> 
>>> Dear Aijun,
>>>  
 [WAJ] Once there is a link/node failure, upon receiving the updated LSA, 
 the ABR 
>>> 
>>> That node failure will need to be detected fast. 
>>> 
>>> The entire discussion here is to do it reasonably fast or as fast as 
>>> possible.
>> [WAJ] And also as less configuration as possible. We have invested several 
>> tools to increase the speed of LSA flooding. 
>>> That is why such detection must happen quickly via LOS or BFD or CFM 
>>> etc That is way before ABR will receive any LSA/LSP from the adjacent 
>>> nodes informing it of the failed adj. And in fact all such adj nodes MUST 
>>> do it fast as ABR will not react till it hears bad news from every node 
>>> previously connected to such PE.
>> [WAJ] The reaction time depend on the IGP convergence time after one node is 
>> detached from the network. It should be in milliseconds within one area? 
>> Right?
>>> 
>>> In every solution we work on we must see a full picture, not just single 
>>> pieces of the puzzle. 
>>> 
>>> Thx,
>>> R.
>>> 
>>> 
>>> 
>>>  
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

[bruno.decraene]

LSR,

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

--Bruno




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

Draft Authors and Contributors,

Are you aware of any IPR that applies to 
draft-decraeneginsberg-lsr-isis-fast-flooding-00?

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

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

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

Thanks,
Acee

_

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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Christian Hopps]

Aijun Wang  writes:


Hi, Robert:

Aijun Wang
China Telecom


On Nov 23, 2021, at 20:00, Robert Raszuk 
wrote:


Dear Aijun,


[WAJ] Once there is a link/node failure, upon receiving the
updated LSA, the ABR 


That node failure will need to be detected fast.

The entire discussion here is to do it reasonably fast or as fast
as possible.

[WAJ] And also as less configuration as possible. We have invested
several tools to increase the speed of LSA flooding.


You keep mentioning less configuration or less configuration complexity when 
people mention BFD. This isn't any sort of justification for not using BFD.

Operators use central management systems now a days, that generate a routers 
configuration, they aren't hand typing configuration into routers anymore. 
There's no problem at all with enabling BFD through configuration, and it's use 
is absolutely not predicated based on how one has to configure it.

Saying BFD is hard to configure is not valid to me. If you are advocating for 
something that would replace BFD, I hope you have a stronger argument against 
using BFD.

Thanks,
Chris.
[WG member hat - for previous emails on this thread too -- forgot to include]



That is why such detection must happen quickly via LOS or BFD or
CFM etc That is way before ABR will receive any LSA/LSP from
the adjacent nodes informing it of the failed adj. And in fact
all such adj nodes MUST do it fast as ABR will not react till it
hears bad news from every node previously connected to such PE.

[WAJ] The reaction time depend on the IGP convergence time after one
node is detached from the network. It should be in milliseconds
within one area? Right?


In every solution we work on we must see a full picture, not just
single pieces of the puzzle.

Thx,
R.




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




signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Aijun,

You are mixing flooding speed with area convergence and with failure
detection. Those are completely orthogonal elements.

You questioned use of BFD - all I am stating that there is no easy way to
detect failure of the neighbour when LOS trigger is not an option.

Thx,
R.

On Tue, Nov 23, 2021 at 1:26 PM Aijun Wang 
wrote:

> Hi, Robert:
>
> Aijun Wang
> China Telecom
>
> On Nov 23, 2021, at 20:00, Robert Raszuk  wrote:
>
> 
> Dear Aijun,
>
>
>> [WAJ] Once there is a link/node failure, upon receiving the updated LSA,
>> the ABR 
>>
>
> That node failure will need to be detected fast.
>
> The entire discussion here is to do it reasonably fast or as fast as
> possible.
>
> [WAJ] And also as less configuration as possible. We have invested several
> tools to increase the speed of LSA flooding.
>
> That is why such detection must happen quickly via LOS or BFD or CFM
> etc That is way before ABR will receive any LSA/LSP from the adjacent
> nodes informing it of the failed adj. And in fact all such adj nodes MUST
> do it fast as ABR will not react till it hears bad news from every node
> previously connected to such PE.
>
> [WAJ] The reaction time depend on the IGP convergence time after one node
> is detached from the network. It should be in milliseconds within one area?
> Right?
>
>
> In every solution we work on we must see a full picture, not just single
> pieces of the puzzle.
>
> Thx,
> R.
>
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 23, 2021, at 20:00, Robert Raszuk  wrote:
> 
> 
> Dear Aijun,
>  
>> [WAJ] Once there is a link/node failure, upon receiving the updated LSA, the 
>> ABR 
> 
> That node failure will need to be detected fast. 
> 
> The entire discussion here is to do it reasonably fast or as fast as possible.
[WAJ] And also as less configuration as possible. We have invested several 
tools to increase the speed of LSA flooding. 
> That is why such detection must happen quickly via LOS or BFD or CFM etc 
> That is way before ABR will receive any LSA/LSP from the adjacent nodes 
> informing it of the failed adj. And in fact all such adj nodes MUST do it 
> fast as ABR will not react till it hears bad news from every node previously 
> connected to such PE.
[WAJ] The reaction time depend on the IGP convergence time after one node is 
detached from the network. It should be in milliseconds within one area? Right?
> 
> In every solution we work on we must see a full picture, not just single 
> pieces of the puzzle. 
> 
> Thx,
> R.
> 
> 
> 
>  
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Mohan Nanduri]

Support the adoption as a WG document.

Cheers,
-Mohan

On Mon, Nov 22, 2021 at 9:12 AM Acee Lindem (acee)
 wrote:
>
> 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
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Dear Aijun,


> [WAJ] Once there is a link/node failure, upon receiving the updated LSA,
> the ABR 
>

That node failure will need to be detected fast.

The entire discussion here is to do it reasonably fast or as fast as
possible. That is why such detection must happen quickly via LOS or BFD or
CFM etc That is way before ABR will receive any LSA/LSP from the
adjacent nodes informing it of the failed adj. And in fact all such adj
nodes MUST do it fast as ABR will not react till it hears bad news from
every node previously connected to such PE.

In every solution we work on we must see a full picture, not just single
pieces of the puzzle.

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 23, 2021, at 19:42, Robert Raszuk  wrote:
> 
> 
> 
> > For IGP solution, the BFD is not required. 
> 
> Excuse me ? 
> 
> BFD is used on vast majority of the WAN links today as those links are not 
> always dark fiber such that you can detect LOS. Those WAN links are 
> (unfortunately) emulated circuits which require BFD to detect failure in a 
> reasonable time. 
> 
> I hope you are not talking about IGP hellos or BGP keepalives here. 
> 
> We are talking PE-P or PE-RR. 

[WAJ] Once there is a link/node failure, upon receiving the updated LSA, the 
ABR can calculate the missed prefixes within its attached area, as described in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-4

> 
> Thx,
> R.
> 
> 
> 
>> On Tue, Nov 23, 2021 at 12:38 PM Aijun Wang  
>> wrote:
>> Hi, Robert:
>> 
>> Aijun Wang
>> China Telecom
>> 
 On Nov 23, 2021, at 18:04, Robert Raszuk  wrote:
 
>>> 
>>> 
>>> > When the node is failed, or is detached from the network, it can’t send 
>>> > the BGP update to other peers already.
>>> 
>>> LOL ... that's given. Same for IGP too. 
>>> 
>>> The UPDATE will be generated by the BGP peer of such node - typically RR. 
>>> And if you run BFD on that session it can be as fast as loosing IGP adj to 
>>> an IGP neighbour of the failing node. 
>> [WAJ] Then you depend again the BFD session which there is configuration 
>> overhead. For IGP solution, the BFD is not required. 
>> And, for tunnels situations, where you configure the monitor peer?
>> 
>> Aijun Wang
>> China Telecom
>> 
>>> 
>>> Cheers,
>>> R.
>>> 
>>> 
>>> 
>>> 
 On Tue, Nov 23, 2021 at 10:03 AM Aijun Wang  
 wrote:
 Hi, Robert:
 
  
 
 When the node is failed, or is detached from the network, it can’t send 
 the BGP update to other peers already.
 
 And, as we have discussed, the potential usage of such information is not 
 only BGP, but may be tunnel endpoints.
 
 Yes, I agree, the light speed is the same.
 
  
 
  
 
 Best Regards
 
  
 
 Aijun Wang
 
 China Telecom
 
  
 
 From: lsr-boun...@ietf.org  On Behalf Of Robert 
 Raszuk
 Sent: Tuesday, November 23, 2021 4:40 PM
 To: Aijun Wang 
 Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
 ; Christian Hopps ; Tony Li 
 ; lsr ; Acee Lindem (acee) 
 ; Tony Przygienda 
 Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
 Meeting Minutes
 
  
 
 Aijun,
 
  
 
 > or lose the fast convergences
 
  
 
 Putting aside all the drawbacks already discussed, what makes you think 
 that flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 
 areas would be any faster then sending BGP UPDATE message(s) across 2-3 
 RRs ? 
 
  
 
 Assume you need to detect the failure and react to it in your RP/RE 
 regardless how it is signalled. If triggered by ABRs you not only need to 
 detect the failure of a node, but also flood it locally within the local 
 area. 
 
  
 
 Light propagation speed last time I checked does not seems to be different 
 for BGP vs OSPF/ISIS packets. 
 
  
 
 Thx,
 
 R.
 
  
 
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

> For IGP solution, the BFD is not required.

Excuse me ?

BFD is used on vast majority of the WAN links today as those links are not
always dark fiber such that you can detect LOS. Those WAN links are
(unfortunately) emulated circuits which require BFD to detect failure in a
reasonable time.

I hope you are not talking about IGP hellos or BGP keepalives here.

We are talking PE-P or PE-RR.

Thx,
R.



On Tue, Nov 23, 2021 at 12:38 PM Aijun Wang 
wrote:

> Hi, Robert:
>
> Aijun Wang
> China Telecom
>
> On Nov 23, 2021, at 18:04, Robert Raszuk  wrote:
>
> 
>
> > When the node is failed, or is detached from the network, it can’t send
> the BGP update to other peers already.
>
> LOL ... that's given. Same for IGP too.
>
> The UPDATE will be generated by the BGP peer of such node - typically RR.
> And if you run BFD on that session it can be as fast as loosing IGP adj to
> an IGP neighbour of the failing node.
>
> [WAJ] Then you depend again the BFD session which there is configuration
> overhead. For IGP solution, the BFD is not required.
> And, for tunnels situations, where you configure the monitor peer?
>
> Aijun Wang
> China Telecom
>
>
> Cheers,
> R.
>
>
>
>
> On Tue, Nov 23, 2021 at 10:03 AM Aijun Wang 
> wrote:
>
>> Hi, Robert:
>>
>>
>>
>> When the node is failed, or is detached from the network, it can’t send
>> the BGP update to other peers already.
>>
>> And, as we have discussed, the potential usage of such information is not
>> only BGP, but may be tunnel endpoints.
>>
>> Yes, I agree, the light speed is the same.
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* lsr-boun...@ietf.org  *On Behalf Of *Robert
>> Raszuk
>> *Sent:* Tuesday, November 23, 2021 4:40 PM
>> *To:* Aijun Wang 
>> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
>> hayabusa...@gmail.com>; Christian Hopps ; Tony Li <
>> tony...@tony.li>; lsr ; Acee Lindem (acee) ;
>> Tony Przygienda 
>> *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
>> LSR Meeting Minutes
>>
>>
>>
>> Aijun,
>>
>>
>>
>> *> or lose the fast convergences*
>>
>>
>>
>> Putting aside all the drawbacks already discussed, what makes you think
>> that flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 areas
>> would be any faster then sending BGP UPDATE message(s) across 2-3 RRs ?
>>
>>
>>
>> Assume you need to detect the failure and react to it in your RP/RE
>> regardless how it is signalled. If triggered by ABRs you not only need to
>> detect the failure of a node, but also flood it locally within the local
>> area.
>>
>>
>>
>> Light propagation speed last time I checked does not seems to be
>> different for BGP vs OSPF/ISIS packets.
>>
>>
>>
>> Thx,
>>
>> R.
>>
>>
>>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 23, 2021, at 18:04, Robert Raszuk  wrote:
> 
> 
> 
> > When the node is failed, or is detached from the network, it can’t send the 
> > BGP update to other peers already.
> 
> LOL ... that's given. Same for IGP too. 
> 
> The UPDATE will be generated by the BGP peer of such node - typically RR. And 
> if you run BFD on that session it can be as fast as loosing IGP adj to an IGP 
> neighbour of the failing node. 
[WAJ] Then you depend again the BFD session which there is configuration 
overhead. For IGP solution, the BFD is not required. 
And, for tunnels situations, where you configure the monitor peer?

Aijun Wang
China Telecom

> 
> Cheers,
> R.
> 
> 
> 
> 
>> On Tue, Nov 23, 2021 at 10:03 AM Aijun Wang  
>> wrote:
>> Hi, Robert:
>> 
>>  
>> 
>> When the node is failed, or is detached from the network, it can’t send the 
>> BGP update to other peers already.
>> 
>> And, as we have discussed, the potential usage of such information is not 
>> only BGP, but may be tunnel endpoints.
>> 
>> Yes, I agree, the light speed is the same.
>> 
>>  
>> 
>>  
>> 
>> Best Regards
>> 
>>  
>> 
>> Aijun Wang
>> 
>> China Telecom
>> 
>>  
>> 
>> From: lsr-boun...@ietf.org  On Behalf Of Robert Raszuk
>> Sent: Tuesday, November 23, 2021 4:40 PM
>> To: Aijun Wang 
>> Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
>> ; Christian Hopps ; Tony Li 
>> ; lsr ; Acee Lindem (acee) ; 
>> Tony Przygienda 
>> Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
>> Meeting Minutes
>> 
>>  
>> 
>> Aijun,
>> 
>>  
>> 
>> > or lose the fast convergences
>> 
>>  
>> 
>> Putting aside all the drawbacks already discussed, what makes you think that 
>> flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 areas would 
>> be any faster then sending BGP UPDATE message(s) across 2-3 RRs ? 
>> 
>>  
>> 
>> Assume you need to detect the failure and react to it in your RP/RE 
>> regardless how it is signalled. If triggered by ABRs you not only need to 
>> detect the failure of a node, but also flood it locally within the local 
>> area. 
>> 
>>  
>> 
>> Light propagation speed last time I checked does not seems to be different 
>> for BGP vs OSPF/ISIS packets. 
>> 
>>  
>> 
>> Thx,
>> 
>> R.
>> 
>>  
>> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

Support.

On Mon, Nov 22, 2021 at 3:11 PM Acee Lindem (acee)  wrote:

> 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
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tony Przygienda]

Yes, support, experimental. It would be beneficial for the authors taking
IPR here to explain in few words what we're protecting here that is not
covered by TCP & million other congestion things out there already

-- tony

On Tue, Nov 23, 2021 at 4:20 AM Jeff Tantsura 
wrote:

> Acee,
>
> I support the adoption, and would like to thank the authors for the great
> work.
> At this point in time, it feels like experimental track is more suitable.
>
> Cheers,
> Jeff
>
>
>
> On Nov 22, 2021, at 6:06 AM, Acee Lindem (acee) <
> acee=40cisco@dmarc.ietf.org> wrote:
>
> 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
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

> As side discussion, I'm getting lost how a SRv6 PE-PE is somehow a
drastically different,

It is not.

You can deliver all of your services using MPLS (as service demux only)
over UDP and IPv4 summarized endpoints for a long long time. Contrail
was/is doing just that :)

Best,
R.


On Tue, Nov 23, 2021 at 11:14 AM Tony Przygienda 
wrote:

>
>
> On Tue, Nov 23, 2021 at 9:30 AM Peter Psenak  wrote:
>
>> Hi Chris,
>>
>> On 22/11/2021 22:29, Christian Hopps wrote:
>> >
>> > Gyan Mishra  writes:
>> >
>> >> +1
>> >>
>> >> As I mentioned the requirements for E2E LSP with seamless MPLS or
>> >> SR-MPLS requires domain wide flooding of host routes.
>> >>
>> >> For large operators with a thousands of routes per area you can image
>> >> if you total that all up can equate to hundreds of thousands of host
>> >> routes.  That is what we live with today real world scenario.
>> >>
>> >> Summarization is a tremendous optimization for operators.
>> >
>> > I'm having a hard time imagining 300,000 or 500,000 PEs that need this
>> "liveness as a host route" notification for. Where are these hundreds of
>> thousands of hosts coming from that ever need to be in the IGP?
>>
>> It's more like tens of thousands from what I have seen.
>>
>
> I don't know the specific network talked about here by Guayn where he
> claims to see 100s of Ks of host routes on a router  either. Though IME
> seeing igp RIB is excess of few 10Ks routes (in a single instance/topology)
> is quiet exceptional for a lot of practical reasons in real deployments.
>
> As side discussion, I'm getting lost how a SRv6 PE-PE is somehow a
> drastically different, novel way of addressing tunnel endpoints. Nothing
> prevents you from summarizing (v6) loopback addresses on PEs AFAIS in any
> other tunneling technology (that preconditions having an addressing
> discipline of course but it seems the same is true for SRv6). I stand
> enlightened but AFAIS a tunnel is a tunnel is a tunnel, what we talk about
> here is adding something that provides a partial (since it does not verify
> the data path needed for the control or transport tunnels) SSAP liveliness
> indication to IGP on whatever endpoint (which happens in IP being roughly
> :port whereas we imply by a loss of address the loss of all
> services which in itself is an assumption which is probably fair enough as
> long BGP has all services on the same routing instance, not a given thing
> in the future AFAIS ;-) Where I agree with TLi again that it's not
> something that should be in IGP scope (or at minimum not shared with the
> instance responsible to do the IP reachability computation).
>
> -- tony
>
>
>>
>> thanks,
>> Peter
>>
>> >
>> > Large operators may have prefixes for each of their internal links or
>> each of their router loopback addresss, so this can lead to 1000s of
>> routes; however, it does not imply 100 times that many host routes being
>> present at all.
>> >
>> > Perhaps this is just a hole in my knowledge though.
>> >
>> > Thanks,
>> > Chris.
>> >
>> >
>> >>
>> >> With RFC 5283 the issue why it was never deployed is that it fixes
>> >> half the problem.  If fixed the IGP for with the LDP inter area
>> >> extension can now support LPM IGP match summarization so the RIB/FIB
>> >> is optimized, however the LFIB still has to maintain all the host
>> >> routes FEC binding RFC 5036.
>> >>
>> >> With the RFC 5283 solution we still have to track the liveliness of
>> >> the egress LSR which states can be done by advertising reachability
>> >> via IGP and then you are back to domain wide flooding even in the
>> >> IGP.
>> >>
>> >> Section 7.2
>> >>
>> >>
>> >> - Advertise LER reachability in the IGP for the purpose of the
>> >>   control plane in a way that does not create IP FIB entries in the
>> >>   forwarding plane.
>> >>
>> >>
>> >>
>> >> Here stated the LFIB remains not optimized
>> >>
>> >>
>> >> - The solution documented in this document reduces te link state
>> database size in the control plane and the number of FIB
>> >> entries in the forwarding plane.  As such, it solves the scaling of
>> >>
>> >> pure IP routers sharing the IGP with MPLS routers.  However, it
>> does
>> >> not decrease the number of LFIB entries so is not sufficient to
>> solve
>> >> the scaling of MPLS routers.  For this, an additional mechanism is
>> >> required (e.g., introducing some MPLS hierarchy in LDP).  This is
>> out
>> >> of scope for this document.
>> >>
>> >>
>> >> So this is quite unfortunate for RFC 5283 and why it was never
>> deployed by operators.
>> >>
>> >>
>> >> SRv6 is an answer but majority of all SPs are not there yet and we
>> >> need to be able support MPLS for a long time to come beyond our
>> >> lifetime.
>> >>
>> >> Kind Regards
>> >>
>> >> Gyan
>> >>
>> >> On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak 
>> >> wrote:
>> >>
>> >>  Robert,
>> >>
>> >>  On 22/11/2021 15:26, Robert Raszuk wrote:
>> >>  >
>> >>  > Peter - the spec does not present ful

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Przygienda]

On Tue, Nov 23, 2021 at 9:30 AM Peter Psenak  wrote:

> Hi Chris,
>
> On 22/11/2021 22:29, Christian Hopps wrote:
> >
> > Gyan Mishra  writes:
> >
> >> +1
> >>
> >> As I mentioned the requirements for E2E LSP with seamless MPLS or
> >> SR-MPLS requires domain wide flooding of host routes.
> >>
> >> For large operators with a thousands of routes per area you can image
> >> if you total that all up can equate to hundreds of thousands of host
> >> routes.  That is what we live with today real world scenario.
> >>
> >> Summarization is a tremendous optimization for operators.
> >
> > I'm having a hard time imagining 300,000 or 500,000 PEs that need this
> "liveness as a host route" notification for. Where are these hundreds of
> thousands of hosts coming from that ever need to be in the IGP?
>
> It's more like tens of thousands from what I have seen.
>

I don't know the specific network talked about here by Guayn where he
claims to see 100s of Ks of host routes on a router  either. Though IME
seeing igp RIB is excess of few 10Ks routes (in a single instance/topology)
is quiet exceptional for a lot of practical reasons in real deployments.

As side discussion, I'm getting lost how a SRv6 PE-PE is somehow a
drastically different, novel way of addressing tunnel endpoints. Nothing
prevents you from summarizing (v6) loopback addresses on PEs AFAIS in any
other tunneling technology (that preconditions having an addressing
discipline of course but it seems the same is true for SRv6). I stand
enlightened but AFAIS a tunnel is a tunnel is a tunnel, what we talk about
here is adding something that provides a partial (since it does not verify
the data path needed for the control or transport tunnels) SSAP liveliness
indication to IGP on whatever endpoint (which happens in IP being roughly
:port whereas we imply by a loss of address the loss of all
services which in itself is an assumption which is probably fair enough as
long BGP has all services on the same routing instance, not a given thing
in the future AFAIS ;-) Where I agree with TLi again that it's not
something that should be in IGP scope (or at minimum not shared with the
instance responsible to do the IP reachability computation).

-- tony


>
> thanks,
> Peter
>
> >
> > Large operators may have prefixes for each of their internal links or
> each of their router loopback addresss, so this can lead to 1000s of
> routes; however, it does not imply 100 times that many host routes being
> present at all.
> >
> > Perhaps this is just a hole in my knowledge though.
> >
> > Thanks,
> > Chris.
> >
> >
> >>
> >> With RFC 5283 the issue why it was never deployed is that it fixes
> >> half the problem.  If fixed the IGP for with the LDP inter area
> >> extension can now support LPM IGP match summarization so the RIB/FIB
> >> is optimized, however the LFIB still has to maintain all the host
> >> routes FEC binding RFC 5036.
> >>
> >> With the RFC 5283 solution we still have to track the liveliness of
> >> the egress LSR which states can be done by advertising reachability
> >> via IGP and then you are back to domain wide flooding even in the
> >> IGP.
> >>
> >> Section 7.2
> >>
> >>
> >> - Advertise LER reachability in the IGP for the purpose of the
> >>   control plane in a way that does not create IP FIB entries in the
> >>   forwarding plane.
> >>
> >>
> >>
> >> Here stated the LFIB remains not optimized
> >>
> >>
> >> - The solution documented in this document reduces te link state
> database size in the control plane and the number of FIB
> >> entries in the forwarding plane.  As such, it solves the scaling of
> >>
> >> pure IP routers sharing the IGP with MPLS routers.  However, it does
> >> not decrease the number of LFIB entries so is not sufficient to
> solve
> >> the scaling of MPLS routers.  For this, an additional mechanism is
> >> required (e.g., introducing some MPLS hierarchy in LDP).  This is
> out
> >> of scope for this document.
> >>
> >>
> >> So this is quite unfortunate for RFC 5283 and why it was never deployed
> by operators.
> >>
> >>
> >> SRv6 is an answer but majority of all SPs are not there yet and we
> >> need to be able support MPLS for a long time to come beyond our
> >> lifetime.
> >>
> >> Kind Regards
> >>
> >> Gyan
> >>
> >> On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak 
> >> wrote:
> >>
> >>  Robert,
> >>
> >>  On 22/11/2021 15:26, Robert Raszuk wrote:
> >>  >
> >>  > Peter - the spec does not present full story. Hardly no RFC
> >>  > presents full A--Z on how to run a network or even a
> >>  given feature. It
> >>  > provides mechanism which can still permit for building LDP LSPs
> >>  > without host routes.
> >>  >
> >>  > So anyone claiming it is impossible by architecture of MPLS is
> >>  simply
> >>  > incorrect.
> >>  >
> >>  > As example - some vendors support ordered LDP mode some do not.
> >>  Some
> >>  > support BGP recursion some 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

> When the node is failed, or is detached from the network, it can’t send
the BGP update to other peers already.

LOL ... that's given. Same for IGP too.

The UPDATE will be generated by the BGP peer of such node - typically RR.
And if you run BFD on that session it can be as fast as loosing IGP adj to
an IGP neighbour of the failing node.

Cheers,
R.




On Tue, Nov 23, 2021 at 10:03 AM Aijun Wang 
wrote:

> Hi, Robert:
>
>
>
> When the node is failed, or is detached from the network, it can’t send
> the BGP update to other peers already.
>
> And, as we have discussed, the potential usage of such information is not
> only BGP, but may be tunnel endpoints.
>
> Yes, I agree, the light speed is the same.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org  *On Behalf Of *Robert
> Raszuk
> *Sent:* Tuesday, November 23, 2021 4:40 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Christian Hopps ; Tony Li <
> tony...@tony.li>; lsr ; Acee Lindem (acee) ;
> Tony Przygienda 
> *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
> Aijun,
>
>
>
> *> or lose the fast convergences*
>
>
>
> Putting aside all the drawbacks already discussed, what makes you think
> that flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 areas
> would be any faster then sending BGP UPDATE message(s) across 2-3 RRs ?
>
>
>
> Assume you need to detect the failure and react to it in your RP/RE
> regardless how it is signalled. If triggered by ABRs you not only need to
> detect the failure of a node, but also flood it locally within the local
> area.
>
>
>
> Light propagation speed last time I checked does not seems to be different
> for BGP vs OSPF/ISIS packets.
>
>
>
> Thx,
>
> R.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Parag Kaneriya]

I support this Draft.

Regards
Parag

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, November 23, 2021 1:17 AM
To: lsr@ietf.org
Subject: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05

[External Email. Be cautious of content]

This begins the WG Last for draft-ietf-lsr-isis-flood-reflection-05. Please 
post your support or objection to this list by 12:00 AM UTC on Dec 14th , 2021. 
Also please post your comments on the draft. I’m allowing as extra week as I 
like to get some additional reviews – although my comments have been addressed.

Thanks,
Acee

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:

 

When the node is failed, or is detached from the network, it can’t send the BGP 
update to other peers already.

And, as we have discussed, the potential usage of such information is not only 
BGP, but may be tunnel endpoints.

Yes, I agree, the light speed is the same.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Robert Raszuk
Sent: Tuesday, November 23, 2021 4:40 PM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
; Christian Hopps ; Tony Li 
; lsr ; Acee Lindem (acee) ; 
Tony Przygienda 
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

 

Aijun,

 

> or lose the fast convergences

 

Putting aside all the drawbacks already discussed, what makes you think that 
flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 areas would be 
any faster then sending BGP UPDATE message(s) across 2-3 RRs ? 

 

Assume you need to detect the failure and react to it in your RP/RE regardless 
how it is signalled. If triggered by ABRs you not only need to detect the 
failure of a node, but also flood it locally within the local area. 

 

Light propagation speed last time I checked does not seems to be different for 
BGP vs OSPF/ISIS packets. 

 

Thx,

R.

 

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Aijun,

*> or lose the fast convergences*

Putting aside all the drawbacks already discussed, what makes you think
that flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 areas
would be any faster then sending BGP UPDATE message(s) across 2-3 RRs ?

Assume you need to detect the failure and react to it in your RP/RE
regardless how it is signalled. If triggered by ABRs you not only need to
detect the failure of a node, but also flood it locally within the local
area.

Light propagation speed last time I checked does not seems to be different
for BGP vs OSPF/ISIS packets.

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Peter Psenak]

Hi Chris,

On 22/11/2021 22:29, Christian Hopps wrote:


Gyan Mishra  writes:


+1

As I mentioned the requirements for E2E LSP with seamless MPLS or
SR-MPLS requires domain wide flooding of host routes.

For large operators with a thousands of routes per area you can image
if you total that all up can equate to hundreds of thousands of host
routes.  That is what we live with today real world scenario.

Summarization is a tremendous optimization for operators.


I'm having a hard time imagining 300,000 or 500,000 PEs that need this "liveness as 
a host route" notification for. Where are these hundreds of thousands of hosts 
coming from that ever need to be in the IGP?


It's more like tens of thousands from what I have seen.

thanks,
Peter



Large operators may have prefixes for each of their internal links or each of 
their router loopback addresss, so this can lead to 1000s of routes; however, 
it does not imply 100 times that many host routes being present at all.

Perhaps this is just a hole in my knowledge though.

Thanks,
Chris.




With RFC 5283 the issue why it was never deployed is that it fixes
half the problem.  If fixed the IGP for with the LDP inter area
extension can now support LPM IGP match summarization so the RIB/FIB
is optimized, however the LFIB still has to maintain all the host
routes FEC binding RFC 5036.

With the RFC 5283 solution we still have to track the liveliness of
the egress LSR which states can be done by advertising reachability
via IGP and then you are back to domain wide flooding even in the
IGP.

Section 7.2


- Advertise LER reachability in the IGP for the purpose of the
  control plane in a way that does not create IP FIB entries in the
  forwarding plane.



Here stated the LFIB remains not optimized


- The solution documented in this document reduces te link state database size 
in the control plane and the number of FIB
entries in the forwarding plane.  As such, it solves the scaling of

pure IP routers sharing the IGP with MPLS routers.  However, it does
not decrease the number of LFIB entries so is not sufficient to solve
the scaling of MPLS routers.  For this, an additional mechanism is
required (e.g., introducing some MPLS hierarchy in LDP).  This is out
of scope for this document.


So this is quite unfortunate for RFC 5283 and why it was never deployed by 
operators.


SRv6 is an answer but majority of all SPs are not there yet and we
need to be able support MPLS for a long time to come beyond our
lifetime.

Kind Regards

Gyan

On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak 
wrote:

 Robert,

 On 22/11/2021 15:26, Robert Raszuk wrote:
 >
 > Peter - the spec does not present full story. Hardly no RFC
 > presents full A--Z on how to run a network or even a
 given feature. It
 > provides mechanism which can still permit for building LDP LSPs
 > without host routes.
 >
 > So anyone claiming it is impossible by architecture of MPLS is
 simply
 > incorrect.
 >
 > As example - some vendors support ordered LDP mode some do not.
 Some
 > support BGP recursion some do not. And the story goes on.
 >
 > But I am not sure what point are you insisting on arguing ...
 If it is
 > ok to run host routes across areas we have no problem to start
 with so
 > why to propose anything new there.

 all I'm trying to say is that IGPs do advertise host routes
 across areas
 today. Yes, it is sub-optimal, but hardly architecturally
 incorrect
 IMHO. We want to improve and allow effective use of aggregation,
 while
 keeping the fast notification about egress PE reachability loss
 in place
 to help overlay protocols converge fast. The situation would be
 much
 improved compared to what we have today.

 thanks,
 Peter


 >
 > Moreover as you very well know tons of opaque stuff is attached
 today to
 > leaked host routes and this curve is going up. So when you
 summarise you
 > stop propagating all of this. Is this really ok ?
 >
 > Do not get me wrong I love summarization but it seems as
 discussed off
 > line - we would be much better to leak host routes with opaque
 stuff
 > when needed rather then then leak blindly everything
 everywhere.
 >
 > Cheers,
 > R.
 >
 >
 >
 >
 > On Mon, Nov 22, 2021 at 3:12 PM Peter Psenak  > wrote:
 >
 >     On 22/11/2021 15:00, Robert Raszuk wrote:
 >      >
 >      >     it's not a choice, that is an MPLS architectural
 requirement
 >     and it
 >      >     happens in every single SP network that offers
 services on
 >     top of MPLS.
 >      >     If that is considered architecturally incorrect,
 then the
 >     whole MPLS
 >      >     would be. But regardless of that, it has been used
 very
 >     successfull