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”)

[Shraddha Hegde]

>Calling RSVP-TE, SR, LFA or Flex-Algo as "applications" is confusing as those 
>are network forwarding paradigms and >not applications.
I totally agree with that. It is very confusing to call them applications . I 
do see new drafts that mistakenly assume ASLA can be used to advertise 
application specific values. What it also implies is that the way industry is 
evolving, it is required to advertise “User application” specific values and 
use them to build paths no-matter what network forwarding paradigms are used.
Having a protocol extension that allows for wildcarding the attributes for 
these forwarding paradigms is useful.

Looks like the other side of the argument is, it would have been useful if it 
was done in RFC 8919/RFC 8920 but since its an RFC now, we should carry that 
debt forever. I don’t agree with that argument and believe we still have 
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 
; Martin Horneffer 
Subject: 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”)

[External Email. Be cautious of content]

Hi Les,

Nope the abbreviation is not confusing.

Calling RSVP-TE, SR, LFA or Flex-Algo as "applications" is confusing as those 
are network forwarding paradigms and not applications.

Applications (read user applications which samples I provided) are running on 
top of them. What you call applications are merely different types of pipes to 
carry user applications.

And that alone if you just stay focused on IGP may be all fine. But the moment 
you need to carry user applications over your (network) applications each with 
set of different colors the picture becomes very confusing.

- - -

In any case - aside from the above - even considering your terminology, 
physical properties of the links are not application dependent. Irrespective of 
what encapsulation you use for your traffic for example the value of 
propagation delay of the link will always be application independent. Hence it 
does make sense to advertise it with ANY wildcard notion.

Especially that you always have the ability within each such "application" 
algorithm definition or with use of link affinities to further select which 
specific links and link attributes to use to compute an instance of a  
forwarding paradigm.

Thx,
R.


On Sun, Mar 27, 2022 at 12:21 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Robert –

The complete name (as reflected in the referenced registry name) is:  Link 
Attribute Application Identifiers

In the context of ASLA we tend 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 mailto:rob...@raszuk.net>>
Sent: Saturday, March 26, 2022 3:16 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: lsr mailto:lsr@ietf.org>>; Christian Hopps 
mailto:cho...@chopps.org>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Martin Horneffer 
mailto:m...@lab.dtag.de>>
Subject: 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”)

Hi Les,

What you call "an application" is simply counter intuitive and not what 99.9% 
of people understand by this term. Application to me is a web server running on 
the host waiting for user requests, SIP gateway providing VoIP connections, 
database instance running on some specific port and responding to SQL queries, 
multicast streaming etc ...

Each of these real applications may benefit from different network 
transport/forwarding class.

Calling a network forwarding class as "an application" only generates huge 
confusion. Networks are servants to the user applications. Networks are not the 
applications itself.

As each user application may benefit from different treatment it can be mapped 
to different network transport or network color. So again network color could 
be seen as a network behaviour constructed in an optimal way to the user 
application it is designed to carry.

When you say "You also can – using the algo specific FAD – specify which colors 
are to be used by a given algo." to me means that you are also overloading the 
term "color" - at least from the notion of how CAR or CT proposal are defining 
it. And what CAR/CT proposals call a transport color is actually in line with 
network forwarding class and very intuitive.

As you recall a few months back I defined an IP TE solution where we can steer 
packets between nodes without any stack of labels or segments imposed on them 
upfront on ingress. That would be in your terminology new application - as it 
does not use SPF, but constructs end to end 

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

[Tony Li]

Hi Aijun,

> Let’s focus on the comparison of NLP and PUAM(Prefix Unreachable Announcement 
> Mechanism):
> For NLP, the receiver should register the interested prefixes first. Once the 
> node fails, all the receivers(normally the nodes within one area) that 
> register such interested prefixes will be notified.
> For PUAM, the receiver NEED NOT register anything.   Once the 
> node fails, all the receivers(normally the nodes within one area) will be 
> notified.
>  
> From the POV of the receiver, if it gets the same results, why don’t select 
> the approach that need less work or nothing to do?


Because the primary goal is stability, not efficiency.

PUA adds load to the IGP. That’s a Very Bad Thing.


> And regarding to your arguments of “Dump Truck” worry about IGP protocol, I 
> think defining one new protocol does not solve the ultimate pressure on 
> Router. Let’s explain this via one analogy:
> The customer(Operator) want the truck(IGP Protocol) to piggyback(via some 
> Tag) some information, the driver(Vendor) said he can’t, because the truck 
> may crush the station(Router) when it pass. The operator need another 
> truck(New Protocol) to carry it.
>  
> Here is the problem then, from the POV of station(Router), if it can’t endure 
> the pass of one truck, why can it can stand to pass the two trucks at the 
> same time?
> Wish you can explain the above paradox in reasonable/logical manner.


