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

[Shraddha Hegde]

I support the adoption of this work.

I would prefer this to be an experimental track document as the deployment 
experiences are expected to
provide a lot of insight and changes to the algorithms being proposed in the 
document.

I have below comments on the document


  1.  Section 4.6 talks about flooding parameter values accounting for the 
number of adjacencies on LAN interface. I think that the flooding parameters  
should account for total number of ISIS adjacencies on the device as well due 
to the common queues/buffers shared by all adjacencies. This is applicable to 
all the flooding enhancements where receiver is advertising the flooding 
parameters. I think this aspect deserves its own section in the document.





Rgds

Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, November 23, 2021 9:57 PM
To: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] WG Adoption Call for "IS-IS Fast Flooding" - 
draft-decraeneginsberg-lsr-isis-fast-flooding-00

[External Email. Be cautious of content]

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 mailto:lsr-boun...@ietf.org>> on behalf of 
"Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>
Date: Monday, November 22, 2021 at 9:12 AM
To: "lsr@ietf.org" mailto: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] BFD aspects

[Gyan Mishra]

Hi Robert

On Tue, Nov 30, 2021 at 12:09 PM Robert Raszuk  wrote:

> Hi Greg,
>
> GIM2>> Now we have to reconcile states reported by RRs.
>>
>
> Not really. That "reconciliation" is native and automatic. No need to do
> anything. If you are hearing updates from two RRs you only consider it DOWN
> when both RRs withdraw the very path. Otherwise it is all UP.
>
> #3 - If my network to PE fails but RR-PE works fine PE will be considered
>>> alive. Network down detection is not the goal for discussing PUA/PULSE.
>>>
>> GIM2>> Thank you for the clarification. Though I wonder how such
>> separation benefits network operation.
>>
>
> Well that can happen if you really use separate data plane for your
> control channels from RRs. Honestly I have not seen much deployments which
> would use such model.
>

   Gyan> My verbiage used in describing this may have been confusing but
what Greg mentioned related to false positive and negative shed some light
on this topic.  So it’s basically the forwarding plane path PE to PE
between any pair of ingress or egress PEs from a design perspective should
never have an RR in the path as the RR hardware is not as robust for high
speed forwarding plane traffic as a PE or P.  Thus the RR from a
topological POV sits to the side in each POP so it’s outside of the direct
PE to PE path forwarding plane for customer traffic.  For this reason the
RR to PE peering path as it’s not the same as the PE to PE path it may
result in false positive or negative.  I am not sure that can be fixed as
that is inherent to any RR design.

>
> Many thx,
> R.
>
> --



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] BGP vs PUA/PULSE

[Les Ginsberg (ginsberg)]

Hannes -

Please see 
https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-4.1

The new Pulse LSPs don't have remaining lifetime - quite intentionally.
They are only retained long enough to support flooding.

But, you remind me that we need to specify how the checksum is calculated. Will 
do that in the next revision.

Thanx.

Les

> -Original Message-
> From: Hannes Gredler 
> Sent: Tuesday, November 30, 2021 11:22 AM
> To: Peter Psenak (ppsenak) 
> Cc: Robert Raszuk ; Les Ginsberg (ginsberg)
> ; Aijun Wang ; lsr
> ; Tony Li ; Shraddha Hegde
> 
> Subject: Re: [Lsr] BGP vs PUA/PULSE
> 
> hi peter,
> 
> Just curious: Do you have an idea how to make short-lived LSPs compatible
> with the problem stated in
> https://datatracker.ietf.org/doc/html/rfc7987
> 
> Would like to hear your thoughts on that.
> 
> thanks,
> 
> /hannes
> 
> On Tue, Nov 30, 2021 at 01:15:04PM +0100, Peter Psenak wrote:
> | Hi Robert,
> |
> | On 30/11/2021 12:40, Robert Raszuk wrote:
> | > Hey Peter,
> | >
> | >  > #1 - I am not ok with the ephemeral nature of the advertisements. 
> (I
> | >  > proposed an alternative).
> | >
> | > LSPs have their age today. One can generate LSP with the lifetime of 1
> | > min. Protocol already allows that.
> | >
> | >
> | > That's a pretty clever comparison indeed. I had a feeling it will come
> | > up here and here you go :)
> | >
> | > But I am afraid this is not comparing apple to apples.
> | >
> | > In LSPs or LSA flooding you have a bunch of mechanisms to make sure the
> | > information stays fresh
> | > and does not time out. And the default refresh in ISIS if I recall was
> | > something like 15 minutes ?
> |
> | yes, default refresh is 900 for the default lifetime of 1200 sec. Most
> | people change both to much larger values.
> |
> | If I send the LSP with the lifetime of 1 min, there will never be any
> | refresh of it. It will last 1 min and then will be purged and removed from
> | the database. The only difference with the Pulse LSP is that it is not
> | purged to avoid additional flooding.
> |
> |
> | >
> | > Today in all MPLS networks host routes from all areas are "spread"
> | > everywhere including all P and PE routers, that's how LS protocols
> | > distribute data, we have no other way to do that in LS IGPs.
> | >
> | >
> | > Can't you run OSPF over GRE ? For ISIS Henk had proposal not so long ago
> | > to run it over TCP too.
> | > https://datatracker.ietf.org/doc/html/draft-hsmit-lsr-isis-flooding-over-
> tcp-00
> |
> | you can run anything over GRE, including IGPs, and you don't need TCP
> | transport for that. I don't see the relevance here. Are you suggesting to
> | create GRE tunnels to all PEs that need the pulses? Nah, that would be an
> | ugly requirement.
> |
> | thanks,
> | Peter
> |
> |
> | >
> | > Seems like a perfect fit !
> | >
> | > Thx,
> | > R.
> |

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

Re: [Lsr] BGP vs PUA/PULSE

[Les Ginsberg (ginsberg)]

Hannes -

Inline.

