Re: [Lsr] UPA

2022-07-07 Thread Robert Raszuk
links > > would expose. > > > > That's the real life scenario which I am trying to map to UPA (or in > > fact also DROID) mechanism. > > > > Many thx, > > Robert > > > > > > On Thu, Jul 7, 2022 at 2:03 PM Peter Psenak > <mailto:pp

Re: [Lsr] UPA

2022-07-07 Thread Robert Raszuk
. That's the real life scenario which I am trying to map to UPA (or in fact also DROID) mechanism. Many thx, Robert On Thu, Jul 7, 2022 at 2:03 PM Peter Psenak wrote: > On 07/07/2022 12:26, Robert Raszuk wrote: > > That's true. > > > > I am pointing out that this in some networ

Re: [Lsr] UPA

2022-07-07 Thread Robert Raszuk
; BGP PIC depends on the IGP convergence. We are not changing any of that > by UPA. > > thanks, > Peter > > > On 07/07/2022 12:02, Robert Raszuk wrote: > > Peter, > > > > All I am saying is that this may be pretty slow if even directly > > attached P rou

Re: [Lsr] UPA

2022-07-07 Thread Robert Raszuk
for all P routers to tell you that PE in fact went down. While in case of invalidating service routes the first trigger is good enough. To me this is significant architectural difference. Many thx, R. On Thu, Jul 7, 2022 at 11:54 AM Peter Psenak wrote: > On 07/07/2022 11:38, Robert Raszuk wr

Re: [Lsr] UPA

2022-07-07 Thread Robert Raszuk
PE. On Thu, Jul 7, 2022 at 11:35 AM Peter Psenak wrote: > Robert, > > On 07/07/2022 11:25, Robert Raszuk wrote: > > Hi Peter, > > > > > Section 4: > > > > > > "The intent of UPA is to provide an event driven signal of the > >

Re: [Lsr] UPA

2022-07-07 Thread Robert Raszuk
rom different carriers and may have for stability varying BFD timers. So here you would have to wait for the slowest link to be detected on the neighbouring P router as down. Thx, R. On Thu, Jul 7, 2022 at 10:16 AM Peter Psenak wrote: > Robert, > > On 06/07/2022 15:07, Robert Raszuk w

[Lsr] UPA

2022-07-06 Thread Robert Raszuk
Hi Peter, Can you please point me in the draft https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt to some section which specifies based on exactly what network flooding changes UPA will be generated by ABRs ? I think such text is not an implementation detail, but it is

Re: [Lsr] YANG requirements for IDR drafts (was Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20))

2022-07-05 Thread Robert Raszuk
ert, > > > On Jun 30, 2022, at 6:56 PM, Robert Raszuk wrote: > > Isn't the YANG section a requirement for all protocol extension > documents before they are sent for publications these days ? > > > We're not yet to the point where extensions to YANG modules are part

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

2022-06-30 Thread Robert Raszuk
Hello, I have a question ... likely to the WG chairs. Why https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-flood-reflection-07 does not have a YANG section ? Is there a separate document for it just like we see a separate document for BGP-LS encoding ? Isn't the YANG section a

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

2022-06-16 Thread Robert Raszuk
UPAs may not even contain the advertised locator in SIDs. That is not clearly spelled out what exactly ABRs should advertise. I presume: a) something which was flooded in the local domain and was not being leaked AND b) something which stopped to be flooded in a local domain AND c) there is local

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

2022-06-16 Thread Robert Raszuk
Bruno, Actually I like your flag suggestion for an additional and different reason. If someone does not need to flood UPAs in any remote area it is trivial to filter those on the ABRs connecting those areas to the core. Otherwise such filtering could be more difficult if at all possible. Thx,

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

