Re: [Lsr] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same

[Gyan Mishra]

Hi Adrian,

In line

Kind Regards

Gyan
On Sun, Nov 15, 2020 at 7:04 AM Adrian Farrel  wrote:

> Hi Gyan,
>
>
>
> Sorry, I missed this (got caught on a filter cos it was a bit spammed to a
> lot of lists :-).
>
>
>
> > I have noticed that after reviewing many drafts across many WGs it seems
> in the
>
> > industry that the lines seem to be blurred between a PCE controller, ODL
> or
>
> > Openflow SDN Controller and a Netconf/Yang NMS Controller ZTP & Day X
>
> > provisioning.
>
>
>
> Yes, blurriness our speciality.
>
>  Gyan> :)
>
> You my find RFC 7491 useful in this respect, although it is a little
> dated. And, of course, RFC 8283 is a good starting point.
>
>  Gyan> Thanks
>
> As this is a software sitting on a server you can have a swiss army knife
> server that
>
> > does everything from PCE path computation to  Netconf/Yang ZTP & Day N
>
> > provisioning as well as any SDN Controller ODL or Openflow controller
> type
>
> > functions as well.
>
>
>
> Yes, and this is one of the risks of PCE as a shiny thing: that it be
> converted from a useful toolkit into some form of god-box. I pontificated
> on this way back in 2014 at http://www.olddog.co.uk/PCEPandOnwards.pdf
>
>  Gyan> My sentiments exactly - With that power at your fingertips comes
> responsibility.
>
> How this comes into play and realization of the lines being blurred is
> the use of
>
> > BGP-LS in building the IGP topological graph of the network which was
> designed
>
> > for PCEP and PCE & PCC active & passive off line path computation for
> both
>
> > RSVP-TE or SR-TE path instantiation.
>
>
>
> In some senses, BGP-LS didn’t add anything because a PCE could have
> snooped on the IGP. But BGP-LS provides an export mechanism and importantly
> adds to that some policy filters to determine what is exported thus giving
> the network some control over what is exported.
>
>  Gyan> Agreed
>
> FWIW, https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/
> proposes using PCEP for the same function. The argument in favor is that a
> PCE has to implement PCEP anyway, so why not include the LS export as well.
> The argument against is that BGP-LS has wider applicability and that it
> will typically be exported from an ASBR which already supports BGP.
>
>  Gyan> Makes sense and in some ways cuts out the middle man BGP-LS
> overloading burden on BGP.  Great idea.  I like it.  Another very valuable
> tool in the operators toolbox.
>
> > However now BGP-LS can also be used for other functions now such as
> usage as
>
> > I am a Shepherd reviewing a draft for BGP-LS usage for BIER to use
> BGP-LS to
>
> > gather the elements internals within BIER using the same BGP-LS data
> structures
>
> > to populate with BIER specific information to graph the BIER topology.
> So here
>
> > we are not doing any path computations as we are using in this use case
> for
>
> > NMS type function to gather data for ZTP & Day N provisioning.
>
> >
>
> > Similarly other use cases such as with TEAS TS-Transport slice and being
> able
>
> > to provision TS and capturing the TS Enhanced VPN RT & resource
> information
>
> > and leveraging BGP-LS to do the same data gathering & ZTP like
> controller style
>
> > provisioning.
>
>
>
> Is there a fundamental difference between ZTP & Day N provisioning and
> path computation for traffic engineering provisioning? It’s all determining
> how to configure the network to best carry traffic.
>
>
>
   Gyan> In my mind the fundamental difference would be TE - control plane
TEDs and forwarding plane routing action path computation and instantiation
of path action as compare to a NMS type Netconf/Yang configuration snippet
push function not routing or TE related.

> > It does seem as though BGP-LS as its a means of "data gathering" "dump
> truck"
>
> > of anything with the kitchen sink included to build any type of
> topological graph
>
> > of literally anything under the sun.
>
>
>
> Remembering Yakov Rekhter saying you could use BGP to transport
> Shakespeare.
>
> This is a tension with any protocol BGP-LS, PCEP, etc., etc. Stuff gets
> added, further use gets made.
>
>  Gyan> Understood
>
> BGP-LS was intended to export routing information “northbound” from the
> network.
>
>  Gyan> Understood
>
> > I see that is a nice to leverage but it does in fact blur the lines of
> NMS Netconf/Yang
>
> > Controller based functionality and  PCE path computation functionality
> and SDN
>
> > controller based ZTP functionality into a single ubiquitous server that
> can do all of
>
> > the above and use BGP-LS to accomplish the "kitchen sink" tasks.  It
> does however
>
> > transform BGP to be an NMS tool but a "tool" and not just the original
> function
>
> > which it was intended NLRI network reachability.
>
>
>
> Not sure that BGP-LS is BGP. But I agree that BGP-LS is “an NMS tool”.
>
> I might argue that BGP distributing policies from installation on PEs is
> an NMS protocol.
>
>  Gyan> Agreed.  One way to look at it is that as BGP primary func

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Tony Przygienda]

