Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[Lizhenbin]

Hi Robert,
The draft tries to propose a lightweight isolated flooding solution capering 
the existing IGP multi-instance solutions. As the suggestion proposed by Acee, 
it should take more work. Now it focuses on ISIS firstly. Then OSPF may be 
taken into account depending on the research result of ISIS.

Best Regards,
Robin




From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, March 11, 2021 6:40 AM
To: Aijun Wang ; wangyali ; 
Tianran Zhou 
Cc: Les Ginsberg (ginsberg) ; Tony Li ; 
Gyan Mishra ; lsr 
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Dear Authors,

Looking at the bigger picture here I have two simple questions.

Q1: Do you plan to submit draft-x-lsr-ospf-mfi-00.txt any time soon ?

Q2: If No - why not ?
   If Yes - how would you choose to use either  
draft-x-lsr-ospf-mfi-00.txt or 
https://tools.ietf.org/html/draft-ietf-ospf-transport-instance-11 for your non
   routing application (opaque to routing) information flooding ?

Extra bonus question - It seems that the very same application (ifit) is 
proposed to be distributed using BGP too 
(https://tools.ietf.org/html/draft-wang-idr-bgp-ifit-capabilities-01). Can you 
provide pros and cons comparison of using link state flooding vs p2mp BGP model 
to distribute this type of data ?

Hint: Please do not respond .. Oh this is yet another way ... That is not a 
valid answer.

Many thx,
Robert.

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

Re: [Lsr] Why not leverage Network conditions to optimize balancing among multiple App Layer Load Balancers? as proposed by draft-dunbar-lsr-5g-edge-compute-ospf-ext

[Gyan Mishra]

Hi Linda

Comments in-line

On Wed, Mar 10, 2021 at 6:46 PM Linda Dunbar 
wrote:

> Gyan,
>
>
>
> To a router, having multiple servers with the same (ANYCAST) address
> attached to different egress routers (A-ER) is same as having multiple
> paths to reach the (ANYCAST) address.
>
>
>
> You are absolutely correct that there are many tools to influence the path
> section, such as the routing distance, TE metrics, policies, etc.
>
>
>
> draft-dunbar-lsr-5g-edge-compute-ospf-ext proposes to add another
> component to influence the path selection: the “Site-Cost”  which is
> influenced by  “site-capacity + load measurement + Preference + xxx”. The
> “site-Cost” can be raw measurements collected by the egress routers based
> on the instruction from a controller, or informed by the App Controller
> periodically.
>
>
>
> In the past, ANYCAST has been predominantly used for multiple servers in
> geographically far apart locations so that routing distance alone can
> always nail down to one specific ANYCAST server.
>
>  Gyan>  The Anycast environments that I have worked with architecture have
> been server clusters in data centers geographically diverse that sit behind
> a load balancer that uses a concept called HRI host route injection that if
> the service is up the VIP is BGP advertised for the cluster to DC core and
> then services VIP host route are advertised into the core all BGP
> attributes equal so lowest IGP metric tie breaker picks best path shortest
> path across the core  as best path and of iBGP multipath is used that
> services VIPs are geographically load balanced flow based if metric is a
> tie and if IPv6 is used in the core then 5-tuple per flow load balanced
> optimized.
>


3GPP TR23.748 (5G Edge Computing) is proposing to use multiple servers (or
> multiple App Layer Load Balancers) with the same ANYCAST address in their
> Local IP Data Network to avoid the single point of failure and the
> bottleneck at the App Layer Load Balancer for mission critical
> applications.
>
>  Gyan>  With Anycast routing as I mentioned you don’t have a single point
> of failure and really have optimal redundancy which is why for any services
> such as DNS, NTP and many others Anycast is the best most redundancy and
> optimal as proximity routing is used. If your closest lowest IGP metric
> iBGP load balanced path goes down let’s say multiple DC outages you still
> have your next closest in the BGP path list pecking order to reach the
> service thus optimized redundancy as every DC would have to be down for
> service VIP to be down.  Also with Anycast as it a distributed architecture
> you are not overloading core paths or certain DC VIPs as all traffic is
> distributed geographically proximity load balanced automatically.  So there
> is a lesser chance of bottleneck as the Anycast architecture is distributed.
>

   As far as 5G you still have main components of the path from UE  user
data plane to RAN xHaul VPN within the wireless operator network then
handoff to the core to a service VIP in a closet proximity data center. So
now we are trying to further optimize the cost based on real time PM
performance metrics to calculate the best path with this draft.

This draft below is in LSR maybe interesting to you related to flex algo
bandwidth related constraints so that the TE static ERO concept of exclude
L2 links in a bundle can be accomplished based on link delay bandwidth
thresholds that use semi dynamic metrics based on PM measurements.

In that discussion thread was brought up use of the PM based metrics and if
that would cause instability.  That maybe something to consider when using
dynamic PM based metrics.

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

Kind Regards


Gyan

Thank you very much for your comments. I have made some changes to the
> text. Please see the revision:
> https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/
>
>
>
>
>
> Linda
>
>
>
> *From:* Gyan Mishra 
> *Sent:* Tuesday, March 9, 2021 12:08 AM
> *To:* Liyizhou 
> *Cc:* Christian Hopps ; Linda Dunbar <
> linda.dun...@futurewei.com>; lsr@ietf.org
> *Subject:* Re: [Lsr] Why not leverage Network conditions to optimize
> balancing among multiple App Layer Load Balancers? as proposed by
> draft-dunbar-lsr-5g-edge-compute-ospf-ext
>
>
>
> Linda and authors
>
>
>
> Some thoughts regarding load balancing draft.
>
>
>
> Anycast in my experience has been used predominantly in my experience
> within operators networks with BGP overlay,  using BGP best path selection
> and most cases boils down to lowest IGP metric tie breaker shortest path
> for the service Anycast proximity route which you can also with unique RD
> in overlay and can take advantage of iBGP multipath equal cost load
> balancing over an operator vaccine or 4G/5G RAN xhaul or internet.
>
>
>
> The nice thing about Anycast with BGP overlay you as are automatically
> proximity based routing load balancing inherent to Anycast 

Re: [Lsr] Why not leverage Network conditions to optimize balancing among multiple App Layer Load Balancers? as proposed by draft-dunbar-lsr-5g-edge-compute-ospf-ext

[Linda Dunbar]

Gyan,

To a router, having multiple servers with the same (ANYCAST) address attached 
to different egress routers (A-ER) is same as having multiple paths to reach 
the (ANYCAST) address.

You are absolutely correct that there are many tools to influence the path 
section, such as the routing distance, TE metrics, policies, etc.

draft-dunbar-lsr-5g-edge-compute-ospf-ext proposes to add another component to 
influence the path selection: the "Site-Cost"  which is influenced by  
"site-capacity + load measurement + Preference + xxx". The "site-Cost" can be 
raw measurements collected by the egress routers based on the instruction from 
a controller, or informed by the App Controller periodically.

In the past, ANYCAST has been predominantly used for multiple servers in 
geographically far apart locations so that routing distance alone can always 
nail down to one specific ANYCAST server.

3GPP TR23.748 (5G Edge Computing) is proposing to use multiple servers (or 
multiple App Layer Load Balancers) with the same ANYCAST address in their Local 
IP Data Network to avoid the single point of failure and the bottleneck at the 
App Layer Load Balancer for mission critical applications.

Thank you very much for your comments. I have made some changes to the text. 
Please see the revision: 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/


Linda

From: Gyan Mishra 
Sent: Tuesday, March 9, 2021 12:08 AM
To: Liyizhou 
Cc: Christian Hopps ; Linda Dunbar 
; lsr@ietf.org
Subject: Re: [Lsr] Why not leverage Network conditions to optimize balancing 
among multiple App Layer Load Balancers? as proposed by 
draft-dunbar-lsr-5g-edge-compute-ospf-ext

Linda and authors

Some thoughts regarding load balancing draft.

Anycast in my experience has been used predominantly in my experience within 
operators networks with BGP overlay,  using BGP best path selection and most 
cases boils down to lowest IGP metric tie breaker shortest path for the service 
Anycast proximity route which you can also with unique RD in overlay and can 
take advantage of iBGP multipath equal cost load balancing over an operator 
vaccine or 4G/5G RAN xhaul or internet.

The nice thing about Anycast with BGP overlay you as are automatically 
proximity based routing load balancing inherent to Anycast routing.

Point here is we are using BGP best path selection but it does boils down to 
IGP lowest metric tie breaker but you can use iBGP multipath to further 
optimize the routing for cloud computing.

We have so many tools in our operators toolbox to optimize routing SR or 
Flex-Algo, SDN etc am wondering if some form of SDN or SD-WAN overlay could 
provide the Dyncast type Dynamic Anycast solution.

I want to the wiki page for Dyncast.  The presentation is not available yet.  
Will check tomorrow.

Thanks

Gyan


On Mon, Mar 8, 2021 at 11:36 PM Liyizhou 
mailto:liyiz...@huawei.com>> wrote:
Hi,

Sorry to chime in.

There are certainly some higher layer application/protocols to employ. At the 
same time, there are some advantages of network layer approaches as well in my 
mind.

When talking about edge computing, there are some unique characteristics. The 
number of edge sites could be large or huge in future in a big city. Edges are 
geographically scattered which could be a few, or tens of, or a hundred 
kilometers away from each other, and each site has limited computing resources 
which could be a small cluster. Application layer based approach normally would 
rely on one or several "server"/"broker" to be responsible for request handling 
all over the city. As such "servers" are unlikely available on each and every 
edge site, it introduces additional path stretch for data packets requiring 
delivery to other edge sites first. Such path stretch introduces additional 
(network and processing) delay which could be crucial for short live request 
flow. On the contrary, the network node at the edge is naturally sitting on the 
data path without introducing any additional cost to direct the 
(explicit/implicit) request somewhere else. Also routing system has been proven 
doing good in such distributed manner.


There is a dyncast (dynamic anycast) work ongoing. It is not exactly same as 
what Linda proposed here, but some relations can be seen, like trying to use 
anycast methodology to access an edge computing, especially computational 
intensive, service. The current discussions are about compellingness of the use 
cases, the deficiency of existing solutions, and proposed architecture, not 
gone very far into what specific routing protocols to use yet. A side meeting 
will be held on Wed 10am CET. You may check 

Re: [Lsr] Comments on draft-dunbar-lsr-5g-edge-compute-ospf-ext-03

[Linda Dunbar]

Acee,

Thank you very much for your comments.
Answers are inserted below.

Linda
From: Acee Lindem (acee) 
Sent: Monday, March 8, 2021 2:12 PM
To: draft-dunbar-lsr-5g-edge-compute-ospf-...@ietf.org
Cc: lsr@ietf.org
Subject: Comments on draft-dunbar-lsr-5g-edge-compute-ospf-ext-03

Speaking as WG member:

Hi Linda and Co-authors,

My first major comment is the confusion with the usage of multiple anycast 
addresses for the same application. Why are you requiring multiple anycast 
address? It would seem the load balancing over multiple servers can be done at 
the data center layer. I guess a UE would use the same anycast address for an 
application based on the initial DNS query? It is very confusing.

[Linda] Yeh, agree with you. It is kind of confusing.  That was one of the 
proposed solutions  in  3GPP’s TR23.748.
With OSPF periodically advertising the reachability to the ANYCAST servers, all 
routers should automatically switch to an alternative location for the ANYCAST 
server.
 I will remove the Section 6 in the next revision.

My second major comment is that in section 4, you point out that an aggregated 
metric would solve the problem. However, the purported downside is that all the 
Application Egress Routers (A-ERs) would need to use the same algorithm to 
aggregate the various capacity measurements into a single metric. It would seem 
to be an even larger obstacle for all the OSPF routers in the area to support 
these new metrics and consistent routing based on those metrics.

[Linda] Agree with you. The solution is only useful for a small controlled 
network, for example,  the Application Function Controller could send the 
“aggregated cost” to the egress routers periodically.
Even though the solution description described in the Section 4 has very 
limited usage, I feel it is important to include it in the draft.
I change the text to the following

“If all egress routers that have direct connection to the App Servers can get 
periodic update of the aggregated cost to the App Servers or can be configured 
with a consistent algorithm to compute an aggregated cost that take into 
consideration the Load Measurement, Capacity value and Preference value, this 
aggregated cost can be considered as the Metric of the link to the App Server.
In this scenario, there is no protocol extension needed.”

Also, some minor comments:


  1.  Why do you talk about ACLs to determine the anycast addresses? 
Presumably, you wouldn’t even have these metrics available for other addresses.
[Linda]  There could be large number of addresses attached to each Egress 
router. The egress routers only need to measure the “Running Environment” for 
the addresses filtered by the ACLs.


  1.  Section 5 still references the misguided 
draft-wang-lsr-passive-interface-attribute draft. I believe you meant to remove 
this.
[Linda] AiJun has answered this question.

There are other nits as well but it doesn’t make sense to spend time on them at 
this stage.

Thanks,
Acee


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

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

[Les Ginsberg (ginsberg)]

Folks -

This revision addresses comments from Dhruv, Alvaro, Donald, and Acee.
Thanx to all for their careful review.

   Les


> -Original Message-
> From: Lsr  On Behalf Of internet-dra...@ietf.org
> Sent: Wednesday, March 10, 2021 7:57 AM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-lsr-isis-rfc5316bis-02.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Link State Routing WG of the IETF.
> 
> Title   : IS-IS Extensions in Support of Inter-Autonomous 
> System (AS)
> MPLS and GMPLS Traffic Engineering
> Authors : Mach(Guoyi) Chen
>   Les Ginsberg
>   Stefano Previdi
>   Xiaodong Duan
>   Filename: draft-ietf-lsr-isis-rfc5316bis-02.txt
>   Pages   : 21
>   Date: 2021-03-10
> 
> Abstract:
>This document describes extensions to the Intermediate System to
>Intermediate System (IS-IS) protocol to support Multiprotocol Label
>Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
>(TE) for multiple Autonomous Systems (ASs).  It defines IS-IS
>extensions for the flooding of TE information about inter-AS links,
>which can be used to perform inter-AS TE path computation.
> 
>No support for flooding information from within one AS to another AS
>is proposed or defined in this document.
> 
>This document obsoletes RFC 5316.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc5316bis-02
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-rfc5316bis-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-rfc5316bis-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> 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] I-D Action: draft-ietf-lsr-isis-rfc5316bis-02.txt