2022-06-16 Thread Robert Raszuk
Gunter, (1) Multiple-ABRs > > > > I was wondering for example if a ingress router receives a PUA signaling > that a given locator becomes unreachable, does that actually really signals > that the SID ‘really’ is unreachable for a router? > Aas there is no association between node_id (perhaps

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

2022-06-16 Thread Robert Raszuk
Hi Gyan, While I agree with your final conclusion and description there is one important detail missing. PODs consist of both network elements and compute nodes. Virtualization happens in the latter. Dynamic routing between those almost in all cases talk BGP in the underlay not IGP simply as

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

2022-06-15 Thread Robert Raszuk
> > looks to me that you are trying to steer the discussion towards the BGP > based solution. Not something I'm interested on this thread. > Not at all. It was you not me who used argument that UPA/PUA is useful for networks with no BGP ... example: Quote: *"I have explained that several

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

2022-06-15 Thread Robert Raszuk
> Traffic will initially switch to alternate path, if any, an > later the native mechanism (BGP signalling, tunnel keepalive, etc), will > take over and bring it to its final state. > On one hand you are saying that UPA is useful where there is no BGP. So let's talk about such a scenario. Also

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

2022-06-15 Thread Robert Raszuk
: > Robert, > > On 15/06/2022 14:13, Robert Raszuk wrote: > > Peter, > > > > the meaning of LSInfinity has been defined decades ago. No matter how > > > > much you may not like it, but it means unreachable. > > > > > > True. But th

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

2022-06-15 Thread Robert Raszuk
Peter, the meaning of LSInfinity has been defined decades ago. No matter how > much you may not like it, but it means unreachable. True. But that brings another question ... Do you envision to use UPA also to indicate planned maintenance of a node ? Thx, R.

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

2022-06-14 Thread Robert Raszuk
> Well, we can blame marketing all we want. All I know is that we, as a > group, failed to come together and present a unified front with > interoperable implementations. That left us in a position where marketing > is pushing rocks up hills and customers are waiting for the dust to settle. I

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

2022-06-14 Thread Robert Raszuk
Hi Tony, > So, can we PLEASE stop beating a dead horse? Are you stating that computing dynamic flooding topologies has no use case outside of MSDCs or for that matter ANY-DCs ? Thx, R. PS. It is true that folks even running 10 racks think BGP is the only choice for the underlay but to me this

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

2022-06-14 Thread Robert Raszuk
ped the discussion to summaries. I realize PUE also wants to cover P failures so in this case each P is also equally important. Thx, R, On Tue, Jun 14, 2022 at 3:57 PM Acee Lindem (acee) wrote: > Speaking as WG member: > > > > *From: *Lsr on behalf of Robert Raszuk < > rob...@raszu

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

2022-06-14 Thread Robert Raszuk
All, > What is wrong with simply not doing summaries What's wrong is that you are reaching the scaling issue much sooner than when you inject summaries. Note that the number of those host routes is flooded irrespective of the actual need everywhere based on the sick assumption that perhaps they

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

2022-06-14 Thread Robert Raszuk
Hello Gunter, I agree with pretty much all you said except the conclusion - do nothing :). To me if you need to accelerate connectivity restoration upon an unlikely event like a complete PE failure the right vehicle to signal this is within the service layer itself. Let's keep in mind that links

[Lsr] Protection between flex-algo topologies

2022-05-18 Thread Robert Raszuk
e experience with “fallback”. It is complex > to implement – especially in the forwarding plane – and would not be my > first choice as a solution. > > > > ?? > > > > Les > > > > > > *From:* Lsr *On Behalf Of * Robert Raszuk > *Sent:* Tuesday, M

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

2022-05-18 Thread Robert Raszuk
at deployment model IMO should get attention and be addressed in base flex-algo specs. Cheers, Robert On Wed, May 18, 2022 at 11:46 AM Peter Psenak wrote: > Robert, > > On 18/05/2022 10:53, Robert Raszuk wrote: > > Peter, > > > > It is not about someone thinking if this

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

2022-05-18 Thread Robert Raszuk
Missed it - sorry: s/ control plane CPUs and data plane FIBs / control plane CPUs and data plane FIBs with LFA or R-LFA enabled per topo/ On Wed, May 18, 2022 at 10:53 AM Robert Raszuk wrote: > Peter, > > It is not about someone thinking if this is a good idea or not. It is > abo

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