Very simple: one of those trucks is vital. The IGP MUST have highest priority 
at all times and should not be burdened with extraneous information. It is not 
a dump truck.

I’m proposing that we use NLP as the dump truck. It can run at a lower priority 
than the IGP. It does not impact IGP flooding or scale. If it gets behind, yes, 
it will affect higher function convergence, but IGP convergence should be 
unaffected.

And, if you didn’t notice, you can run it on a proxy, outside of any router. So 
it really can’t get in the way.

Regards,
Tony

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

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

[Aijun Wang]

Hi, Tony:

Let’s focus on the comparison of NLP and PUAM(Prefix Unreachable Announcement 
Mechanism):

For NLP, the receiver should register the interested prefixes first. Once the 
node fails, all the receivers(normally the nodes within one area) that register 
such interested prefixes will be notified.

For PUAM, the receiver NEED NOT register anything.   Once the 
node fails, all the receivers(normally the nodes within one area) will be 
notified.

 

>From the POV of the receiver, if it gets the same results, why don’t select 
>the approach that need less work or nothing to do?

 

And regarding to your arguments of “Dump Truck” worry about IGP protocol, I 
think defining one new protocol does not solve the ultimate pressure on Router. 
Let’s explain this via one analogy:

The customer(Operator) want the truck(IGP Protocol) to piggyback(via some Tag) 
some information, the driver(Vendor) said he can’t, because the truck may crush 
the station(Router) when it pass. The operator need another truck(New Protocol) 
to carry it.

 

Here is the problem then, from the POV of station(Router), if it can’t endure 
the pass of one truck, why can it can stand to pass the two trucks at the same 
time?

Wish you can explain the above paradox in reasonable/logical manner.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Tony Li
Sent: Friday, March 25, 2022 7:20 PM
To: Aijun Wang 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the 
node live?

 

 

Hi Aijun,

 

Thanks for your clarification of the NLP mechanism during the meeting.

1. Regarding to the PUB/SUB model within IETF, there are already some of 
them:

1)   
https://datatracker.ietf.org/doc/html/rfc8641 (Subscription to YANG 
Notifications for Datastore Updates)

2)   
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09

3)   
https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile

4)   
https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-09

Why do we need to invent the new one again?

 

 

Thank you, I was unaware of these.  If the WG is interested, I’m certainly 
willing to pursue using one of these.

As far as I can tell from a quick perusal, none of these is intended to be 
generic.  That is to say, none of them 

is a dump truck either.

 





And, if we prefer to the PUB/SUB model to solve the discussed problem, why 
RFC8641 can’t be used?

 

 

YANG is evil. :-)

 

 

2. Regarding to the NLP mechanism itself:

As you explained, current NLP adopt the “Subscribe Summary Prefixes, Notify the 
failure of Specific Address” to reduces the pressures on ABRs. Such approach 
has the following drawbacks again:

1) The register should know in advance the summary prefixes that the peers‘ 
loopback address belong to. Once the summary prefixes are changed, such 
information should be updated, which will be headache for the operators

 

 

Not at all. Loopback address configuration is already handled by the management 
plane. A prefix or multiple prefixes for loopback addresses will also be 
incorporated into the management plane.

 

Modern networking assumes automation. Yes, we didn’t have it back when I 
started, but it’s there today. Admittedly, it’s not perfect and it has a way to 
go, but there are MANY organizations now that are fully automated.  Anyone that 
wants to be, can be.

 





2) If the register subscribe the “summary prefixes”, then it will receives 
all the nodes fail notifications within this summary prefixes, which should be 
avoided when you argue that IGP flooding has such side effect.The results 
is, NLP can’t avoid it also, then why don’t we utilize IGP flooding mechanism 
directly?

 

 

Yes, if you register for a prefix, you may get multiple notifications back. 
This is a good thing. In the IGP, this would create a scalability problem. The 
very good news is that this is not a scalability problem for NLP.  There is no 
restriction for a finite sized LSDB. There are no real-time demands. The 
distribution of the data can be easily managed, even for slow receivers, by 
techniques that are well-known for BGP.

 

Using a real transport protocol instead of relying on flooding is a Very Good 
Thing.  And don’t get me wrong, I love flooding. For the things that should be 
flooded. :)

 





3) The controller is already in the network, why not rely on it to relieve 
the pressure of ABRs if we prefer to the PUB/SUB model to solve the questions. 
And, as you stated, the NLP mechanism may be used to transfer other non-IGP 
information, then why bother ABR?

 

 

Yes, we can also solve the PUA problem via a