[internet-drafts]

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

Title   : IS-IS Extensions in Support of Inter-Autonomous 
System (AS) MPLS and GMPLS Traffic Engineering
Authors : Mach(Guoyi) Chen
  Les Ginsberg
  Stefano Previdi
  Xiaodong Duan
Filename: draft-ietf-lsr-isis-rfc5316bis-02.txt
Pages   : 21
Date: 2021-03-10

Abstract:
   This document describes extensions to the Intermediate System to
   Intermediate System (IS-IS) protocol to support Multiprotocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
   (TE) for multiple Autonomous Systems (ASs).  It defines IS-IS
   extensions for the flooding of TE information about inter-AS links,
   which can be used to perform inter-AS TE path computation.

   No support for flooding information from within one AS to another AS
   is proposed or defined in this document.

   This document obsoletes RFC 5316.



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

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

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


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

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


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

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Tony Przygienda]

same thing. if you want go multiple hops ZeroMQ you need forwarding
already. And if you go one hop it really doesn't matter, it's just FOSE
(flooding over something else ;-)

-- tony

On Wed, Mar 10, 2021 at 12:52 PM Robert Raszuk  wrote:

> >  You think Kafka here?
>
> Nope ... I meant ZeroMQ message bus as underlaying pub-sub transport for
> service related info.
>
> Thx,
> R.,
>
>
> On Wed, Mar 10, 2021 at 11:41 AM Tony Przygienda 
> wrote:
>
>> ? Last time I looked @ it (and it's been a while) Open-R had nothing of
>> that sort, it was basically KV playing LSDB (innovative and clever in
>> itself). You think Kafka here? Which in turn needs underlying IGP however
>> and is nothing but BGP problems in new clothes having looked @ their
>> internal architecture and where it's goiing a while ago.
>>
>> -- tony
>>
>> On Wed, Mar 10, 2021 at 11:29 AM Robert Raszuk  wrote:
>>
>>> Peter,
>>>
>>> > But suddenly the DOWN event distribution is considered
>>> > problematic. Not sure I follow.
>>>
>>> In routing and IP reachability we use p2mp distribution and flooding as
>>> it is required to provide any to any connectivity.
>>>
>>> Such spray model no longer fits services where not every endpoint
>>> participates in all services.
>>>
>>> So my point is that just because you have transport ready we should not
>>> continue to announce neither good nor bad news in spray fashion for
>>> services.
>>>
>>> Sure it works, but it is hardly a good design and sound architecture.
>>>
>>> It happened to BGP as the convenience of already having TCP sessions
>>> between nodes was so great that we loaded loads of stuff to go along basic
>>> routing reachability.
>>>
>>> And now it seems time came to do the same with IGPs :).
>>>
>>> I think unless we stop and define a real pub-sub messaging protocol
>>> (like FB does with open-R)  we will continue this.
>>>
>>> And to me it is like building a tower from the cards ... the higher you
>>> go the more likely your entire tower is to collapse.
>>>
>>> Cheers,
>>> R.
>>>
>>> PS.
>>>
>>> > with MPLS loopback address of all PEs is advertised everywhere.
>>>
>>> Is this a feature or a day one design bug later fixed by RFC5283 ?
>>>
>>>
>>>
>>>
>>> On Wed, Mar 10, 2021 at 9:10 AM Peter Psenak  wrote:
>>>
 Robert,


 On 09/03/2021 19:30, Robert Raszuk wrote:
 > Hi Peter,
 >
 >  > Example 1:
 >  >
 >  > If session to PE1 goes down, withdraw all RDs received from
 such PE.
 >
 > still dependent on RDs and BGP specific.
 >
 >
 > To me this does sound like a feature ... to you I think it was rather
 > pejorative.

 not sure I understand your point with "pejorative"...

 There are other ways to provide services outside of BGP - think GRE,
 IPsec, etc. The solution should cover them all.

 >
 > We want app independent way of
 > signaling the reachability loss. At the end that's what IGPs do
 without
 > a presence of summarization.
 >
 >
 > Here you go. I suppose you just drafted the first use case for OSPF
 > Transport Instance.

 you said it, not me.


 >
 > I suppose you just run new ISIS or OSPF Instance and flood info about
 PE
 > down events to all other instance nodes (hopefully just PEs and no Ps
 as
 > such plane would be OTT one).  Still you will be flooding this to
 100s
 > of PEs which may never need this information at all which I think is
 the
 > main issue here. Such bad news IMHO should be distributed on a
 pub/sub
 > basis only. First you subscribe then you get updates ... not get
 > everything then keep junk till it get's removed or expires.

 with MPLS loopback address of all PEs is advertised everywhere. So you
 keep the state when the remote PE loopback is up and you get a state
 withdrawal when the remote PE loopback goes down.

 In Srv6, with summarization we can reduced the amount of UP state to
 minimum. But suddenly the DOWN event distribution is considered
 problematic. Not sure I follow.

 thanks,
 Peter

 >
 > Many thx,
 > Robert
 >

 ___