2022-05-18 Thread Robert Raszuk
gt; Peter > > > > On 17/05/2022 19:58, Robert Raszuk wrote: > > Hi Peter, > > > > Enabling local protection on all nodes in all topologies may also not be > > the best thing to do (for various reasons). > > > > While I agree that general fallback may be

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

2022-05-17 Thread Robert Raszuk
> Robert, > > On 17/05/2022 14:14, Robert Raszuk wrote: > > Ok cool - thx Peter ! > > > > More general question - for any FlexAlgo model (incl. SR): > > > > Is fallback between topologies - say during failure of primary one - > > only allowed on the ingress t

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

2022-05-17 Thread Robert Raszuk
Peter Psenak wrote: > Hi Robert, > > > On 17/05/2022 12:11, Robert Raszuk wrote: > > > > Actually I would like to further clarify if workaround 1 is even doable > ... > > > > It seems to me that the IP flexalgo paradigm does not have a way for > > mor

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

2022-05-17 Thread Robert Raszuk
, 2022 at 12:01 PM Robert Raszuk wrote: > Folks, > > A bit related to Aijun's point but I have question to the text from the > draft he quoted: > >In cases where a prefix advertisement is received in both a IPv4 >Prefix Reachability TLV and an IPv4 Algorithm Prefix

[Lsr] Fwd: Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

2022-05-17 Thread Robert Raszuk
Folks, A bit related to Aijun's point but I have question to the text from the draft he quoted: In cases where a prefix advertisement is received in both a IPv4 Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability TLV, the IPv4 Prefix Reachability advertisement MUST be

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

2022-04-14 Thread Robert Raszuk
Hi John, In the IETF context I have always associated ‘data plane’ with packet > forwarding, > No one disputes that. But the fact that various sub-data-planes are built on top of base physical data planes needs to be clearly distinguished. Kind regards, R.

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

2022-04-14 Thread Robert Raszuk
Hi Robert, > > On 14/04/2022 11:21, Robert Raszuk wrote: > > Hi Peter, > > > > Term "data-plane" usually means physical resources links, switch fabric, > > ASIC etc ... so I am afraid it will also generate confusion with default > > data plane. > > &

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

2022-04-14 Thread Robert Raszuk
Hi Peter, Term "data-plane" usually means physical resources links, switch fabric, ASIC etc ... so I am afraid it will also generate confusion with default data plane. How about two alternatives: - custom/logical topology - logical-data-plane Thx, Robert. On Thu, Apr 14, 2022 at 9:27 AM

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

2022-04-13 Thread Robert Raszuk
Hi Ketan, > KT2> I see the primary use case for IP FlexAlgo (or another data plane) > > to be that the data plane is used by itself. In the (rare?) case where > > multiple data planes are required to coexist, it is simpler both from > > implementation and deployment POV to use different algos. It

Re: [Lsr] New Version Notification for draft-li-lsr-droid-00.txt

2022-04-04 Thread Robert Raszuk
Hi Tony, Just two follow up points, #1 - I can't stop the feeling that DROID is very IGP centric and not generic enough. Do you think we need DROID-2 to start offloading BGP or at least stop trashing it ? Or you think that DROID as proposed could take on day one flowspec v2 with its various

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-droid-00.txt

2022-04-04 Thread Robert Raszuk
Hi Tony, Very happy to see this draft. First question - the draft seems to be focusing on hierarchical IGPs and is clearly driven by liveness propagation discussion. But the motivation of offloading non routing information from IGPs (and/or BGP) is also full applicable to non hierarchical IGPs

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

2022-03-31 Thread Robert Raszuk
cenario is described in > https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-3.2 > . > > The corresponding solution will be updated later. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

2022-03-30 Thread Robert Raszuk
hable information ? Thx a lot, Robert On Wed, Mar 30, 2022 at 10:48 AM Aijun Wang wrote: > Hi, Robert: > > > > *From:* Robert Raszuk > *Sent:* Tuesday, March 29, 2022 3:53 PM > *To:* Aijun Wang > *Cc:* Tony Li ; Aijun Wang ; > lsr > *Subject:* Re: [Lsr] Is it ne

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

