Re: [Lsr] draft-lin-lsr-flex-algo-metric-00

[Chenmengxiao]

Hi Peter,



Sorry to reply late. Please see inline.



Thanks,

Mengxiao Chen



-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Friday, March 25, 2022 4:16 PM
To: chenmengxiao (RD) ; lsr@ietf.org
Subject: Re: [Lsr] draft-lin-lsr-flex-algo-metric-00



Hi Mengxiao,



please see inline:



On 25/03/2022 07:35, Chenmengxiao wrote:

> Hi Peter,

>

> Thank you for the comments.

>

> Time for the presentation is very limited. Glad to receive your comments

> here.

>

> I agree that flex-algo is much easier to deploy and manage than MT,

> which make it a popular tool now.

>

> But I think using algorithm-specific link metric will not cause the loss

> of this property.

>

> For example, flex-algo 128 and flex-algo 129 need to use different

> metrics of the same metric-type for the same link.

>

> Solution A: Use algorithm-based metric for algorithm 128 and algorithm 129

>

> Solution B: Use metric-type-based metric for metric-type 128 and

> metric-type 129 (according to Shraddha's suggestion,

> draft-ietf-lsr-flex-algo-bw-con)

>

> Both in the two solutions, extra link metric tlvs need to be advertised,

> and they are stored locally, no matter algorithm-based or metric-type-based.



yes, but for B, any other algorithm may share the metric used for algo

128 or 129. That is not possible with A.



You may argue that in your case you only have two algos, so the result

ts similar. Yes, but from the architecture perspective there is a

difference.



[MXC] Yes, from the perspective of protocol, metric-type 128 and 129 in 
solution B are possible to be shared by other algorithm. But if we focus on the 
case here, metric-type 128 and 129 are used to configure their unique metrics 
for the same public type (bandwidth or TE metric), so the chance of sharing may 
be very low in practice.

From another perspective, if we use user-defined metric-type, we need to 
advertise it for every link. But if we use algorithm-specific link metric, the 
algorithm may only advertise the algorithm-specific metrics of a few links 
whose metric value are different from the common metric.



TLV-22 of Solution A:

   metric   <- IGP metric (used by all algorithms, if no algorithm-specific 
advertised)

generic metric  <- other type (used by all algorithms, if no 
algorithm-specific advertised)

ASLA

link attribute<- TE metric/delay (used by all algorithms, if no 
algorithm-specific advertised)

algorithm-specific metric  <- metric for algorithm 128

algorithm-specific metric  <- metric for algorithm 128



TLV-22 of Solution B:

   metric   <- IGP metric (used by all algorithms)

generic metric  <- other type (used by all algorithms)

generic metric  <- type 128 (for algorithm 128)

generic metric  <- type 129 (for algorithm 129)

ASLA

link attribute<- TE metric/delay (used by all algorithms)



Not to mention that for A we would need to extend the FAD.



[MXC] That’s true. I think a new bit in the Flexible Algorithm Definition Flags 
can be used for such extension. We’ve missed it in the current version of 
draft. Thank you for pointing out.



>

> During path computation, the difference is that, solution A needs to

> check if there is algorithm-based metric for the link. If yes,

> algorithm-based metric is preferred. If no, common metric is used.

>

> IMHO, even if the algorithm-specific link metric is used, flex-algo is

> still light weight, compared with MT.



not really, because it advertise algo specific metric that can not be

used by any other algo, which is similar to topology specific metric in MT.



I would encourage you to consider option B as a solution for your problem.



[MXC] Thanks for your suggestion. I don’t doubt that solution B can solve our 
problem at current stage. In solution B, user-defined metric-type is used as a 
substitution for algorithm-specific metric of a standard metric-type.

But if there are strong requirements to advertise different metrics  for 
different algorithms, I would prefer solution A (algorithm-specific link 
metric). Assume that, an algorithm uses metric-type X for path computation, and 
it also uses metric-type Y as constraints. And it has its own metrics for both 
metric-type X and Y. The user-defined metric-type may not be adequate in such 
case.