>>> 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] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Robert Raszuk]

>  You think Kafka here?

Nope ... I meant ZeroMQ message bus as underlaying pub-sub transport for
service related info.

Thx,
R.,


On Wed, Mar 10, 2021 at 11:41 AM Tony Przygienda 
wrote:

> ? Last time I looked @ it (and it's been a while) Open-R had nothing of
> that sort, it was basically KV playing LSDB (innovative and clever in
> itself). You think Kafka here? Which in turn needs underlying IGP however
> and is nothing but BGP problems in new clothes having looked @ their
> internal architecture and where it's goiing a while ago.
>
> -- tony
>
> On Wed, Mar 10, 2021 at 11:29 AM Robert Raszuk  wrote:
>
>> Peter,
>>
>> > But suddenly the DOWN event distribution is considered
>> > problematic. Not sure I follow.
>>
>> In routing and IP reachability we use p2mp distribution and flooding as
>> it is required to provide any to any connectivity.
>>
>> Such spray model no longer fits services where not every endpoint
>> participates in all services.
>>
>> So my point is that just because you have transport ready we should not
>> continue to announce neither good nor bad news in spray fashion for
>> services.
>>
>> Sure it works, but it is hardly a good design and sound architecture.
>>
>> It happened to BGP as the convenience of already having TCP sessions
>> between nodes was so great that we loaded loads of stuff to go along basic
>> routing reachability.
>>
>> And now it seems time came to do the same with IGPs :).
>>
>> I think unless we stop and define a real pub-sub messaging protocol (like
>> FB does with open-R)  we will continue this.
>>
>> And to me it is like building a tower from the cards ... the higher you
>> go the more likely your entire tower is to collapse.
>>
>> Cheers,
>> R.
>>
>> PS.
>>
>> > with MPLS loopback address of all PEs is advertised everywhere.
>>
>> Is this a feature or a day one design bug later fixed by RFC5283 ?
>>
>>
>>
>>
>> On Wed, Mar 10, 2021 at 9:10 AM Peter Psenak  wrote:
>>
>>> Robert,
>>>
>>>
>>> On 09/03/2021 19:30, Robert Raszuk wrote:
>>> > Hi Peter,
>>> >
>>> >  > Example 1:
>>> >  >
>>> >  > If session to PE1 goes down, withdraw all RDs received from
>>> such PE.
>>> >
>>> > still dependent on RDs and BGP specific.
>>> >
>>> >
>>> > To me this does sound like a feature ... to you I think it was rather
>>> > pejorative.
>>>
>>> not sure I understand your point with "pejorative"...
>>>
>>> There are other ways to provide services outside of BGP - think GRE,
>>> IPsec, etc. The solution should cover them all.
>>>
>>> >
>>> > We want app independent way of
>>> > signaling the reachability loss. At the end that's what IGPs do
>>> without
>>> > a presence of summarization.
>>> >
>>> >
>>> > Here you go. I suppose you just drafted the first use case for OSPF
>>> > Transport Instance.
>>>
>>> you said it, not me.
>>>
>>>
>>> >
>>> > I suppose you just run new ISIS or OSPF Instance and flood info about
>>> PE
>>> > down events to all other instance nodes (hopefully just PEs and no Ps
>>> as
>>> > such plane would be OTT one).  Still you will be flooding this to 100s
>>> > of PEs which may never need this information at all which I think is
>>> the
>>> > main issue here. Such bad news IMHO should be distributed on a pub/sub
>>> > basis only. First you subscribe then you get updates ... not get
>>> > everything then keep junk till it get's removed or expires.
>>>
>>> with MPLS loopback address of all PEs is advertised everywhere. So you
>>> keep the state when the remote PE loopback is up and you get a state
>>> withdrawal when the remote PE loopback goes down.
>>>
>>> In Srv6, with summarization we can reduced the amount of UP state to
>>> minimum. But suddenly the DOWN event distribution is considered
>>> problematic. Not sure I follow.
>>>
>>> thanks,
>>> Peter
>>>
>>> >
>>> > Many thx,
>>> > Robert
>>> >
>>>
>>> ___
>> 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] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Tony Przygienda]