> -Original Message-
> From: Hannes Gredler 
> Sent: Tuesday, November 30, 2021 11:15 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Aijun Wang ; 'Robert Raszuk'
> ; 'lsr' ; 'Tony Li' ;
> 'Shraddha Hegde' ; Peter Psenak (ppsenak)
> 
> Subject: Re: [Lsr] BGP vs PUA/PULSE
> 
> hi les,
> 
> please see inline.
> 
> On Mon, Nov 29, 2021 at 10:39:17PM +, Les Ginsberg (ginsberg) wrote:
> |Hannes -
> |
> |
> |
> |Thanx for bringing a new voice into the discussion.
> |
> |Please see inline.
> |
> |
> |
> |> -Original Message-
> |
> |> From: Hannes Gredler 
> |
> |> Sent: Monday, November 29, 2021 1:27 AM
> |
> |> To: Aijun Wang 
> |
> |> Cc: 'Robert Raszuk' ; 'lsr' ; Les
> |Ginsberg
> |
> |> (ginsberg) ; 'Tony Li' ; 'Shraddha
> |
> |> Hegde' ; Peter Psenak (ppsenak)
> |
> |> 
> |
> |> Subject: Re: [Lsr] BGP vs PUA/PULSE
> |
> |>
> |
> |> On Mon, Nov 29, 2021 at 09:42:57AM +0800, Aijun Wang wrote:
> |
> |>
> |
> |> [ ... ]
> |
> |>
> |
> |> |Option 3: The “DOWN” detection on ABR is same as PUA/PULSE, the
> |
> |> different
> |
> |> |is how to propagate such “DOWN” information. Considering we have
> |
> |> observed
> |
> |> |that all P/PE router in other areas may be interested such
> |information,
> |
> |> |your proposal will require every P/PE router run BGP-LS, which is
> |not the
> |
> |> |aimed deploy scenarios for BGP-LS.
> |
> |>
> |
> |> HG> BGP-LS has been conceived to solve the very problem of providing
> |
> |> visibility of other
> |
> |> area's link state. I fail to see what is out of scope here.
> |
> |>
> |
> |[LES:] BGP-LS only advertises what the IGPs themselves advertise.
> 
> HG> That is an implementation choice; the protocol allows multiple sources
> of information.
> https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-
> parameters.xhtml#protocol-ids
> And even standalone implementations are fine as the LSVR WG suggests.
> 
[LES:] Yes - I thought you might bring that up. 😊
If you want to use BGP-LS to advertise things on its own, that's fine and - as 
you point out - even supported by RFC 7752.
But it isn’t part of the LSR WG discussion where we are discussing possible IGP 
solutions.


> |In this case, both IGP proposals involve ephemeral advertisements - so
> |even if we were to define BGP-LS support for these new advertisements
> -
> |they wouldn't persist long enough to be reflected in BGP-LS.
> 
> HG> you could model the liveliness tracker as a "source protocol" and
> advertise the state of your endpoint.
> 
> |So, I really don’t know why we are discussing BGP-LS in the context of
> |this thread.
> 
> HG> because some people think it's a bad a idea to put this corner-case app
> in the very core of our networks.
> 
[LES:] Again, if you want to propose BGP-LS as a possible solution, feel free 
to do so. I believe IDR would be the right WG for that discussion.

> |(This seems to be one example of what Acee correctly identified as this
> |discussion going "off track".)
> 
> HG> please do not derail the discussion. It is well within the mandate of LSR
> to discuss solution space and have a healthy discussion
> about the scalingaspects of a proposal. If the WG has concerns on the scaling
> properties and brings up alternatives to make a given
> use-case work that is IMO fine and we may just use some airtime for that.
> After all it's link-state routing, right ?
> 
> |
> |
> |
> |> |Then, if IGP has such capabilities, why bother BGP? What is the
> |benefit?
> |
> |>
> |
> |> HG> simply put: seperation of concerns. Agreed consensus is to mostly
> |use
> |
> |> the
> |
> |> IGP for topology discovery and put the bulk of carrying reachability
> |
> |> information
> |
> |> into BGP which gives us:
> |
> |>
> |
> |[LES:] I am not convinced either side can claim "consensus" in this
> |discussion. That is a work in progress. 😊
> 
> HG> by consensus i meant that the BGP/IGP split is common practise of
> building large scale networks.
> 
> |However, when you say IGPs are (exclusively?) for topology discovery - it
> |seems to suggest that IGP shouldn’t be advertising prefix reachability at
> |all. Hopefully, that is not what you intend.
> 
> HG> did not say that. of course we need minimal IP reachability for
> bootstrapping the iBGP transport mesh.
> but we certainly do not use the IGP for carrying bulk routes at (Internet)
> scale.

[LES:] No one is proposing that.
WE are proposing to signal loss of reachability to prefixes that are already 
being learned by the IGPs.

> 
> |One of the points that still baffles me is the assertion of an
> |architectural violation in the IGP proposals.
> |
> 
> HG> did not say that.
> 
[LES:] That was in response to earlier comments from other folks. I used your 
post as an opportunity 

Re: [Lsr] BGP vs PUA/PULSE

[Hannes Gredler]

hi peter,

Just curious: Do you have an idea how to make short-lived LSPs compatible with 
the problem stated in
https://datatracker.ietf.org/doc/html/rfc7987

Would like to hear your thoughts on that.

thanks,

/hannes

On Tue, Nov 30, 2021 at 01:15:04PM +0100, Peter Psenak wrote:
| Hi Robert,
| 
| On 30/11/2021 12:40, Robert Raszuk wrote:
| > Hey Peter,
| > 
| >  > #1 - I am not ok with the ephemeral nature of the advertisements. (I
| >  > proposed an alternative).
| > 
| > LSPs have their age today. One can generate LSP with the lifetime of 1
| > min. Protocol already allows that.
| > 
| > 
| > That's a pretty clever comparison indeed. I had a feeling it will come
| > up here and here you go :)
| > 
| > But I am afraid this is not comparing apple to apples.
| > 
| > In LSPs or LSA flooding you have a bunch of mechanisms to make sure the
| > information stays fresh
| > and does not time out. And the default refresh in ISIS if I recall was
| > something like 15 minutes ?
| 
| yes, default refresh is 900 for the default lifetime of 1200 sec. Most
| people change both to much larger values.
| 
| If I send the LSP with the lifetime of 1 min, there will never be any
| refresh of it. It will last 1 min and then will be purged and removed from
| the database. The only difference with the Pulse LSP is that it is not
| purged to avoid additional flooding.
| 
| 
| > 
| > Today in all MPLS networks host routes from all areas are "spread"
| > everywhere including all P and PE routers, that's how LS protocols
| > distribute data, we have no other way to do that in LS IGPs.
| > 
| > 
| > Can't you run OSPF over GRE ? For ISIS Henk had proposal not so long ago
| > to run it over TCP too.
| > 
https://datatracker.ietf.org/doc/html/draft-hsmit-lsr-isis-flooding-over-tcp-00
| 
| you can run anything over GRE, including IGPs, and you don't need TCP
| transport for that. I don't see the relevance here. Are you suggesting to
| create GRE tunnels to all PEs that need the pulses? Nah, that would be an
| ugly requirement.
| 
| thanks,
| Peter
| 
| 
| > 
| > Seems like a perfect fit !
| > 
| > Thx,
| > R.
| 

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