Besides, I still think that flex-algo with algorithm-specific link metric will 
not become MT. The control plane and data plane are so different.



thanks,

Peter







>

> Thanks,

>

> Mengxiao Chen

>

> -Original Message-

> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak

> Sent: Thursday, March 24, 2022 11:09 PM

> To: lsr@ietf.org

> Subject: [Lsr] draft-lin-lsr-flex-algo-metric-00

>

> Hi,

>

> as I was unable to make my comments during the presentation, let me put

>

> them here:

>

> When we started with the flex-algo work, there has been a lengthy

>

> 

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

[Aijun Wang]

Hi, Robert:

Let’s don’t make the conclusion in hurry.

I think you should know the application scenarios for such unreachable 
information is not only for BGP services, but also for the tunnel services(for 
example, SRv6 loose-path routing). 

For the latter scenario, the P node on the path should know the status of other 
P node on the path, which is located in other areas.

Then, NLP like approach will also result in ALL NODES within the areas needs to 
register such information, and the failures of one nodes will be sent to all 
the register.  

What’s the difference with the IGP flooding mechanism then? 

 

Best 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 monitor the 
node live?

 

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 in the area which do not have any interest what 
so ever will also get it. 

 

Worse - EVERY IGP NODE - in all areas/levels will get it. 

 

Can't you see how bad architecturally that is ? And I do not buy the 
justification - oh this is so little or - oh this is likely to never happen ... 
If that is so why bother when you can just either do it with pub-sub model or 
simply withdraw your service routes (either one by one or in bulk mode) ? 

 

Thx,
R.

 

PS. And if you like analogies - We are here about speed to service restoration 
- correct ? So what is better - to signal node failure using as a carrier a 
local train which requires to change trains at each of say 30 stations or put 
the information into a RAPID one which only stops at two exchange stations ? 

 

 

 

On Mon, Mar 28, 2022 at 3:15 AM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

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   mailto:lsr-boun...@ietf.org> > On Behalf Of Tony Li
Sent: Friday, March 25, 2022 7:20 PM
To: Aijun Wang mailto:wang...@chinatelecom.cn> >
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 

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

[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 in the area which do not have any interest
what so ever will also get it.

Worse - EVERY IGP NODE - in all areas/levels will get it.

Can't you see how bad architecturally that is ? And I do not buy the
justification - oh this is so little or - oh this is likely to never
happen ... If that is so why bother when you can just either do it with
pub-sub model or simply withdraw your service routes (either one by one or
in bulk mode) ?

Thx,
R.

PS. And if you like analogies - We are here about speed to service
restoration - correct ? So what is better - to signal node failure using as
a carrier a local train which requires to change trains at each of say 30
stations or put the information into a RAPID one which only stops at two
exchange stations ?



On Mon, Mar 28, 2022 at 3:15 AM Aijun Wang 
wrote:

> 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, 

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

[Robert Raszuk]

Hi,

> I do see new drafts that mistakenly assume ASLA can be used to advertise
application specific values.

Exactly ! And I do not blame any authors of those new drafts as for anyone
with reading skills "Application Specific Link Attribute" means links
attributes which correspond to either user application (voice, video, web
etc ...) or at best class of service (gold, silver, bronze, grey ...)

No one would think those *applications* are just some forwarding
paradigms or constructs how to compute paths from A to Z.

And I also agree that RFC8919/8920 need revision perhaps -bis to rename
misleading terminology as well as perhaps add ANY flags which can be used
for "application agnostic link attributes - AALA".

Thx,
Robert.


On Mon, Mar 28, 2022 at 7:02 AM Shraddha Hegde  wrote:

>
>
> >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) <
> 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 
> *Sent:* Saturday, March 26, 2022 3:16 PM
> *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”)
>
>
>
> 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