? Last time I looked @ it (and it's been a while) Open-R had nothing of
that sort, it was basically KV playing LSDB (innovative and clever in
itself). You think Kafka here? Which in turn needs underlying IGP however
and is nothing but BGP problems in new clothes having looked @ their
internal architecture and where it's goiing a while ago.

-- tony

On Wed, Mar 10, 2021 at 11:29 AM Robert Raszuk  wrote:

> Peter,
>
> > But suddenly the DOWN event distribution is considered
> > problematic. Not sure I follow.
>
> In routing and IP reachability we use p2mp distribution and flooding as it
> is required to provide any to any connectivity.
>
> Such spray model no longer fits services where not every endpoint
> participates in all services.
>
> So my point is that just because you have transport ready we should not
> continue to announce neither good nor bad news in spray fashion for
> services.
>
> Sure it works, but it is hardly a good design and sound architecture.
>
> It happened to BGP as the convenience of already having TCP sessions
> between nodes was so great that we loaded loads of stuff to go along basic
> routing reachability.
>
> And now it seems time came to do the same with IGPs :).
>
> I think unless we stop and define a real pub-sub messaging protocol (like
> FB does with open-R)  we will continue this.
>
> And to me it is like building a tower from the cards ... the higher you go
> the more likely your entire tower is to collapse.
>
> Cheers,
> R.
>
> PS.
>
> > with MPLS loopback address of all PEs is advertised everywhere.
>
> Is this a feature or a day one design bug later fixed by RFC5283 ?
>
>
>
>
> On Wed, Mar 10, 2021 at 9:10 AM Peter Psenak  wrote:
>
>> Robert,
>>
>>
>> On 09/03/2021 19:30, Robert Raszuk wrote:
>> > Hi Peter,
>> >
>> >  > Example 1:
>> >  >
>> >  > If session to PE1 goes down, withdraw all RDs received from such
>> PE.
>> >
>> > still dependent on RDs and BGP specific.
>> >
>> >
>> > To me this does sound like a feature ... to you I think it was rather
>> > pejorative.
>>
>> not sure I understand your point with "pejorative"...
>>
>> There are other ways to provide services outside of BGP - think GRE,
>> IPsec, etc. The solution should cover them all.
>>
>> >
>> > We want app independent way of
>> > signaling the reachability loss. At the end that's what IGPs do
>> without
>> > a presence of summarization.
>> >
>> >
>> > Here you go. I suppose you just drafted the first use case for OSPF
>> > Transport Instance.
>>
>> you said it, not me.
>>
>>
>> >
>> > I suppose you just run new ISIS or OSPF Instance and flood info about
>> PE
>> > down events to all other instance nodes (hopefully just PEs and no Ps
>> as
>> > such plane would be OTT one).  Still you will be flooding this to 100s
>> > of PEs which may never need this information at all which I think is
>> the
>> > main issue here. Such bad news IMHO should be distributed on a pub/sub
>> > basis only. First you subscribe then you get updates ... not get
>> > everything then keep junk till it get's removed or expires.
>>
>> with MPLS loopback address of all PEs is advertised everywhere. So you
>> keep the state when the remote PE loopback is up and you get a state
>> withdrawal when the remote PE loopback goes down.
>>
>> In Srv6, with summarization we can reduced the amount of UP state to
>> minimum. But suddenly the DOWN event distribution is considered
>> problematic. Not sure I follow.
>>
>> thanks,
>> Peter
>>
>> >
>> > Many thx,
>> > Robert
>> >
>>
>> ___
> 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] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Peter Psenak]