Yeah, so to give e'one his due, negative disaggregation is Pascal's
brilliant brain-child, I bow to this. And I bow to his patience grinding me
down to convince me the complexity of it is by far outweighted by elegance
it brings to ugly failure repair. Then it took a lot of brow-beating until
e'one on RIFT understood that no, we will not get negative entry silicon
and hence need to remap negative to proper resolution as positive. Not the
simplest things but once you implemented it it turns out simpler than it
looks @ first

my 2c, I'll be watching here from a distance probably until it gelled a bit
more

-- tony

On Fri, Nov 20, 2020 at 12:45 PM Robert Raszuk  wrote:

> Hey Tony,
>
> >  people somehow implying a map of RIFT negative disaggregation in
> relation to this work
>
> I think those people just made a subtle point that considering IGP alone
> if you want to influence your data plane forwarding by advertising PUA in
> today's hardware you really need to install more specific blocks of the
> summary routes which PUA punched the hole in as sent by say one of the
> ABR's. Analogy made to RIFT was just limited to this data plane fragment
> only.
>
> And that comment was not to compare PUA to RIFT negative routing in any
> way. It was just to a) realize what could be required if such a use case
> continues and more importantly b) highlight that if we just use PUA in the
> control plane to for example invalidate BGP next hops or other overlay
> service routes the disaggregation piece does not apply.
>
> Cheers,
> R.
>
>
>
>
>
> On Fri, Nov 20, 2020 at 9:09 PM Tony Przygienda 
> wrote:
>
>>
>>
>> On Fri, Nov 20, 2020 at 6:27 AM Aijun Wang 
>> wrote:
>>
>>> Hi, Tony:
>>>
>>> Aijun Wang
>>> China Telecom
>>>
>>> On Nov 20, 2020, at 17:45, Tony Przygienda  wrote:
>>>
>>> 
>>> Yes, acknowledging the idea of negative disaggregation is inspired by
>>> RIFT work is fine (and normally, when inspired by an idea at least in
>>> research cycles it is considered basic courtesy to refer to the according
>>> source, something has been lost more and more in IETF over time I dare to
>>> observe which in itself reflects on the community IMO) but please do not
>>> try to compare the two beyond that.
>>>
>>> [WAJ] PUA has no relation with RIFT. I have not yet study what’s problem
>>> it encountered, but welcome the experts have such design experience to
>>> point out the pitfall that PUA can bypass.
>>>
>>>
>> aha, ok, I just chimed in because I saw people somehow implying a map of
>> RIFT negative disaggregation in relation to this work but if this is a
>> completely different mechanism than I just watch from the sidelines
>>
>> thanks
>>
>> -- tony
>>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Robert Raszuk]

Hey Tony,

>  people somehow implying a map of RIFT negative disaggregation in
relation to this work

I think those people just made a subtle point that considering IGP alone if
you want to influence your data plane forwarding by advertising PUA in
today's hardware you really need to install more specific blocks of the
summary routes which PUA punched the hole in as sent by say one of the
ABR's. Analogy made to RIFT was just limited to this data plane fragment
only.

And that comment was not to compare PUA to RIFT negative routing in any
way. It was just to a) realize what could be required if such a use case
continues and more importantly b) highlight that if we just use PUA in the
control plane to for example invalidate BGP next hops or other overlay
service routes the disaggregation piece does not apply.

Cheers,
R.





On Fri, Nov 20, 2020 at 9:09 PM Tony Przygienda  wrote:

>
>
> On Fri, Nov 20, 2020 at 6:27 AM Aijun Wang 
> wrote:
>
>> Hi, Tony:
>>
>> Aijun Wang
>> China Telecom
>>
>> On Nov 20, 2020, at 17:45, Tony Przygienda  wrote:
>>
>> 
>> Yes, acknowledging the idea of negative disaggregation is inspired by
>> RIFT work is fine (and normally, when inspired by an idea at least in
>> research cycles it is considered basic courtesy to refer to the according
>> source, something has been lost more and more in IETF over time I dare to
>> observe which in itself reflects on the community IMO) but please do not
>> try to compare the two beyond that.
>>
>> [WAJ] PUA has no relation with RIFT. I have not yet study what’s problem
>> it encountered, but welcome the experts have such design experience to
>> point out the pitfall that PUA can bypass.
>>
>>
> aha, ok, I just chimed in because I saw people somehow implying a map of
> RIFT negative disaggregation in relation to this work but if this is a
> completely different mechanism than I just watch from the sidelines
>
> thanks
>
> -- tony
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Tony Przygienda]