2022-03-29 Thread Robert Raszuk
t Regards > > > > Aijun Wang > > China Telecom > > > > *From:* Robert Raszuk > *Sent:* Monday, March 28, 2022 5:01 PM > *To:* Aijun Wang ; Tony Li > *Cc:* Aijun Wang ; lsr > *Subject:* Re: [Lsr] Is it necessary to define new PUB/SUB model to > moni

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

2022-03-28 Thread Robert Raszuk
Aijun, > For PUAM, the receiver NEED NOT register anything. > Once the node fails, all the receivers(normally the nodes within one area) will be notified. That's a spec bug not a feature. Not only those egress nodes which would have otherwise register will get it with PUAM, but also all P nodes

Re: [Lsr] New Subject: Is Flex-Algo One App or Many (was “RE: IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit”)

2022-03-28 Thread Robert Raszuk
opportunity to improve. > > > > Rgds > > Shraddha > > > > > > > > Juniper Business Use Only > > *From:* Robert Raszuk > *Sent:* Sunday, March 27, 2022 5:22 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* lsr ; Christian Hopps ; Shraddha > Hegde

Re: [Lsr] New Subject: Is Flex-Algo One App or Many (was “RE: IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit”)

2022-03-26 Thread Robert Raszuk
to abbreviate that as “Application”. If you > find that confusing, we can all try to use the more complete name. > > But whatever name we use, that is what is being referenced when we discuss > the use of ASLA. > > > >Les > > > > *From:* Robert Raszuk > *Sent:*

Re: [Lsr] New Subject: Is Flex-Algo One App or Many (was “RE: IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit”)

2022-03-26 Thread Robert Raszuk
cs is to be used for > that algo. But in doing so, the App associated with each of the Generic > Metric advertisements will be Flex-Algo. > > > > Les > > > > *From:* Robert Raszuk > *Sent:* Saturday, March 26, 2022 9:10 AM > *To:* Les Ginsberg (ginsberg)

Re: [Lsr] New Subject: Is Flex-Algo One App or Many (was “RE: IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit”)

2022-03-26 Thread Robert Raszuk
nderstand it and want > to do a major rewrite of it – I am not sure which. > > But either way, none of this has anything to do with the original thread. > > > >Les > > > > *From:* Robert Raszuk > *Sent:* Saturday, March 26, 2022 3:43 AM > *To:* Christian Hopps

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

2022-03-26 Thread Robert Raszuk
gold etc ... Now tell me how does it make sense to enable each app on the link delay attribute ? Cheers, Robert On Sat, Mar 26, 2022 at 6:42 AM Christian Hopps wrote: > > Robert Raszuk writes: > > > Les, > > > > I don't think this is noise. > > &g

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

2022-03-25 Thread Robert Raszuk
erization isn’t accurate. > > > > I don’t think this sub-thread is useful – you are adding noise to the > conversation. > > > > If you want to discuss offline – please contact me directly. > > > >Les > > > > > > *From:* Robert Raszuk

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

2022-03-25 Thread Robert Raszuk
> > I don’t think there is anything else that needs to be said. > > > >Les > > > > *From:* Robert Raszuk > *Sent:* Friday, March 25, 2022 4:53 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* Shraddha Hegde ; Martin Horneffer < > m...@lab.dtag.de>

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

2022-03-25 Thread Robert Raszuk
are off-topic with your post. > > > >Les > > > > > > *From:* Robert Raszuk > *Sent:* Friday, March 25, 2022 4:41 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* Shraddha Hegde ; Martin Horneffer < > m...@lab.dtag.de>; lsr@ietf.org > *Subject:* Re

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

2022-03-25 Thread Robert Raszuk
Hi Les, Let me clarify if I read you correctly ... Are you saying that because quoted RFCs have been published in Oct 2020 no one has a right to define any new standard link attributes any more as implementations are closed ? Including those which would be common to all applications on a link ?

Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

2022-03-08 Thread Robert Raszuk
page but not much content there ... Best, Robert. On Tue, Mar 8, 2022 at 3:11 PM Acee Lindem (acee) wrote: > Hi Robert, > > > > *From: *Robert Raszuk > *Date: *Tuesday, March 8, 2022 at 7:00 AM > *To: *Acee Lindem > *Cc: *Aijun Wang , Alvaro Retana < > alvaro.

Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