Robert,

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

Peter,

 > But suddenly the DOWN event distribution is considered
 > problematic. Not sure I follow.

In routing and IP reachability we use p2mp distribution and flooding as 
it is required to provide any to any connectivity.


Such spray model no longer fits services where not every endpoint 
participates in all services.


So my point is that just because you have transport ready we should not 
continue to announce neither good nor bad news in spray fashion for 
services.


Sure it works, but it is hardly a good design and sound architecture.

It happened to BGP as the convenience of already having TCP sessions 
between nodes was so great that we loaded loads of stuff to go along 
basic routing reachability.


And now it seems time came to do the same with IGPs :).

I think unless we stop and define a real pub-sub messaging protocol 
(like FB does with open-R)  we will continue this.


you are of course free to do that. Here we are at the LSR WG.

thanks,
Peter





And to me it is like building a tower from the cards ... the higher you 
go the more likely your entire tower is to collapse.


Cheers,
R.

PS.

 > with MPLS loopback address of all PEs is advertised everywhere.

Is this a feature or a day one design bug later fixed by RFC5283 ?




On Wed, Mar 10, 2021 at 9:10 AM Peter Psenak > wrote:


Robert,


On 09/03/2021 19:30, Robert Raszuk wrote:
 > Hi Peter,
 >
 >      > Example 1:
 >      >
 >      > If session to PE1 goes down, withdraw all RDs received