On Fri, Nov 20, 2020 at 6:27 AM Aijun Wang 
wrote:

> Hi, Tony:
>
> Aijun Wang
> China Telecom
>
> On Nov 20, 2020, at 17:45, Tony Przygienda  wrote:
>
> 
> Yes, acknowledging the idea of negative disaggregation is inspired by RIFT
> work is fine (and normally, when inspired by an idea at least in research
> cycles it is considered basic courtesy to refer to the according source,
> something has been lost more and more in IETF over time I dare to observe
> which in itself reflects on the community IMO) but please do not try to
> compare the two beyond that.
>
> [WAJ] PUA has no relation with RIFT. I have not yet study what’s problem
> it encountered, but welcome the experts have such design experience to
> point out the pitfall that PUA can bypass.
>
>
aha, ok, I just chimed in because I saw people somehow implying a map of
RIFT negative disaggregation in relation to this work but if this is a
completely different mechanism than I just watch from the sidelines

thanks

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

Re: [Lsr] Early Allocation for IS-IS TTZ

[Acee Lindem (acee)]

Les,
Thanks for coordinating the experts and getting this done.
Acee

From: "Les Ginsberg (ginsberg)" 
Date: Friday, November 20, 2020 at 1:50 PM
To: "Les Ginsberg (ginsberg)" , Acee 
Lindem , Huaimo Chen , Christian 
Hopps , Hannes Gredler 
Cc: "lsr@ietf.org" , Alvaro Retana 
Subject: RE: Early Allocation for IS-IS TTZ

FYI –

This has been approved by the DEs and IANA has updated the registry.

   Les



From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, November 18, 2020 1:45 PM
To: Acee Lindem (acee) ; Huaimo Chen 
; Christian Hopps ; Hannes 
Gredler 
Cc: lsr@ietf.org; Alvaro Retana 
Subject: Re: [Lsr] Early Allocation for IS-IS TTZ

Request noted.

Chris/Hannes/myself will discuss and get back to you.

   Les

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, November 18, 2020 12:21 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>; Hannes Gredler 
mailto:han...@gredler.at>>; Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>>
Cc: lsr@ietf.org; Alvaro Retana 
mailto:aretana.i...@gmail.com>>
Subject: Re: Early Allocation for IS-IS TTZ

+LSR list and Alvaro for information.

I have no problems with this allocation. This needs to go to IS-IS designated 
experts (Chris, Les, Hannes).

Thanks,
Acee

From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Date: Wednesday, November 18, 2020 at 2:34 PM
To: Acee Lindem mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Subject: Early Allocation for IS-IS TTZ

Hi Acee and Chris,

We would like to request an early allocation of "IS-IS TLV Codepoints" for 
IS-IS TTZ  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/

 28 (suggested) - IS-IS Zone ID TLV

Thank you very much for your consideration.

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

Re: [Lsr] Early Allocation for IS-IS TTZ

[Les Ginsberg (ginsberg)]

FYI –

This has been approved by the DEs and IANA has updated the registry.

   Les



From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, November 18, 2020 1:45 PM
To: Acee Lindem (acee) ; Huaimo Chen 
; Christian Hopps ; Hannes 
Gredler 
Cc: lsr@ietf.org; Alvaro Retana 
Subject: Re: [Lsr] Early Allocation for IS-IS TTZ

Request noted.

Chris/Hannes/myself will discuss and get back to you.

   Les

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, November 18, 2020 12:21 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>; Hannes Gredler 
mailto:han...@gredler.at>>; Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>>
Cc: lsr@ietf.org; Alvaro Retana 
mailto:aretana.i...@gmail.com>>
Subject: Re: Early Allocation for IS-IS TTZ

+LSR list and Alvaro for information.

I have no problems with this allocation. This needs to go to IS-IS designated 
experts (Chris, Les, Hannes).

Thanks,
Acee

From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Date: Wednesday, November 18, 2020 at 2:34 PM
To: Acee Lindem mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Subject: Early Allocation for IS-IS TTZ