Re: [Lsr] BGP vs PUA/PULSE

[Hannes Gredler]

hi les,

please see inline.

On Mon, Nov 29, 2021 at 10:39:17PM +, Les Ginsberg (ginsberg) wrote:
|Hannes -
| 
| 
| 
|Thanx for bringing a new voice into the discussion.
| 
|Please see inline.
| 
| 
| 
|> -Original Message-
| 
|> From: Hannes Gredler 
| 
|> Sent: Monday, November 29, 2021 1:27 AM
| 
|> To: Aijun Wang 
| 
|> Cc: 'Robert Raszuk' ; 'lsr' ; Les
|Ginsberg
| 
|> (ginsberg) ; 'Tony Li' ; 'Shraddha
| 
|> Hegde' ; Peter Psenak (ppsenak)
| 
|> 
| 
|> Subject: Re: [Lsr] BGP vs PUA/PULSE
| 
|>
| 
|> On Mon, Nov 29, 2021 at 09:42:57AM +0800, Aijun Wang wrote:
| 
|>
| 
|> [ ... ]
| 
|>
| 
|> |Option 3: The “DOWN” detection on ABR is same as PUA/PULSE, the
| 
|> different
| 
|> |is how to propagate such “DOWN” information. Considering we have
| 
|> observed
| 
|> |that all P/PE router in other areas may be interested such
|information,
| 
|> |your proposal will require every P/PE router run BGP-LS, which is
|not the
| 
|> |aimed deploy scenarios for BGP-LS.
| 
|>
| 
|> HG> BGP-LS has been conceived to solve the very problem of providing
| 
|> visibility of other
| 
|> area's link state. I fail to see what is out of scope here.
| 
|>
| 
|[LES:] BGP-LS only advertises what the IGPs themselves advertise.

HG> That is an implementation choice; the protocol allows multiple sources of 
information.
https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml#protocol-ids
And even standalone implementations are fine as the LSVR WG suggests.

|In this case, both IGP proposals involve ephemeral advertisements - so
|even if we were to define BGP-LS support for these new advertisements -
|they wouldn't persist long enough to be reflected in BGP-LS.

HG> you could model the liveliness tracker as a "source protocol" and advertise 
the state of your endpoint.

|So, I really don’t know why we are discussing BGP-LS in the context of
|this thread.

HG> because some people think it's a bad a idea to put this corner-case app in 
the very core of our networks.

|(This seems to be one example of what Acee correctly identified as this
|discussion going "off track".)

HG> please do not derail the discussion. It is well within the mandate of LSR 
to discuss solution space and have a healthy discussion
about the scalingaspects of a proposal. If the WG has concerns on the scaling 
properties and brings up alternatives to make a given
use-case work that is IMO fine and we may just use some airtime for that. After 
all it's link-state routing, right ?

| 
| 
| 
|> |Then, if IGP has such capabilities, why bother BGP? What is the
|benefit?
| 
|>
| 
|> HG> simply put: seperation of concerns. Agreed consensus is to mostly
|use
| 
|> the
| 
|> IGP for topology discovery and put the bulk of carrying reachability
| 
|> information
| 
|> into BGP which gives us:
| 
|>
| 
|[LES:] I am not convinced either side can claim "consensus" in this
|discussion. That is a work in progress. 😊

HG> by consensus i meant that the BGP/IGP split is common practise of building 
large scale networks.

|However, when you say IGPs are (exclusively?) for topology discovery - it
|seems to suggest that IGP shouldn’t be advertising prefix reachability at
|all. Hopefully, that is not what you intend.

HG> did not say that. of course we need minimal IP reachability for 
bootstrapping the iBGP transport mesh.
but we certainly do not use the IGP for carrying bulk routes at (Internet) 
scale.
 
|One of the points that still baffles me is the assertion of an
|architectural violation in the IGP proposals.
| 

HG> did not say that.

| 
|It is OK for IGPs to advertise all prefixes covered by a summary (i.e., do
|not summarize).
| 
|It is OK for IGPs to advertise multiple summaries (e.g., multiple /24s
|instead of a single /16).
| 
|It is even OK for IGPs to advertise some prefixes covered by a summary
|along with the summary (don’t know if any implementations do this - but
|they could).
| 
|None of this is an "architectural violation".
| 

HG> Again - Don't think its an architectual violation - I just think in it's 
current state
it has a lot of havoc potential under load.
 
|But advertising a summary and signaling the loss of reachability to a
|specific prefix covered by the summary is seen by some as an architectural
|violation.
| 
|Sorry, I still don't understand this argument.
|
| 
| 
|You can not like the approach. You can be concerned about scaling
|properties (more on that below). You can question the effectiveness of
|ephemeral advertisements.
| 
|These kinds of objections/concerns I can easily understand - even if we
|don’t agree on their significance.
| 
|But claiming that "IGPs are not supposed to d

Re: [Lsr] BFD aspects

[Robert Raszuk]

Hi Greg,

GIM2>> Now we have to reconcile states reported by RRs.
>

Not really. That "reconciliation" is native and automatic. No need to do
anything. If you are hearing updates from two RRs you only consider it DOWN
when both RRs withdraw the very path. Otherwise it is all UP.