from such PE.
 >
 >     still dependent on RDs and BGP specific.
 >
 >
 > To me this does sound like a feature ... to you I think it was
rather
 > pejorative.

not sure I understand your point with "pejorative"...

There are other ways to provide services outside of BGP - think GRE,
IPsec, etc. The solution should cover them all.

 >
 >     We want app independent way of
 >     signaling the reachability loss. At the end that's what IGPs
do without
 >     a presence of summarization.
 >
 >
 > Here you go. I suppose you just drafted the first use case for OSPF
 > Transport Instance.

you said it, not me.


 >
 > I suppose you just run new ISIS or OSPF Instance and flood info
about PE
 > down events to all other instance nodes (hopefully just PEs and
no Ps as
 > such plane would be OTT one).  Still you will be flooding this to
100s
 > of PEs which may never need this information at all which I think
is the
 > main issue here. Such bad news IMHO should be distributed on a
pub/sub
 > basis only. First you subscribe then you get updates ... not get
 > everything then keep junk till it get's removed or expires.

with MPLS loopback address of all PEs is advertised everywhere. So you
keep the state when the remote PE loopback is up and you get a state
withdrawal when the remote PE loopback goes down.

In Srv6, with summarization we can reduced the amount of UP state to
minimum. But suddenly the DOWN event distribution is considered
problematic. Not sure I follow.