2022-03-08 Thread Robert Raszuk
Can you please list those standards ? Thank you, R. On Tue, Mar 8, 2022 at 12:36 PM Acee Lindem (acee) wrote: > Hi Robert, > > > > *From: *Robert Raszuk > *Date: *Tuesday, March 8, 2022 at 4:09 AM > *To: *Acee Lindem > *Cc: *Aijun Wang , Alvaro Retana < > alv

Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

2022-03-08 Thread Robert Raszuk
8, 2022 at 4:02 AM Acee Lindem (acee) wrote: > Hi Aijun, > > > > > > > > *From: *Aijun Wang > *Date: *Monday, March 7, 2022 at 9:41 PM > *To: *Acee Lindem , Robert Raszuk , > 'Alvaro Retana' > *Cc: *'Lin Han' , "lsr@ietf.org" > *Subject: *

Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

2022-03-07 Thread Robert Raszuk
Hi Alvaro, Practically speaking, yes Monitor nodes are cool to have. But so are the Controller nodes. The difference would be that in both cases there is no topology information being injected by such nodes, however in the latter case the additional information could be injected. Such

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

2022-03-02 Thread Robert Raszuk
Hi Tony, > If FlexAlgo is adopted, then we should expect that it will get stressed > and that further conditions will be added to a FAD. The problem will only > become worse the more success that FlexAlgo has. It sounds to me like you > want FlexAlgo to fail, which seems strange. Well I have a

Re: [Lsr] Adoption Question Stub-Link vs RFC5316

2022-02-18 Thread Robert Raszuk
Hi Chris, Tony Li (at least) seemed to think that it was useful to be able to attach > TE attributes to a link, not just to prefixes. Perhaps I've missed this in > the thread but what current mechanism (rfc?) are you referring to, to > identify a link and attach TE attributes to it? I have two

Re: [Lsr] Adoption Question Stub-Link vs RFC5316