Hi Acee and Chris,

We would like to request an early allocation of "IS-IS TLV Codepoints" for 
IS-IS TTZ  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/

 28 (suggested) - IS-IS Zone ID TLV

Thank you very much for your consideration.

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

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Aijun Wang]

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 20, 2020, at 16:10, Robert Raszuk  wrote:
> 
> 
> Gyan,
> 
> I like and support your use case #1 
> 
> For use case #2 I have doubts. Imagine indeed an area which get's partitioned 
> such that ABR will loose connectivity to bunch of nodes. Does this mean that 
> now such ABR will be blasting globally perhaps 1000s of PUAs ? How would the 
> ABR be able to send PUA summary provided some disconnected POPs within area 
> could be nicely summarized ?
[WAJ] If ABR can do PUA summary, it is certainly better.  Or else, send the 
“PUA+Summary” for failure prefixes or send the “detailed reachable 
information-summary“ for connected prefixes, depend which one is less. Do you 
have other proposals?

> Isn't it better to design your area such that ABRs are interconnected with 
> redundancy ? 

[WAJ] Such requirement is certainly reasonable, but it still can’t avoid the 
extreme situation. 

> 
> Thx,
> R.
> 
> 
> 
>> On Fri, Nov 20, 2020 at 3:28 AM Gyan Mishra  wrote:
>> 
>> Aijun 
>> 
>> I am thinking per the feedback received let’s keep it really simple.  We 
>> need a solid use case to move the ball forward were the PUA data plane 
>> convergence capabilities can fills a gap that exists today. 
>> 
>> I have two simple solutions to start that I will update the presentation 
>> with to start and present to the WG and we can go from there.
>> 
>> 1.  BGP NH tracking via PUA of NH component prefix to converge the data plane
>> 
>> 2.  Area partitioned scenario where PUA is used for data plane convergence 
>> to ABR that has reachability to component prefixes.  
>> 
>> I will send out tomorrow.
>> 
>> Thanks 
>> 
>> Gyan
>> 
>>> On Wed, Nov 18, 2020 at 9:37 PM Aijun Wang  
>>> wrote:
>>> Hi, Acee:
>>> 
>>>  
>>> 
>>> OK, we will try to improve this document to meet this criteria.
>>> 
>>> And, as this topic has been discussed intensely on the mail list, we are 
>>> also eager to invite more interested experts to join us as co-authors to 
>>> refine the solutions for more scenarios.
>>> 
>>>  
>>> 
>>> Thanks in advance.
>>> 
>>>  
>>> 
>>> Best Regards
>>> 
>>>  
>>> 
>>> Aijun Wang
>>> 
>>> China Telecom
>>> 
>>>  
>>> 
>>>  
>>> 
>>> From: Acee Lindem (acee)  
>>> Sent: Thursday, November 19, 2020 12:42 AM
>>> To: Aijun Wang ; 'Robert Raszuk' 
>>> ; 'Jeff Tantsura' 
>>> Cc: 'Gyan Mishra' ; 'lsr' ; 'Acee 
>>> Lindem (acee)' 
>>> Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases
>>> 
>>>  
>>> 
>>> Speaking as WG Co-Chair:
>>> 
>>>  
>>> 
>>> From: Aijun Wang 
>>> Date: Wednesday, November 18, 2020 at 3:05 AM
>>> To: Robert Raszuk , Jeff Tantsura 
>>> 
>>> Cc: 'Gyan Mishra' , Acee Lindem , 
>>> 'lsr' , "'Acee Lindem (acee)'" 
>>> 
>>> Subject: RE: [Lsr] Prefix Unreachable Announcement Use Cases
>>> 
>>>  
>>> 
>>> Hi, Robert:
>>> 
>>>  
>>> 
>>> The trigger and propagation of PUA info can be standardized, the actions 
>>> based on the PUA can be different in different situation.
>>> 
>>> We can discuss and describe the actions based on different scenarios after 
>>> its WG adoption?
>>> 
>>>  
>>> 
>>> There will be no adoption call until there is a coherent draft with use 
>>> case(s) and viable actions.
>>> 
>>>  
>>> 
>>> Thanks,
>>> 
>>> Acee
>>> 
>>>  
>>> 
>>>  
>>> 
>>> Best Regards
>>> 
>>>  
>>> 
>>> Aijun Wang
>>> 
>>> China Telecom
>>> 
>>>  
>>> 
>>> From: Robert Raszuk  
>>> Sent: Wednesday, November 18, 2020 3:49 PM
>>> To: Jeff Tantsura 
>>> Cc: Gyan Mishra ; Acee Lindem (acee) 
>>> ; lsr ; Aijun Wang 
>>> ; Acee Lindem (acee) 
>>> 
>>> Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases
>>> 
>>>  
>>> 
>>> Jeff,
>>> 
>>>  
>>> 
>>> Please notice that WAN is not an IX. 
>>> 
>>>  
>>> 
>>> While you can have full mesh of BFD sessions among all IXP participants 
>>> each bombarding each over over TB fabric every 100 ms or so to map the same 
>>> over global WAN is a different game. If nothing else RTT between IXP 
>>> participants in healthy IX is around 1 ms while RTT between PEs distributed 
>>> globally is often 100-200 ms. 
>>> 
>>>  
>>> 
>>> Just imagine 1000 PEs in 10 areas distributed all over the world. That 
>>> means that in worst case scenario (say same mgmt VPN present on each PE) 
>>> you will establish 1000*999 BFD sessions. Now for this to make sense timer 
>>> needs to be 100 ms or so with 3x or 5x multiplier. Anything slower will 
>>> defeat the purpose as BGP withdraw will be faster. 
>>> 
>>>  
>>> 
>>> Then we go into queuing issues. If BFD packets are queued at any interface 
>>> meltdowns may occur which can be far worse in consequences then waiting for 
>>> BGP service route removal. Such meltdowns often result in cascading effects 
>>> to the applications itself. 
>>> 
>>>  
>>> 
>>> So this is not at all about autodiscovery with which address to setup the 
>>> BFD session. It is much more about operational aspects of going that 
>>> direction. 
>>> 
>>>  
>>> 
>>> With that I am supportive of this work even if 

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Aijun Wang]