#3 - If my network to PE fails but RR-PE works fine PE will be considered
>> alive. Network down detection is not the goal for discussing PUA/PULSE.
>>
> GIM2>> Thank you for the clarification. Though I wonder how such
> separation benefits network operation.
>

Well that can happen if you really use separate data plane for your control
channels from RRs. Honestly I have not seen much deployments which would
use such model.

Many thx,
R.
___
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

[Antoni Przygienda]

Not aware of any undisclosed IPR

From: "Marek Karasek (mkarasek)" 
Date: Tuesday, 30 November 2021 at 17:24
To: "Acee Lindem (acee)" , 
"draft-decraeneginsberg-lsr-isis-fast-flood...@ietf.org" 

Cc: "lsr@ietf.org" 
Subject: Re: IPR Poll for "IS-IS Fast Flooding" - 
draft-decraeneginsberg-lsr-isis-fast-flooding-00
Resent from: 
Resent to: , Tony Li , Chris 
Bowers , , , 
Bruno Decraene , , Peter Psenak 
, 
Resent date: Tuesday, 30 November 2021 at 17:24

[External Email. Be cautious of content]

Hi Acee,

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

Thanks,
Marek


From: "Acee Lindem (acee)" 
Date: Monday, 22 November 2021 at 15:13
To: "draft-decraeneginsberg-lsr-isis-fast-flood...@ietf.org" 

Cc: "lsr@ietf.org" 
Subject: IPR Poll for "IS-IS Fast Flooding" - 
draft-decraeneginsberg-lsr-isis-fast-flooding-00
Resent from: 
Resent to: , , 
, , , 
, , , 

Resent date: Monday, 22 November 2021 at 15:13

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


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] BFD aspects

[Greg Mirsky]

Hi Robert,
thank you for your kind words and the discussion. Please find my notes
in-lined below and tagged GIM2>>.

Regards,
Greg


On Tue, Nov 30, 2021 at 1:11 AM Robert Raszuk  wrote:

> Greg,
>
> Thank you so much for your input to this discussion. As you can see it is
> not easy to convince some folks :)
>
> I just want to clarify one thing in respect to using multihop BFD between
> RR and PE. There is nothing about data plane path detection with that
> suggestion. Basically BFD is used here as a better ping. No more no less.
>
> Few points:
>
> #1 - Yes, if my control plane RR-PE network fails and the normal data
> plane to PE is still up I will have a false positive. Solution: Use more
> than one RR.
>
GIM2>> Now we have to reconcile states reported by RRs. Doable but adds
complexity.

>
> #2 - Yes BFD process liveness or not on PE does not guarantee service
> liveness of the PE - that is always true as BFD does not check real service
> data plane processing anyway
>
GIM2>> Agree,

>
> #3 - If my network to PE fails but RR-PE works fine PE will be considered
> alive. Network down detection is not the goal for discussing PUA/PULSE.
>
GIM2>> Thank you for the clarification. Though I wonder how such separation
benefits network operation.

>
> Cheers,
> R.
>
>
>
>
>
> On Tue, Nov 30, 2021 at 5:08 AM Greg Mirsky  wrote:
>
>> Hi Aijun,
>> thank you for clarifying your goal. I have missed asking another question:
>>
>> What is the required failure detection time?
>>
>> For example, a 10 ms detection guarantee is required for local
>> protection. And that results in a 3.3 ms interval between the fault
>> detection packets (e.g., CCM or BFD). As I understand it, IGP is likely to
>> rely on single-hop BFD detection. Hence, 10 ms before PE's neighbor
>> discovers the failure. Then the IGP processes will start acting. Thus, I
>> don't see how IGP can guarantee anything less than 10 ms. Would you agree?
>>
>> Regards,
>> Greg
>>
>> On Mon, Nov 29, 2021 at 7:38 PM Aijun Wang 
>> wrote:
>>
>>> Hi, Greg:
>>>
>>>
>>>
>>> I understand that BFD can get the guaranteed failure detection time than
>>> other protocol that depends on the size of the network.
>>>
>>> What we want to emphasize is that the balance of deployment/operation
>>> overhead and the efficiency of the proposed solutions.
>>>
>>> For your questions, I think we can still get the millisecond failure
>>> detection time via the IGP itself(Far faster than the BGP hello timer for
>>> BGP use case; and also benefit for the tunnel services that has no hello
>>> timer).
>>>
>>> The actual time should certainly be verified later in simulation
>>> environment or in real network deployment.
>>>
>>>
>>>
>>> Best Regards
>>>
>>>
>>>
>>> Aijun Wang
>>>
>>> China Telecom
>>>
>>>
>>>
>>> *From:* Greg Mirsky 
>>> *Sent:* Tuesday, November 30, 2021 11:11 AM
>>> *To:* Aijun Wang 
>>> *Cc:* lsr ; Gyan Mishra ; Robert
>>> Raszuk 
>>> *Subject:* Re: [Lsr] BFD aspects
>>>
>>>
>>>
>>> Hi Aijun,
>>>
>>> what is the guaranteed failure detection time for the IGP-based solution?
>>>
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>> On Mon, Nov 29, 2021 at 7:07 PM Aijun Wang 
>>> wrote:
>>>
>>> Hi, Greg:
>>>
>>>
>>>
>>> Even the BFD auto-configuration extensions has been standardized and
>>> implemented, won’t the network be filled with the detect packets,
>>> instead of the user packets?
>>>
>>> For PUA/PULSE solution, the mentioned LSA will only be emerged when the
>>> node status change from “UP” to “DOWN”, but the BFD packet will be sent
>>> continuously when these PEs are active.
>>>
>>> Which one is efficient?
>>>
>>>
>>>
>>> Certainly, we will consider the massive failure situations, even it will
>>> occur in very rare circumstances.
>>>
>>>
>>>
>>> Best Regards
>>>
>>>
>>>
>>> Aijun Wang
>>>
>>> China Telecom
>>>
>>>
>>>
>>> *From:* Greg Mirsky 
>>> *Sent:* Tuesday, November 30, 2021 10:47 AM
>>> *To:* Aijun Wang 
>>> *Cc:* lsr ; Gyan Mishra ; Robert
>>> Raszuk 
>>> *Subject:* Re: [Lsr] BFD aspects
>>>
>>>
>>>
>>> Hi Aijun,
>>>
>>> thank you for confirming that it is not the conclusion one can arrive
>>> based on my discussion with Robert. Secondly, the problem you describe, I
>>> wouldn't characterize as a scaling issue with using multi-hop BFD
>>> monitoring path continuity in the underlay network. In my opinion, it is an
>>> operational overhead that can be addressed by an intelligent management
>>> plane or a few extensions in the control plane that is setting an overlay.
>>> Since the management plane is usually a proprietary solution, I invite
>>> anyone interested in working on BFD auto-configuration extensions in the
>>> control plane. I much appreciate references to the use cases that can
>>> benefit from such extensions.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>> On Mon, Nov 29, 2021 at 6:26 PM Aijun Wang 
>>> wrote:
>>>
>>> Hi, Greg:
>>>
>>>
>>>
>>> Firstly, regardless of which methods to be used for the multihop BFD
>>> approach, it is certainly the c

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