2022-02-18 Thread Robert Raszuk
Hi Aijun, I do have some sympathy to what you are trying to do here. But I also have a concern if IGP is the right protocol to load it and use it disseminate completely opaque to its main role information. Imagine your CAN use case and use of areas with summarization. The ingress nodes/machines

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-02-13 Thread Robert Raszuk
Thu, Feb 10, 2022 at 10:59 AM Acee Lindem (acee) 40cisco@dmarc.ietf.org> wrote: > >> Hi Robert, >> >> This is great to hear – I thought you wanted to make this required for >> implementation as opposed to a recommendation. >> >> Thanks, >> >

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-02-10 Thread Robert Raszuk
Hi Acee, > There was debate regarding making the delay timer described in section 5 a normative requirement. I see added into new version of the draft the following text into section 5: The use of OSPF BFD strict- mode along with mechanisms such as hold-down *(a delay in the initial

Re: [Lsr] Lsr Digest, Vol 49, Issue 24

2022-02-07 Thread Robert Raszuk
gh). IMO, link quality > issue is outside the scope of this draft. > > Thanks > Albert > > From: Robert Raszuk To: Les Ginsberg < > ginsb...@cisco.com> > Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" > - draft-ietf-lsr-ospf-bf

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-02-06 Thread Robert Raszuk
Les, Please kindly present the facts. The facts are that equivalent functionality in OSPF which has been approved for years uses a configurable timer which allows both - to wait for BFD as well to make sure that BFD stays UP till that timer expires. The point I even started this discussion was

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-02-06 Thread Robert Raszuk
ent to change its FSM in that respect. I do not see why this should not be at least described in the draft. Anyhow enough time spent on this ... Many thx, Robert On Sun, Feb 6, 2022 at 11:29 PM Christian Hopps wrote: > > Robert Raszuk writes: > > > Hi Les, > > > >

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-02-06 Thread Robert Raszuk
Dampening can be used as an unconditional UP transition suppression buffer. The same applies to interfaces which went down and came UP after max-suppress-time had already expired. Thx, R. On Sun, Feb 6, 2022 at 11:05 PM Les Ginsberg (ginsberg) wrote: > Robert – > > > > > >

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-02-06 Thread Robert Raszuk
Hi Les, > There is nothing in RFC 5880 (nor in, what I consider to be even more > relevant, RFC 5882) that requires a BFD implementation to signal UP state > to a BFD client within a specific time following transition of the BFD > state machine to UP . An implementation is free to introduce a

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-02-06 Thread Robert Raszuk
draft to bring up OSPF adj. without risk of it to shortly go down. Thx, R On Sun, Feb 6, 2022 at 6:24 PM Gyan Mishra wrote: > Hi Robert > > On Sun, Feb 6, 2022 at 6:11 AM Robert Raszuk wrote: > >> Gyan, >> >> > Overall I believe the goal of the strict mode BFD

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-02-06 Thread Robert Raszuk
hese additional capabilities (e.g., MTU testing and link quality > determination beyond what is already in BFD) in a separate draft. > > Thanks, > > Acee > > > > *From: *Robert Raszuk > *Date: *Sunday, February 6, 2022 at 6:11 AM > *To: *Gyan Mishra > *Cc: *Acee Lindem

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-02-06 Thread Robert Raszuk
Gyan, > Overall I believe the goal of the strict mode BFD “wait for BFD” is accomplished > and solve all problems I do not agree with this statement. As currently defined in the posted version of the draft "wait for BFD" means wait for BFD control packets to bring the session up. The session

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-02-04 Thread Robert Raszuk
> leaking of backbone routes without summarization. Also note that the > virtual link endpoint could be reachable in the transit area but may not be > up. Multi-hop BFD would still be useful for a virtual link. > > Thanks, > > Acee > > > > *From: *Robert Raszuk >

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-02-04 Thread Robert Raszuk
Muthu, If you are using virtual link why is this still multihop BFD ? Thx, R. On Fri, Feb 4, 2022 at 6:22 PM Muthu Arul Mozhi Perumal < muthu.a...@gmail.com> wrote: > Hi Ketan, > > Sure, looking forward to the clarification in the draft on multi-hop BFD.. > > Just curious, are there

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-02-01 Thread Robert Raszuk
Ketan, > What the OSPF draft discusses in Sec 5 is a "hold-down" wait period where > even though the BFD session is established the protocol FSM does not > proceed further until a period of time has passed to ensure the stability > of the BFD session. > Which protocol FSM ? BFD FSM or OSPF FSM

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-31 Thread Robert Raszuk
Hey Albert, Ok now we are in sync as far as what is the topic. I think such a delay is very useful and completely in the spirit of OSPF or ISIS strict-mode operation. So I do recommend that the draft should discuss it. The default can be 0 if you think that is the proper value. But the

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-31 Thread Robert Raszuk
long in this draft. Which is why I agree with everything you > say below except for your perception that you are agreeing with Robert. You > are actually agreeing with myself, Albert, Ketan.  > > > > Thanx for your participation. > > > > Les > > > > *From

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-31 Thread Robert Raszuk
nted at the OSPF level. >>> >>> >>> >>> Once you have strict mode support, the sequence becomes: >>> >>> >>> >>> a)BFD goes down >>> >>> b)OSPF goes down in response to BFD >>> >>> c)BFD comes back u

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-31 Thread Robert Raszuk
ig deeper into what could be a very lengthy discussion. If you > really want to pursue this idea, I suggest you write a new draft. > > > >Les > > > > *From:* Robert Raszuk > *Sent:* Monday, January 31, 2022 6:59 AM > *To:* Albert Fu ; Les Ginsberg (ginsberg) &

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-31 Thread Robert Raszuk
clients benefit from this. Ad if the link is still > unstable, it is more likely that the BFD session will go down during the > delay period than it would be for OSPF because the BFD timers are > significantly more aggressive. > > (BTW, this behavior can be done w/o a BFD protocol ext

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-31 Thread Robert Raszuk
. Ad if the link is still > unstable, it is more likely that the BFD session will go down during the > delay period than it would be for OSPF because the BFD timers are > significantly more aggressive. > > (BTW, this behavior can be done w/o a BFD protocol extension – it is > purely a

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-30 Thread Robert Raszuk
this behavior can be done w/o a BFD protocol extension – it is > purely an implementation choice.) > > > > From a design perspective, dampening is always best done at the lowest > layer possible. In most cases, interface layer dampening is best. If that > is not reliable fo

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-30 Thread Robert Raszuk
Hi Ketan, > It explains the scenario of a noisy link that experiences traffic drops. The point is that BFD may or may not detect noisy links or links with "degraded or poor quality". There are many failure scenarios - especially brownouts - where BFD will continue to run just fine over a link

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-30 Thread Robert Raszuk
Hi Ketan, I would like to point out that the draft discusses the BFD "dampening" or > "hold-down" mechanism in Sec 5. We are aware of BFD implementations that > include such mechanisms in a protocol-agnostic manner. > BFD dampening or hold-time are completely orthogonal to my point. Both have

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-30 Thread Robert Raszuk
layer or >> in the BFD implementation. >> >> I am familiar with implementations which apply this timer at the protocol >> level (AKA BFD client in this context) and this is done precisely because >> the protocol does NOT have the functionality being defined in this draft.

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-29 Thread Robert Raszuk
Hi Les, That timer and its consistency on both ends clearly belongs to OSPF not to > BFD. > > *[LES:] I disagree. The definition of UP state belongs to the BFD > protocol/implementation.* > > *If you don’t want BFD clients (like OSPF) to react “too quickly” then > build additional config/logic

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-29 Thread Robert Raszuk
gt; Once you have implemented “wait-for-BFD” logic as defined in this draft you > do not need additional delay timers in the protocol. > > > > I don’t think the suggestions you are making belong in this document. > > > > Les > > > > > > *From:* Lsr

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-29 Thread Robert Raszuk
Acee, > I don’t anyone has implemented the later capability. This MTU test > extension could be added in a separate draft if there were a strong > requirement. > I think you are mixing an example of what BFD could be doing to make sure the link is fine with the delay timer allowing it to do

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-29 Thread Robert Raszuk
Hi Acee, Can you suggest text which with you’d be happy? I’m sure the authors would > add you to the acknowledgements. > Actually instead of suggesting any new text I would suggest to delete the two below sentences and it will be fine: *"In certain other scenarios, a degraded or poor quality

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-29 Thread Robert Raszuk
Hi Albert, > [AF] This draft ensures that BFD can be used to detect failure quickly > when there is a complete path failure between the nodes. You are right that > there are many other types of failure that BFD cannot detect. > > Indeed, but the draft says otherwise. I think that needs to be

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

2022-01-29 Thread Robert Raszuk
Hi Ketan and all, I support this draft - it is a useful addition. There are two elements which I would suggest to adjust in the text before publication. *#1 Overpromise* Even below you say: > Since there is a issue with forwarding *(which is what BFD detects)* and in the text we see: "In

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

2022-01-26 Thread Robert Raszuk
Hi Les, Yes you are correct. It is a classic pull vs push model. Push gives you notification about state. That's it. Pull gives you much more as it includes e2e elements of the data plane - of course for a bit higher cost. I would not disregard any of the above. We have been having similar

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

2022-01-26 Thread Robert Raszuk
> The pulse solution does not suffer from the scale issues. It shifts that "suffering" to flood the entire domain with information which is not needed on P routers and selectively useful on the remote PEs. Also fast signaling the fact that PE may have been disconnected from the network for a few

Re: [Lsr] BGP vs PUA/PULSE

2022-01-25 Thread Robert Raszuk
ed via the > management system? > > Aijun Wang > China Telecom > > On Jan 25, 2022, at 23:28, Robert Raszuk wrote: > >  > > Auto discovery is described in the draft. > > You may also provision this session by your management plane just like you > push 1000s

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

2022-01-25 Thread Robert Raszuk
Hi Tony, If a given PE needs to get all notifications from all other PEs it is > sufficient that it sends to local ABRs a single registration in a form of > 0.0.0.0/0 and be done. > > > If you look a bit more carefully, you will find that registering for 0/0 > doesn’t work without a bit more

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

2022-01-25 Thread Robert Raszuk
. Thx, R. On Tue, Jan 25, 2022 at 4:42 PM Peter Psenak wrote: > On 25/01/2022 15:18, Robert Raszuk wrote: > > Peter, > > > > You clearly missed the added new sentence to section 4.3 in version -01 > > > > It is RECOMMENDED that the ABR register for the >

Re: [Lsr] BGP vs PUA/PULSE

2022-01-25 Thread Robert Raszuk
ang > China Telecom > > On Jan 25, 2022, at 21:21, Robert Raszuk wrote: > >  > Aijun, > > No, I think you misunderstanding our purpose. >> > > You are using this argument towards a number of people ... I recommend you > reconsider. > > >> The

Re: [Lsr] BGP vs PUA/PULSE

2022-01-25 Thread Robert Raszuk
No. Run this node liveness service on ABR or on any other IGP node in an area. On Tue, Jan 25, 2022 at 4:01 PM Aijun Wang wrote: > Hi, Robert: > > You mean make every PE as the register server? > > Aijun Wang > China Telecom > > On Jan 25, 2022, at 21:21, Robert Rasz

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

2022-01-25 Thread Robert Raszuk
Peter, You clearly missed the added new sentence to section 4.3 in version -01 It is RECOMMENDED that the ABR register for the most specific prefix that is less specific than the original prefix. Thx, R On Tue, Jan 25, 2022 at 2:57 PM Peter Psenak wrote: > On 25/01/2022 14:07, Rob

Re: [Lsr] BGP vs PUA/PULSE

2022-01-25 Thread Robert Raszuk
Aijun, No, I think you misunderstanding our purpose. > You are using this argument towards a number of people ... I recommend you reconsider. > The proposed solution can fit in small network, or large network and RR > can locate anywhere the operator want to place. We have no assumption about

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

2022-01-25 Thread Robert Raszuk
Peter, Your math is off. > 1. 100k registrations in each ABR, 10 million network wide ABRs will "aggregate" atomic registrations to summaries when passing them to other ABRs. Please recalculate, Thx, R. On Tue, Jan 25, 2022 at 12:25 PM Peter Psenak wrote: > Tony, > > I'm going to use my

Re: [Lsr] BGP vs PUA/PULSE

2022-01-25 Thread Robert Raszuk
Aijun, The solution can’t rely only on the limited assumption. > And the protocol extensions can not be justified based on the limited corner cases of broken network designs. And, actually, the PE are Provider Edge Router, we always locate them at > the non-backbone area in large network ,

Re: [Lsr] BGP vs PUA/PULSE

2022-01-25 Thread Robert Raszuk
Aijun, [WAJ] X aims to how to withdraw the VPN prefixes with the mentioned > extended communities, right? > Extended communities have nothing to do with this discussion at all. > Y aims to how assist the RR get the prefix cost from one node that other > than the RR itself. Right? > No. > I

Re: [Lsr] BGP vs PUA/PULSE

2022-01-25 Thread Robert Raszuk
Aijun, On Tue, Jan 25, 2022 at 10:30 AM Aijun Wang wrote: > Hi, Robert: > > > > So the main point here is that yes it is highly recommended to use > summaries across areas. But what's not clear (at least to me) is if we > really need to signal node liveness in IGP to accomplish the ultimate

Re: [Lsr] BGP vs PUA/PULSE

2022-01-25 Thread Robert Raszuk
> > As we’ve been saying for months now, the ordering is: > > 1) Leak PE loopbacks > 2) Pub/Sub > 3) Carry loopbacks in BGP and recurse > 4) Multi-hop BFD > 5) Pulse > 6) PUA I would like to actually add to this list two alternatives which some vendors have been shipping for decades: X)

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

2022-01-24 Thread Robert Raszuk
proposal since he doesn’t think the IGP should be in the business of > sending node liveness information. > > The service itself doesn’t even need to be running on a router at all. > > > >Les > > > > > > *From:* Robert Raszuk > *Sent:* Monday, January 24

<    1   2   3   4   5   6   >