thanks,
Peter

 >
 > Many thx,
 > Robert
 >



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

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Robert Raszuk]

Peter,

> But suddenly the DOWN event distribution is considered
> problematic. Not sure I follow.

In routing and IP reachability we use p2mp distribution and flooding as it
is required to provide any to any connectivity.

Such spray model no longer fits services where not every endpoint
participates in all services.

So my point is that just because you have transport ready we should not
continue to announce neither good nor bad news in spray fashion for
services.

Sure it works, but it is hardly a good design and sound architecture.

It happened to BGP as the convenience of already having TCP sessions
between nodes was so great that we loaded loads of stuff to go along basic
routing reachability.

And now it seems time came to do the same with IGPs :).

I think unless we stop and define a real pub-sub messaging protocol (like
FB does with open-R)  we will continue this.

And to me it is like building a tower from the cards ... the higher you go
the more likely your entire tower is to collapse.

Cheers,
R.

PS.

> with MPLS loopback address of all PEs is advertised everywhere.

Is this a feature or a day one design bug later fixed by RFC5283 ?




On Wed, Mar 10, 2021 at 9:10 AM Peter Psenak  wrote:

> Robert,
>
>
> On 09/03/2021 19:30, Robert Raszuk wrote:
> > Hi Peter,
> >
> >  > Example 1:
> >  >
> >  > If session to PE1 goes down, withdraw all RDs received from such
> PE.
> >
> > still dependent on RDs and BGP specific.
> >
> >
> > To me this does sound like a feature ... to you I think it was rather
> > pejorative.
>
> not sure I understand your point with "pejorative"...
>
> There are other ways to provide services outside of BGP - think GRE,
> IPsec, etc. The solution should cover them all.
>
> >
> > We want app independent way of
> > signaling the reachability loss. At the end that's what IGPs do
> without
> > a presence of summarization.
> >
> >
> > Here you go. I suppose you just drafted the first use case for OSPF
> > Transport Instance.
>
> you said it, not me.
>
>
> >
> > I suppose you just run new ISIS or OSPF Instance and flood info about PE
> > down events to all other instance nodes (hopefully just PEs and no Ps as
> > such plane would be OTT one).  Still you will be flooding this to 100s
> > of PEs which may never need this information at all which I think is the
> > main issue here. Such bad news IMHO should be distributed on a pub/sub
> > basis only. First you subscribe then you get updates ... not get
> > everything then keep junk till it get's removed or expires.
>
> with MPLS loopback address of all PEs is advertised everywhere. So you
> keep the state when the remote PE loopback is up and you get a state
> withdrawal when the remote PE loopback goes down.
>
> In Srv6, with summarization we can reduced the amount of UP state to
> minimum. But suddenly the DOWN event distribution is considered
> problematic. Not sure I follow.
>
> thanks,
> Peter
>
> >
> > Many thx,
> > Robert
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR meeting comment on draft-acee-lsr-ospf-transport-instance