[Marek Karasek (mkarasek)]

Hi Acee,

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

Thanks,
Marek


From: "Acee Lindem (acee)" 
Date: Monday, 22 November 2021 at 15:13
To: "draft-decraeneginsberg-lsr-isis-fast-flood...@ietf.org" 

Cc: "lsr@ietf.org" 
Subject: IPR Poll for "IS-IS Fast Flooding" - 
draft-decraeneginsberg-lsr-isis-fast-flooding-00
Resent from: 
Resent to: , , 
, , , 
, , , 

Resent date: Monday, 22 November 2021 at 15:13

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] WG Adoption Call for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

[Les Ginsberg (ginsberg)]

As co-author, I support WG adoption.

I also strongly favor Experimental Track for this draft. This accurately 
reflects the state of this work.
One of the possible final outcomes of this work may be that multiple approaches 
work and that there is no need for standardization.  TBD
Until the need for standardization is demonstrated this work should remain 
experimental.

   Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Monday, November 22, 2021 6:07 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] BGP vs PUA/PULSE

[Tony Li]

Les,


> I am not convinced we are going to converge.


I concur. I propose that we agree to disagree.


> Note that my goal/expectation is not that one of us convinces the other as to 
> what is “best”. It is simply to get a clearer understanding regarding our 
> points of disagreement. But I am now less optimistic about that being 
> achievable.


I think that we have achieved clarity. :-)


> You’re intentionally breaking summarization and advertising liveness.  You 
> can claim that it’s just reachability, but it’s not.  If it were 
> reachability, then you’d be ok with a static prefix assignment.
>  
> [LES:] Your response mystifies me. I do not know how “static prefix 
> assignment” is relevant. I wasn’t proposing “dynamic prefix assignment”.



Ok, would you be happier with ’static prefix advertisement’?



> I was just trying to illustrate that prefixes covered by the summary could be 
> advertised using existing IGP advertisements even when the summary is being 
> advertised.
> It is still reachability. The determination of when to advertise the prefix 
> and when not to is still based upon whether the ABR has a path to the prefix 
> based on latest SPF calculation.


That smells much more like liveness.  This is one disagreement.


> You choose to rename such an advertisement as “liveness” rather than 
> “reachability” for no reason that I can see. It then allows you claim an 
> “architectural violation” – but this to me is a meaningless distraction.
> I was hoping to get rid of this distraction – but no such luck I see.


There’s very good reason. We make address assignments to areas so that we have 
a mapping from prefixes to topology. We make this a static mapping so that we 
don’t have to deal with continual flap. If a host within the prefix is up, then 
it is reachabie within that portion of the topology. That static property is 
what we call ‘reachability’.


> No, it doesn’t. Static summarization is the preferred approach.  It’s stable. 
>  
>  
> [LES:] This wasn’t the point of the example.


It is the point of our disagreement.


> I wasn’t promoting the example as desirable deployment choice. I was only 
> illustrating that it is the change in reachability(sic) that is the event. 
> With current IGP advertisements we would (of course) stop advertising 
> reachability when we do not have a path to a given prefix. The new 
> advertisements propose to advertise the loss of reachability to destinations 
> which are covered by a summary. That has advantages over a withdrawal (the 
> absence of an advertisement).


While that is still distasteful for scalability reasons, that would be 
preferable to injecting additional information at failure time. What advantages 
does that have?


> If you want to say that an operator should only have two choices:
> a)Advertise a summary or
> b)Advertise all reachable prefixes covered by a summary
>  
> I understand your POV even if I do not agree with it.
> But please do not obfuscate things by claiming a reachability advertisement 
> is now something else when it is triggered by the same event i.e., a change 
> in the reachability to a given destination.


I would not say that.  I think that the choices are simpler:
a) Advertise a summary.
b) Don’t bother with hierarchy.


> And, the use of tagging to identify the prefixes which may be advertised 
> using the new mechanism is one way to deal with scale issues.
>   
> How? If there are 10,000 tagged prefixes, how does that not become 10,000 
> negative leaks?
>  
> [LES:] This is one of many possible tools to address scaling issues. (I have 
> previously suggested others) Clearly this is only of benefit if, in a given 
> deployment, the number of prefixes for which loss of reachability 
> notifications is desired is modest and/or if used in conjunction w other 
> tools.
> Please do not twist my words.


I’m not trying to twist them, I’m trying to understand them. Tagging is not, in 
and of itself, a limitation. Harsh experience with previous scalability issues 
has taught me that what we think of as ‘modest’ becomes the customer’s version 
of ‘unlimited’. If there are other mechanisms, other than some arbitrary limit, 
they haven’t been discussed.

We’re proposing new mechanisms. We need to understand how they will be used in 
the field and we know that they will be abused in the worst ways possible. My 
concern is never about 1 or 2 additional prefixes. My concern is that it 
becomes tens of thousands and expectations that they propagated in 10ms even 
with a mass failure.

Our job is to ensure that the worst possible conditions still work. I’m not yet 
convinced and I don’t think we should be solving this in the IGP.

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

[Les Ginsberg (ginsberg)]

I am not aware of any undisclosed IPR.

Les



