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

[Aijun Wang <[e-mail]>]

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 <[e-mail]> 
Sent: Monday, March 28, 2022 5:01 PM
To: Aijun Wang <[e-mail]>; Tony Li <[e-mail]>
Cc: Aijun Wang <[e-mail]>; lsr <[e-mail]>
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 <[e-mail] <mailto:[e-mail]> > 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: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> > On Behalf Of Tony Li
Sent: Friday, March 25, 2022 7:20 PM
To: Aijun Wang <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]> 
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> 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> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09

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

4)      <https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-09> 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 controller. If the WG chooses to take that path, it can.  Heck, we could choose to say that we believe in the SDN philosophy completely and that IGPs should be deprecated in favor of SDN. Of course, this also addresses the PUA problem. :)

 

Tony

 

_______________________________________________
Lsr mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/lsr