[Aijun Wang]

Hi, Authors:

 

I think other use case, such as 3.2 and 3.3 can also be solved by other means.

Following the direction of using different routing instances to transfer such 
information is not one feasible way.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Uma Chunduri
Sent: Tuesday, March 9, 2021 4:48 AM
To: lsr@ietf.org
Subject: [Lsr] LSR meeting comment on draft-acee-lsr-ospf-transport-instance

 

Dear Authors,

 

Just want to quickly clarify my comment today on this draft.

 

We know there was a significant discussion many years ago when similar work was 
done during  RFC 6822 (ISIS-MI) and RFC 6823 (GenInfo).  The usefulness of this 
is evident with the more recent publication 
https://datatracker.ietf.org/doc/rfc8202/. I am certainly not in the group and 
would not question 'why' this is needed in OSPF.

 

However, section 3.1 use cases are difficult to understand and quite frankly 
either through the reference (ETSI-WP28-MEC) or the cases listed. As long as 
there is overlay in those networks (with the 3GPP preferred option expanded 
rapidly for multiple interfaces beyond N9, F1, W1 etc after REL16+) the 
usefulness of this core network and application info into the underlay and 
routing layer is limited and even more so for UEs. 

 

So please either expand the use case (sec 3.1) to see how this is applicable or 
leave it out for future scenarios.

 

--

Uma C.

 

 

 

 

 

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

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Peter Psenak]

Robert,


On 09/03/2021 19:30, Robert Raszuk wrote:

Hi Peter,

 > Example 1:
 >
 > If session to PE1 goes down, withdraw all RDs received from such PE.

still dependent on RDs and BGP specific. 



To me this does sound like a feature ... to you I think it was rather 
pejorative.


not sure I understand your point with "pejorative"...

There are other ways to provide services outside of BGP - think GRE, 
IPsec, etc. The solution should cover them all.




We want app independent way of
signaling the reachability loss. At the end that's what IGPs do without
a presence of summarization.


Here you go. I suppose you just drafted the first use case for OSPF 
Transport Instance.


you said it, not me.




I suppose you just run new ISIS or OSPF Instance and flood info about PE 
down events to all other instance nodes (hopefully just PEs and no Ps as 
such plane would be OTT one).  Still you will be flooding this to 100s 
of PEs which may never need this information at all which I think is the 
main issue here. Such bad news IMHO should be distributed on a pub/sub 
basis only. First you subscribe then you get updates ... not get 
everything then keep junk till it get's removed or expires.


with MPLS loopback address of all PEs is advertised everywhere. So you 
keep the state when the remote PE loopback is up and you get a state 
withdrawal when the remote PE loopback goes down.


In Srv6, with summarization we can reduced the amount of UP state to 
minimum. But suddenly the DOWN event distribution is considered 
problematic. Not sure I follow.


thanks,
Peter



Many thx,
Robert



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