From: Acee Lindem (acee) 
Sent: Monday, November 22, 2021 6:12 AM
To: draft-decraeneginsberg-lsr-isis-fast-flood...@ietf.org
Cc: lsr@ietf.org
Subject: 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] IPR Poll for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

[Peter Psenak]

Hi Acee,

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

thanks,
Peter

On 22/11/2021 15:12, 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

[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

[Lsr] Node state distribution

[Robert Raszuk]

Hi,

The current PUA/PULSE discussion is aiming for letting the ingress PEs know
about egress PE failures. Alternatives to IGP domian wide flooding has been
discussed on other threads.

But I would like to bring to your attention a different point.

Imagine I am an ingress PE and have N paths for multi homed service to two
or more egress PEs.

>From pure operational POV my services and customers would be much more
efficient if I not only know if the remote egress PEs are up or down, but
also how busy those egress PEs are. Maybe one is at 90% fabric or queuing
utilization for the last 1h while guy next to it is just 5% of the same
metric as no one is selecting him as service best path.

Of course I see everyone (including myself) jumping that while very useful
this is not the role of IGP to communicate such data around. Well yes you
are right.

But the point is that if we want to build a bit more efficient and
intelligent WAN networks (just like SDWAN has done so already) we need such
additional information to be distributed irrespective of the underlay
routing.

And if we all agree with that then PUA/PULSE fit very nicely there too !

And if we continue to try to solve little point fixes/elements without
looking end to end especially without holistic view on what network role is
the outcome will be rather poor

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

Re: [Lsr] BGP vs PUA/PULSE

[Robert Raszuk]

> > Can't you run OSPF over GRE ? For ISIS Henk had proposal not so long ago
> > to run it over TCP too.
> >
> https://datatracker.ietf.org/doc/html/draft-hsmit-lsr-isis-flooding-over-tcp-00
>
> you can run anything over GRE, including IGPs, and you don't need TCP
> transport for that. I don't see the relevance here. Are you suggesting
> to create GRE tunnels to all PEs that need the pulses? Nah, that would
> be an ugly requirement.
>


Well I am not talking about PE-PE anything here. I am talking about
interested PEs setting such directed IGP sessions to ABRs who have the
information. And that can be just your local area ABRs if those will in
turn create similar sessions to "other side" area0 ABRs - endorsing
hierarchical design. Or it can be target area ABRs too. After all, the
number of ABRs in any network is usually not big.

Now obviously it would be pretty stupid to request anyone to do it by
confguration (regardless if this would be manual or automated). However,
injecting info indicating that capability of ABR in a given area and
allowing to simply apply encapsulation from PE to ABR with zero cfg seems
to be pretty trivial to accomplish.

And the reason I mentioned TCP was to avoid such encap.

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

Re: [Lsr] BGP vs PUA/PULSE

[Peter Psenak]

Hi Robert,

On 30/11/2021 12:40, Robert Raszuk wrote:

Hey Peter,

 > #1 - I am not ok with the ephemeral nature of the advertisements. (I
 > proposed an alternative).

LSPs have their age today. One can generate LSP with the lifetime of 1
min. Protocol already allows that. 



That's a pretty clever comparison indeed. I had a feeling it will come 
up here and here you go :)


But I am afraid this is not comparing apple to apples.

In LSPs or LSA flooding you have a bunch of mechanisms to make sure the 
information stays fresh
and does not time out. And the default refresh in ISIS if I recall was 
something like 15 minutes ?


yes, default refresh is 900 for the default lifetime of 1200 sec. Most 
people change both to much larger values.


If I send the LSP with the lifetime of 1 min, there will never be any 
refresh of it. It will last 1 min and then will be purged and removed 
from the database. The only difference with the Pulse LSP is that it is 
not purged to avoid additional flooding.





Today in all MPLS networks host routes from all areas are "spread"
everywhere including all P and PE routers, that's how LS protocols
distribute data, we have no other way to do that in LS IGPs.


Can't you run OSPF over GRE ? For ISIS Henk had proposal not so long ago 
to run it over TCP too.

https://datatracker.ietf.org/doc/html/draft-hsmit-lsr-isis-flooding-over-tcp-00


you can run anything over GRE, including IGPs, and you don't need TCP 
transport for that. I don't see the relevance here. Are you suggesting 
to create GRE tunnels to all PEs that need the pulses? Nah, that would 
be an ugly requirement.


thanks,
Peter




Seems like a perfect fit !

Thx,
R.


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

Re: [Lsr] BGP vs PUA/PULSE

[Robert Raszuk]

Hey Peter,

> #1 - I am not ok with the ephemeral nature of the advertisements. (I
> > proposed an alternative).
>
> LSPs have their age today. One can generate LSP with the lifetime of 1
> min. Protocol already allows that.


That's a pretty clever comparison indeed. I had a feeling it will come up
here and here you go :)

But I am afraid this is not comparing apple to apples.

In LSPs or LSA flooding you have a bunch of mechanisms to make sure the
information stays fresh
and does not time out. And the default refresh in ISIS if I recall was
something like 15 minutes ?

Today in all MPLS networks host routes from all areas are "spread"
> everywhere including all P and PE routers, that's how LS protocols
> distribute data, we have no other way to do that in LS IGPs.
>

Can't you run OSPF over GRE ? For ISIS Henk had proposal not so long ago to
run it over TCP too.
https://datatracker.ietf.org/doc/html/draft-hsmit-lsr-isis-flooding-over-tcp-00

Seems like a perfect fit !

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

Re: [Lsr] BGP vs PUA/PULSE

[Peter Psenak]

Robert,

On 30/11/2021 10:29, Robert Raszuk wrote:

Les,