Hi, Tony:

Aijun Wang
China Telecom

> On Nov 20, 2020, at 17:45, Tony Przygienda  wrote:
> 
> 
> Yes, acknowledging the idea of negative disaggregation is inspired by RIFT 
> work is fine (and normally, when inspired by an idea at least in research 
> cycles it is considered basic courtesy to refer to the according source, 
> something has been lost more and more in IETF over time I dare to observe 
> which in itself reflects on the community IMO) but please do not try to 
> compare the two beyond that.
[WAJ] PUA has no relation with RIFT. I have not yet study what’s problem it 
encountered, but welcome the experts have such design experience to point out 
the pitfall that PUA can bypass.

> Disaggregation works well on directed graphs (lattices) or arguably if your 
> addressing scheme is aligned with regular topology (hypercube e.g.). it works 
> in generic graphs in super special cases only & it will be @ best a crutch 
> that may under all the correct circumstances have some utility but probably 
> ends up hurting operationally more than helping.
[WAJ] PUA will try to avoid the solution that can only fit some special 
topology or address schema.

> The indication that "magic timer" is needed in the draft should be first 
> warning, all kind of seat-of-pants heuristics to dis- and re-aggregate 2nd. 

[WAJ] “timer” is not uncommon in IGP protocol. Using it within PUA mechanism is 
just to assure the service switch successfully upon it receives the PUA.

> Just quickly flying through the draft I see lots of logic problems already 
> that will lead to vexing effects, e.g. indication of missing neighbor will 
> work in specific type of topologies, in others varying by one link only may 
> lead to stable blackholes. 
[WAJ] Would you like to state the above conclusion more clearly?

> 
> my 2c
> 
> -- tony 
> 
>> On Sun, Nov 15, 2020 at 11:29 AM Jeff Tantsura  
>> wrote:
>> As RIFT chair - I’d like to respond to Robert’ comment -  the example is 
>> rather  unfortunate, in RIFT disaggregation is conditional and well 
>> contained within its context, it doesn’t  affect overall scalability.
>> 
>> Regards,
>> Jeff
>> 
 On Nov 15, 2020, at 08:44, Robert Raszuk  wrote:
 
>>> 
>>> Hi Aijun,
>>> 
>>> I would in fact only propose that the presented mechanism is narrowed down 
>>> to invalidate BGP (service) routes - in fact their next hops. 
>>> 
>>> The reason being that the moment you make the solution generic, moreover 
>>> the moment you want it to be used in RIB and data plane I am afraid you are 
>>> running into similar (even if local) deaggregation mechanism like recently 
>>> described in RIFT. That would kill all the scalability of advertising 
>>> summary routes in the first place and I bet would face lots of opposition. 
>>> 
>>> Thx,
>>> R.
>>>  
> I would actually trim most use cases leaving just one - to signal remote 
> service node (ex: PE) going down in the presence of summary route being 
> advertised from remote area or pop. 
>>>  [WAJ] Yes, this may be the most useful use case, but the PUA mechanism can 
>>> also apply to other scenarios. We want to make it one general solution.
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Tony Przygienda]