*/I was just trying to illustrate that prefixes covered by the
summary could be advertised using existing IGP advertisements even
when the summary is being advertised. /**/It is still reachability.
The determination of when to advertise the prefix and when not to is
still based upon whether the ABR has a path to the prefix based on
latest SPF calculation./*

*/__ __/*

*/You choose to rename such an advertisement as “liveness” rather
than “reachability” for no reason that I can see. It then allows you
claim an “architectural violation” – but this to me is a meaningless
distraction. /**/I was hoping to get rid of this distraction – but
no such luck I see./*


You are correct that from ABR it may look like atomic reachability.

But if you look at the bigger picture what triggers this reachability is 
liveness detection between P and PE routers.


And I guess what really matters is not how we call it - what matters is 
what truly triggers our protocol actions.



*/[LES:] This wasn’t the point of the example. I wasn’t promoting
the example as desirable deployment choice. I was only illustrating
that it is the change in reachability(sic) that is the event. With
current IGP advertisements we would (of course) stop advertising
reachability when we do not have a path to a given prefix. The new
advertisements propose to advertise the loss of reachability to
destinations which are covered by a summary. That has advantages
over a withdrawal (the absence of an advertisement)./*


Perhaps. But it also has huge complexity on the clients (src PEs) which 
now need to bend to use this info. Something which is not in RIB 
disappears. I recall when you worked on RIB architecture one of the 
basic primitives was to always communicate protocol to protocol via RIB. 
Here we are talking about some not so elegant shortcuts. And not only in 
respect to protocols. Also touching FIB.


we have done the prototype. The changes to consume the pulse and trigger 
the BGP PIC were very small and simple.




It is perhaps the vendor's secret sauce how you use this new info. But 
by all means this is not what is today well known operational monitoring 
practice.


that does not make it wrong, does it?

thanks,
Peter



That is why the ephemeral nature of the proposed advertisements is IMO 
its disadvantage.


Thank you,
R.



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

Re: [Lsr] BGP vs PUA/PULSE

[Robert Raszuk]

Les,

*I was just trying to illustrate that prefixes covered by the summary could
> be advertised using existing IGP advertisements even when the summary is
> being advertised. **It is still reachability. The determination of when
> to advertise the prefix and when not to is still based upon whether the ABR
> has a path to the prefix based on latest SPF calculation.*
>
>
>
> *You choose to rename such an advertisement as “liveness” rather than
> “reachability” for no reason that I can see. It then allows you claim an
> “architectural violation” – but this to me is a meaningless distraction. **I
> was hoping to get rid of this distraction – but no such luck I see.*
>

You are correct that from ABR it may look like atomic reachability.

But if you look at the bigger picture what triggers this reachability is
liveness detection between P and PE routers.

And I guess what really matters is not how we call it - what matters is
what truly triggers our protocol actions.


*[LES:] This wasn’t the point of the example. I wasn’t promoting the
> example as desirable deployment choice. I was only illustrating that it is
> the change in reachability(sic) that is the event. With current IGP
> advertisements we would (of course) stop advertising reachability when we
> do not have a path to a given prefix. The new advertisements propose to
> advertise the loss of reachability to destinations which are covered by a
> summary. That has advantages over a withdrawal (the absence of an
> advertisement).*
>

Perhaps. But it also has huge complexity on the clients (src PEs) which now
need to bend to use this info. Something which is not in RIB disappears. I
recall when you worked on RIB architecture one of the basic primitives was
to always communicate protocol to protocol via RIB. Here we are talking
about some not so elegant shortcuts. And not only in respect to protocols.
Also touching FIB.

It is perhaps the vendor's secret sauce how you use this new info. But by
all means this is not what is today well known operational monitoring
practice.

That is why the ephemeral nature of the proposed advertisements is IMO its
disadvantage.

Thank you,
R.

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

Re: [Lsr] BFD aspects

[Robert Raszuk]

Greg,

Thank you so much for your input to this discussion. As you can see it is
not easy to convince some folks :)

I just want to clarify one thing in respect to using multihop BFD between
RR and PE. There is nothing about data plane path detection with that
suggestion. Basically BFD is used here as a better ping. No more no less.

Few points:

#1 - Yes, if my control plane RR-PE network fails and the normal data plane
to PE is still up I will have a false positive. Solution: Use more than one
RR.

#2 - Yes BFD process liveness or not on PE does not guarantee service
liveness of the PE - that is always true as BFD does not check real service
data plane processing anyway

#3 - If my network to PE fails but RR-PE works fine PE will be considered
alive. Network down detection is not the goal for discussing PUA/PULSE.

Cheers,
R.





On Tue, Nov 30, 2021 at 5:08 AM Greg Mirsky  wrote:

> Hi Aijun,
> thank you for clarifying your goal. I have missed asking another question:
>
> What is the required failure detection time?
>
> For example, a 10 ms detection guarantee is required for local protection.
> And that results in a 3.3 ms interval between the fault detection packets
> (e.g., CCM or BFD). As I understand it, IGP is likely to rely on single-hop
> BFD detection. Hence, 10 ms before PE's neighbor discovers the failure.
> Then the IGP processes will start acting. Thus, I don't see how IGP can
> guarantee anything less than 10 ms. Would you agree?
>
> Regards,
> Greg
>
> On Mon, Nov 29, 2021 at 7:38 PM Aijun Wang 
> wrote:
>
>> Hi, Greg:
>>
>>
>>
>> I understand that BFD can get the guaranteed failure detection time than
>> other protocol that depends on the size of the network.
>>
>> What we want to emphasize is that the balance of deployment/operation
>> overhead and the efficiency of the proposed solutions.
>>
>> For your questions, I think we can still get the millisecond failure
>> detection time via the IGP itself(Far faster than the BGP hello timer for
>> BGP use case; and also benefit for the tunnel services that has no hello
>> timer).
>>
>> The actual time should certainly be verified later in simulation
>> environment or in real network deployment.
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* Greg Mirsky 
>> *Sent:* Tuesday, November 30, 2021 11:11 AM
>> *To:* Aijun Wang 
>> *Cc:* lsr ; Gyan Mishra ; Robert
>> Raszuk 
>> *Subject:* Re: [Lsr] BFD aspects
>>
>>
>>
>> Hi Aijun,
>>
>> what is the guaranteed failure detection time for the IGP-based solution?
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>> On Mon, Nov 29, 2021 at 7:07 PM Aijun Wang 
>> wrote:
>>
>> Hi, Greg:
>>
>>
>>
>> Even the BFD auto-configuration extensions has been standardized and
>> implemented, won’t the network be filled with the detect packets,
>> instead of the user packets?
>>
>> For PUA/PULSE solution, the mentioned LSA will only be emerged when the
>> node status change from “UP” to “DOWN”, but the BFD packet will be sent
>> continuously when these PEs are active.
>>
>> Which one is efficient?
>>
>>
>>
>> Certainly, we will consider the massive failure situations, even it will
>> occur in very rare circumstances.
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* Greg Mirsky 
>> *Sent:* Tuesday, November 30, 2021 10:47 AM
>> *To:* Aijun Wang 
>> *Cc:* lsr ; Gyan Mishra ; Robert
>> Raszuk 
>> *Subject:* Re: [Lsr] BFD aspects
>>
>>
>>
>> Hi Aijun,
>>
>> thank you for confirming that it is not the conclusion one can arrive
>> based on my discussion with Robert. Secondly, the problem you describe, I
>> wouldn't characterize as a scaling issue with using multi-hop BFD
>> monitoring path continuity in the underlay network. In my opinion, it is an
>> operational overhead that can be addressed by an intelligent management
>> plane or a few extensions in the control plane that is setting an overlay.
>> Since the management plane is usually a proprietary solution, I invite
>> anyone interested in working on BFD auto-configuration extensions in the
>> control plane. I much appreciate references to the use cases that can
>> benefit from such extensions.
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>> On Mon, Nov 29, 2021 at 6:26 PM Aijun Wang 
>> wrote:
>>
>> Hi, Greg:
>>
>>
>>
>> Firstly, regardless of which methods to be used for the multihop BFD
>> approach, it is certainly the configuration overhead if you image there are
>> 10,000 PEs as Tony often raised as one example.
>>
>> Shouldn’t you configure each pair of them to detect the PE-PE connection?
>>
>> It is obvious not scalable.
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* Greg Mirsky 
>> *Sent:* Tuesday, November 30, 2021 10:18 AM
>> *To:* Aijun Wang 
>> *Cc:* Gyan Mishra ; Robert Raszuk <
>> rob...@raszuk.net>; lsr 
>> *Subject:* Re: [Lsr] BFD aspects
>>
>>
>>
>> Hi Aijun,
>>
>> could you please elaborate on how you see that this discussion leads to
>>

Re: [Lsr] BGP vs PUA/PULSE

[Peter Psenak]

Robert,

On 29/11/2021 23:53, Robert Raszuk wrote:

Hi Les,

Just to summarize my personal take on this thread in the light of your 
last email.


#1 - I am not ok with the ephemeral nature of the advertisements. (I 
proposed an alternative).


LSPs have their age today. One can generate LSP with the lifetime of 1 
min. Protocol already allows that. So you are "not ok" with what 
protocol allows already. I'm fine if that's your position, but making 
that an argument against the proposal is not correct IMHO.




#2 - I am not ok with spreading the information everywhere including all 
P and PE routers which do not need it.


Today in all MPLS networks host routes from all areas are "spread" 
everywhere including all P and PE routers, that's how LS protocols 
distribute data, we have no other way to do that in LS IGPs.


Summarization with what we propose reduces the "spread" significantly. 
And we cam easily address the "mass failures", so we will never generate 
as many pulses as we have host routes today. If you still don't like it, 
fine, but arguing that the existing distribution method in IGP is 
incorrect is not a valid argument IMHO.




#3 - 1 days ago you said: "The legitimate question is whether folks see 
it as appropriate to have an IGP based solution for the problem." So 
bringing a BGP alternative seems to be very much in line with your 
guidance for this thread. >
#4 - I am not sure it is OK for IGP to advertise a bunch of area local 
info to every IGP node. The fact that it was pushed through IETF with 
brute force does not make it a great protocol evolution. Maybe now it is 
time to close that gate ?


same as (2).

thanks,
Peter


Kind regards,
Robert


[LES:] BGP-LS only advertises what the IGPs themselves advertise. 

In this case, both IGP proposals involve ephemeral advertisements -
so even if we were to define BGP-LS support for these new
advertisements - they wouldn't persist long enough to be reflected
in BGP-LS.

So, I really don’t know why we are discussing BGP-LS in the context
of this thread.

(This seems to be one example of what Acee correctly identified as
this discussion going "off track".)


[LES:] I am not convinced either side can claim "consensus" in this
discussion. That is a work in progress. 😊

However, when you say IGPs are (exclusively?) for topology discovery
- it seems to suggest that IGP shouldn’t be advertising prefix
reachability at all. Hopefully, that is not what you intend.

__ __

One of the points that still baffles me is the assertion of an
architectural violation in the IGP proposals.

__ __

It is OK for IGPs to advertise all prefixes covered by a summary
(i.e., do not summarize).

It is OK for IGPs to advertise multiple summaries (e.g., multiple
/24s instead of a single /16).

It is even OK for IGPs to advertise some prefixes covered by a
summary along with the summary (don’t know if any implementations do
this - but they could).

None of this is an "architectural violation".

__ __

But advertising a summary and signaling the loss of reachability to
a specific prefix covered by the summary is seen by some as an
architectural violation.

Sorry, I still don't understand this argument.

__ __

You can not like the approach. You can be concerned about scaling
properties (more on that below). You can question the effectiveness
of ephemeral advertisements.

These kinds of objections/concerns I can easily understand - even if
we don’t agree on their significance.

But claiming that "IGPs are not supposed to do this"??

Not grokking this.

__ __

We have not added any new information to the IGP itself. We are only
suggesting a new form of advertisement to signal some information
already known to the IGP, but which is currently not advertised (in
some deployments) by the configuration of summaries.

[LES:] The questions of scale (as I have previously commented) are
very legitimate - and more has to be specified before an IGP
solution would be considered ready for deployment. But there are
tools easily applicable to address this (rate limiting, embedded
summarization, perhaps others).

The more significant point is to focus on the goal - which in this
usage is improved convergence time.

When the network is largely stable, convergence improvements can be
achieved w/o risk.

When widespread failures occur, real time signaling of any type is
unlikely to provide improved convergence - which is why the IGPs
today shift the focus from convergence to stability by slowing down
the rate of updates sent and SPFs performed. This is STILL true even
in the fast convergence/FRR era.

I see no reason why the same tools should not be used in this case.