Yes, acknowledging the idea of negative disaggregation is inspired by RIFT
work is fine (and normally, when inspired by an idea at least in research
cycles it is considered basic courtesy to refer to the according source,
something has been lost more and more in IETF over time I dare to observe
which in itself reflects on the community IMO) but please do not try to
compare the two beyond that. Disaggregation works well on directed graphs
(lattices) or arguably if your addressing scheme is aligned with regular
topology (hypercube e.g.). it works in generic graphs in super special
cases only & it will be @ best a crutch that may under all the correct
circumstances have some utility but probably ends up hurting operationally
more than helping. The indication that "magic timer" is needed in the draft
should be first warning, all kind of seat-of-pants heuristics to dis- and
re-aggregate 2nd.  Just quickly flying through the draft I see lots of
logic problems already that will lead to vexing effects, e.g. indication of
missing neighbor will work in specific type of topologies, in others
varying by one link only may lead to stable blackholes.

my 2c

-- tony

On Sun, Nov 15, 2020 at 11:29 AM Jeff Tantsura 
wrote:

> As RIFT chair - I’d like to respond to Robert’ comment -  the example is
> rather  unfortunate, in RIFT disaggregation is conditional and well
> contained within its context, it doesn’t  affect overall scalability.
>
> Regards,
> Jeff
>
> On Nov 15, 2020, at 08:44, Robert Raszuk  wrote:
>
> 
> Hi Aijun,
>
> I would in fact only propose that the presented mechanism is narrowed down
> to invalidate BGP (service) routes - in fact their next hops.
>
> The reason being that the moment you make the solution generic, moreover
> the moment you want it to be used in RIB and data plane I am afraid you are
> running into similar (even if local) deaggregation mechanism like recently
> described in RIFT. That would kill all the scalability of advertising
> summary routes in the first place and I bet would face lots of opposition.
>
> Thx,
> R.
>
>
>> I would actually trim most use cases leaving just one - to signal remote
>> service node (ex: PE) going down in the presence of summary route being
>> advertised from remote area or pop.
>>
>>  [WAJ] Yes, this may be the most useful use case, but the PUA mechanism
> can also apply to other scenarios. We want to make it one general solution.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Gyan Mishra]

Robert

Let me send it over graphical depiction as a picture is worth a thousand
words should be easy to see the concept.

Trying to keep as simple as possible.

Thanks

Gyan

On Fri, Nov 20, 2020 at 3:03 AM Robert Raszuk  wrote:

> Gyan,
>
> I like and support your use case #1
>
> For use case #2 I have doubts. Imagine indeed an area which get's
> partitioned such that ABR will loose connectivity to bunch of nodes. Does
> this mean that now such ABR will be blasting globally perhaps 1000s of PUAs
> ? How would the ABR be able to send PUA summary provided some disconnected
> POPs within area could be nicely summarized ? Isn't it better to design
> your area such that ABRs are interconnected with redundancy ?
>
> Thx,
> R.
>
>
>
> On Fri, Nov 20, 2020 at 3:28 AM Gyan Mishra  wrote:
>
>>
>> Aijun
>>
>> I am thinking per the feedback received let’s keep it really simple.  We
>> need a solid use case to move the ball forward were the PUA data plane
>> convergence capabilities can fills a gap that exists today.
>>
>> I have two simple solutions to start that I will update the presentation
>> with to start and present to the WG and we can go from there.
>>
>> 1.  BGP NH tracking via PUA of NH component prefix to converge the data
>> plane
>>
>> 2.  Area partitioned scenario where PUA is used for data plane
>> convergence to ABR that has reachability to component prefixes.
>>
>> I will send out tomorrow.
>>
>> Thanks
>>
>> Gyan
>>
>> On Wed, Nov 18, 2020 at 9:37 PM Aijun Wang 
>> wrote:
>>
>>> Hi, Acee:
>>>
>>>
>>>
>>> OK, we will try to improve this document to meet this criteria.
>>>
>>> And, as this topic has been discussed intensely on the mail list, we are
>>> also eager to invite more interested experts to join us as co-authors to
>>> refine the solutions for more scenarios.
>>>
>>>
>>>
>>> Thanks in advance.
>>>
>>>
>>>
>>> Best Regards
>>>
>>>
>>>
>>> Aijun Wang
>>>
>>> China Telecom
>>>
>>>
>>>
>>>
>>>
>>> *From:* Acee Lindem (acee) 
>>> *Sent:* Thursday, November 19, 2020 12:42 AM
>>> *To:* Aijun Wang ; 'Robert Raszuk' <
>>> rob...@raszuk.net>; 'Jeff Tantsura' 
>>> *Cc:* 'Gyan Mishra' ; 'lsr' ;
>>> 'Acee Lindem (acee)' 
>>> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases
>>>
>>>
>>>
>>> Speaking as WG Co-Chair:
>>>
>>>
>>>
>>> *From: *Aijun Wang 
>>> *Date: *Wednesday, November 18, 2020 at 3:05 AM
>>> *To: *Robert Raszuk , Jeff Tantsura <
>>> jefftant.i...@gmail.com>
>>> *Cc: *'Gyan Mishra' , Acee Lindem ,
>>> 'lsr' , "'Acee Lindem (acee)'" <
>>> acee=40cisco@dmarc.ietf.org>
>>> *Subject: *RE: [Lsr] Prefix Unreachable Announcement Use Cases
>>>
>>>
>>>
>>> Hi, Robert:
>>>
>>>
>>>
>>> The trigger and propagation of PUA info can be standardized, the actions
>>> based on the PUA can be different in different situation.
>>>
>>> We can discuss and describe the actions based on different scenarios
>>> after its WG adoption?
>>>
>>>
>>>
>>> There will be no adoption call until there is a coherent draft with use
>>> case(s) and viable actions.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Acee
>>>
>>>
>>>
>>>
>>>
>>> Best Regards
>>>
>>>
>>>
>>> Aijun Wang
>>>
>>> China Telecom
>>>
>>>
>>>
>>> *From:* Robert Raszuk 
>>> *Sent:* Wednesday, November 18, 2020 3:49 PM
>>> *To:* Jeff Tantsura 
>>> *Cc:* Gyan Mishra ; Acee Lindem (acee) <
>>> a...@cisco.com>; lsr ; Aijun Wang <
>>> wangai...@tsinghua.org.cn>; Acee Lindem (acee) <
>>> acee=40cisco@dmarc.ietf.org>
>>> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases
>>>
>>>
>>>
>>> Jeff,
>>>
>>>
>>>
>>> Please notice that WAN is not an IX.
>>>
>>>
>>>
>>> While you can have full mesh of BFD sessions among all IXP participants
>>> each bombarding each over over TB fabric every 100 ms or so to map the same
>>> over global WAN is a different game. If nothing else RTT between IXP
>>> participants in healthy IX is around 1 ms while RTT between PEs distributed
>>> globally is often 100-200 ms.
>>>
>>>
>>>
>>> Just imagine 1000 PEs in 10 areas distributed all over the world. That
>>> means that in worst case scenario (say same mgmt VPN present on each PE)
>>> you will establish 1000*999 BFD sessions. Now for this to make sense timer
>>> needs to be 100 ms or so with 3x or 5x multiplier. Anything slower will
>>> defeat the purpose as BGP withdraw will be faster.
>>>
>>>
>>>
>>> Then we go into queuing issues. If BFD packets are queued at any
>>> interface meltdowns may occur which can be far worse in consequences then
>>> waiting for BGP service route removal. Such meltdowns often result in
>>> cascading effects to the applications itself.
>>>
>>>
>>>
>>> So this is not at all about autodiscovery with which address to
>>> setup the BFD session. It is much more about operational aspects of going
>>> that direction.
>>>
>>>
>>>
>>> With that I am supportive of this work even if we label it as
>>> experimental for some time. As each network is different what is optimal
>>> solution for one design and deployment may not be optimal for the other.
>>>
>>>
>>>

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Robert Raszuk]

Gyan,

I like and support your use case #1

For use case #2 I have doubts. Imagine indeed an area which get's
partitioned such that ABR will loose connectivity to bunch of nodes. Does
this mean that now such ABR will be blasting globally perhaps 1000s of PUAs
? How would the ABR be able to send PUA summary provided some disconnected
POPs within area could be nicely summarized ? Isn't it better to design
your area such that ABRs are interconnected with redundancy ?

Thx,
R.



On Fri, Nov 20, 2020 at 3:28 AM Gyan Mishra  wrote:

>
> Aijun
>
> I am thinking per the feedback received let’s keep it really simple.  We
> need a solid use case to move the ball forward were the PUA data plane
> convergence capabilities can fills a gap that exists today.
>
> I have two simple solutions to start that I will update the presentation
> with to start and present to the WG and we can go from there.
>
> 1.  BGP NH tracking via PUA of NH component prefix to converge the data
> plane
>
> 2.  Area partitioned scenario where PUA is used for data plane convergence
> to ABR that has reachability to component prefixes.
>
> I will send out tomorrow.
>
> Thanks
>
> Gyan
>
> On Wed, Nov 18, 2020 at 9:37 PM Aijun Wang 
> wrote:
>
>> Hi, Acee:
>>
>>
>>
>> OK, we will try to improve this document to meet this criteria.
>>
>> And, as this topic has been discussed intensely on the mail list, we are
>> also eager to invite more interested experts to join us as co-authors to
>> refine the solutions for more scenarios.
>>
>>
>>
>> Thanks in advance.
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>>
>>
>> *From:* Acee Lindem (acee) 
>> *Sent:* Thursday, November 19, 2020 12:42 AM
>> *To:* Aijun Wang ; 'Robert Raszuk' <
>> rob...@raszuk.net>; 'Jeff Tantsura' 
>> *Cc:* 'Gyan Mishra' ; 'lsr' ; 'Acee
>> Lindem (acee)' 
>> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases
>>
>>
>>
>> Speaking as WG Co-Chair:
>>
>>
>>
>> *From: *Aijun Wang 
>> *Date: *Wednesday, November 18, 2020 at 3:05 AM
>> *To: *Robert Raszuk , Jeff Tantsura <
>> jefftant.i...@gmail.com>
>> *Cc: *'Gyan Mishra' , Acee Lindem ,
>> 'lsr' , "'Acee Lindem (acee)'" <
>> acee=40cisco@dmarc.ietf.org>
>> *Subject: *RE: [Lsr] Prefix Unreachable Announcement Use Cases
>>
>>
>>
>> Hi, Robert:
>>
>>
>>
>> The trigger and propagation of PUA info can be standardized, the actions
>> based on the PUA can be different in different situation.
>>
>> We can discuss and describe the actions based on different scenarios
>> after its WG adoption?
>>
>>
>>
>> There will be no adoption call until there is a coherent draft with use
>> case(s) and viable actions.
>>
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* Robert Raszuk 
>> *Sent:* Wednesday, November 18, 2020 3:49 PM
>> *To:* Jeff Tantsura 
>> *Cc:* Gyan Mishra ; Acee Lindem (acee) <
>> a...@cisco.com>; lsr ; Aijun Wang <
>> wangai...@tsinghua.org.cn>; Acee Lindem (acee) <
>> acee=40cisco@dmarc.ietf.org>
>> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases
>>
>>
>>
>> Jeff,
>>
>>
>>
>> Please notice that WAN is not an IX.
>>
>>
>>
>> While you can have full mesh of BFD sessions among all IXP participants
>> each bombarding each over over TB fabric every 100 ms or so to map the same
>> over global WAN is a different game. If nothing else RTT between IXP
>> participants in healthy IX is around 1 ms while RTT between PEs distributed
>> globally is often 100-200 ms.
>>
>>
>>
>> Just imagine 1000 PEs in 10 areas distributed all over the world. That
>> means that in worst case scenario (say same mgmt VPN present on each PE)
>> you will establish 1000*999 BFD sessions. Now for this to make sense timer
>> needs to be 100 ms or so with 3x or 5x multiplier. Anything slower will
>> defeat the purpose as BGP withdraw will be faster.
>>
>>
>>
>> Then we go into queuing issues. If BFD packets are queued at any
>> interface meltdowns may occur which can be far worse in consequences then
>> waiting for BGP service route removal. Such meltdowns often result in
>> cascading effects to the applications itself.
>>
>>
>>
>> So this is not at all about autodiscovery with which address to setup the
>> BFD session. It is much more about operational aspects of going that
>> direction.
>>
>>
>>
>> With that I am supportive of this work even if we label it as
>> experimental for some time. As each network is different what is optimal
>> solution for one design and deployment may not be optimal for the other.
>>
>>
>>
>> Many thx,
>>
>> Robert
>>
>>
>>
>>
>>
>> On Wed, Nov 18, 2020 at 4:34 AM Jeff Tantsura 
>> wrote:
>>
>> We have been discussing for quite some time and in different wg's (there’s
>> IX with RS use case) BFD verification based on next-hop extraction, Robert
>> - you should know. (also built a well working prototype in previous life).
>>
>> Very simple logic:
>>
>> Upon route import (BGP update received and imported), extr