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

[Robert Raszuk]

Aijun,

Hmm so you want ephemeral indication to trigger SPF and affect topology
computation ?

I do not think this is a sound idea.

At least PULSE folks (Peter & Les pls confirm) never assumed PULSE will
trigger SPF and will be used as topology change input.

Thx,
R.



On Thu, Mar 31, 2022 at 10:46 AM Aijun Wang 
wrote:

> Hi, Robert:
>
>
>
> There are possibilities that only one of the ABRs is detached from other
> nodes in the same area, the receivers should select other ABRs to reach the
> destination announced by PUA message.
>
> Such scenario is described in
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-3.2
> .
>
> The corresponding solution will be updated later.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org  *On Behalf Of *Robert
> Raszuk
> *Sent:* Wednesday, March 30, 2022 4:58 PM
> *To:* Aijun Wang 
> *Cc:* Aijun Wang ; Tony Li ;
> lsr 
> *Subject:* Re: [Lsr] Is it necessary to define new PUB/SUB model to
> monitor the node live?
>
>
>
> Hi Aijun,
>
>
>
> *" Incremental SPF or other mechanism can be used to parse such
> unreachable information on the receiver to decrease Tony’ worry for the
> stability of “vital truck”.*
>
>
>
> H - could you kindly elaborate a bit more what *incremental SPF* has
> anything to do with parsing such unreachable information ?
>
>
>
> Thx a lot,
>
> Robert
>
>
>
>
>
>
>
> On Wed, Mar 30, 2022 at 10:48 AM Aijun Wang 
> wrote:
>
> Hi, Robert:
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Tuesday, March 29, 2022 3:53 PM
> *To:* Aijun Wang 
> *Cc:* Tony Li ; Aijun Wang ;
> lsr 
> *Subject:* Re: [Lsr] Is it necessary to define new PUB/SUB model to
> monitor the node live?
>
>
>
> Aijun,
>
>
>
> Your email is written prove that my question the other day which
> remain not answered is valid.
>
>
>
> I asked is the scope of PUA/PULSE to only signal service endpoints or is
> this to also carry any to any liveness across all areas/levels in the link
> state IGP ?
>
>
>
> It seems clear that you say is the latter. Not sure if PULSE authors are
> of the same opinion.
>
> *[WAJ] The scope of PUA can cover and aim to solve both scenarios.*
>
>
>
> If every node is interested in every other node's liveness that we are
> redefining scope of the work here, but I may still argue that not every
> node in the network will have a segment endpoints terminating on every
> other node.
>
> *[WAJ] Yes, such full mesh any-to-any connection may not happen at the
> same time, but the possibility of any to any segment list exists, the
> overall effect is that the any to any notification is needed *
>
>  So registration model handled outside of active link state nodes IMO
> still is far superior to flood and forget (via timeout) type of model.
>
> *[WAJ] Invent the new truck will alleviate the burden of the
> station(Router).  Utilize the existing flood mechanism to meet the above
> scenarios are the most efficient way.  Incremental SPF or other mechanism
> can be used to parse such unreachable information on the receiver to
> decrease Tony**’ worry for the stability of “vital truck”.*
>
>
>
> Best,
>
> R.
>
>
>
>
___
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, Robert:

 

There are possibilities that only one of the ABRs is detached from other nodes 
in the same area, the receivers should select other ABRs to reach the 
destination announced by PUA message. 

Such scenario is described in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-3.2.

The corresponding solution will be updated later.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Robert Raszuk
Sent: Wednesday, March 30, 2022 4:58 PM
To: Aijun Wang 
Cc: Aijun Wang ; Tony Li ; lsr 

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

 

Hi Aijun,

 

" Incremental SPF or other mechanism can be used to parse such unreachable 
information on the receiver to decrease Tony’ worry for the stability of “vital 
truck”.

 

H - could you kindly elaborate a bit more what incremental SPF has anything 
to do with parsing such unreachable information ? 

 

Thx a lot,

Robert

 

 

 

On Wed, Mar 30, 2022 at 10:48 AM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Robert:

 

From: Robert Raszuk mailto:rob...@raszuk.net> > 
Sent: Tuesday, March 29, 2022 3:53 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
Cc: Tony Li mailto:tony...@tony.li> >; Aijun Wang 
mailto:wang...@chinatelecom.cn> >; lsr mailto:lsr@ietf.org> >
Subject: Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the 
node live?

 

Aijun,

 

Your email is written prove that my question the other day which remain not 
answered is valid. 

 

I asked is the scope of PUA/PULSE to only signal service endpoints or is this 
to also carry any to any liveness across all areas/levels in the link state IGP 
? 

 

It seems clear that you say is the latter. Not sure if PULSE authors are of the 
same opinion. 

[WAJ] The scope of PUA can cover and aim to solve both scenarios.

 

If every node is interested in every other node's liveness that we are 
redefining scope of the work here, but I may still argue that not every node in 
the network will have a segment endpoints terminating on every other node.

[WAJ] Yes, such full mesh any-to-any connection may not happen at the same 
time, but the possibility of any to any segment list exists, the overall effect 
is that the any to any notification is needed 

 So registration model handled outside of active link state nodes IMO still is 
far superior to flood and forget (via timeout) type of model. 

[WAJ] Invent the new truck will alleviate the burden of the station(Router).  
Utilize the existing flood mechanism to meet the above scenarios are the most 
efficient way.  Incremental SPF or other mechanism can be used to parse such 
unreachable information on the receiver to decrease Tony’ worry for the 
stability of “vital truck”.

 

Best,

R.

 

___
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?

[Robert Raszuk]

Hi Aijun,


*" Incremental SPF or other mechanism can be used to parse such unreachable
information on the receiver to decrease Tony’ worry for the stability of
“vital truck”.*

H - could you kindly elaborate a bit more what *incremental SPF* has
anything to do with parsing such unreachable information ?

Thx a lot,
Robert



On Wed, Mar 30, 2022 at 10:48 AM Aijun Wang 
wrote:

> Hi, Robert:
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Tuesday, March 29, 2022 3:53 PM
> *To:* Aijun Wang 
> *Cc:* Tony Li ; Aijun Wang ;
> lsr 
> *Subject:* Re: [Lsr] Is it necessary to define new PUB/SUB model to
> monitor the node live?
>
>
>
> Aijun,
>
>
>
> Your email is written prove that my question the other day which
> remain not answered is valid.
>
>
>
> I asked is the scope of PUA/PULSE to only signal service endpoints or is
> this to also carry any to any liveness across all areas/levels in the link
> state IGP ?
>
>
>
> It seems clear that you say is the latter. Not sure if PULSE authors are
> of the same opinion.
>
> *[WAJ] The scope of PUA can cover and aim to solve both scenarios.*
>
>
>
> If every node is interested in every other node's liveness that we are
> redefining scope of the work here, but I may still argue that not every
> node in the network will have a segment endpoints terminating on every
> other node.
>
> *[WAJ] Yes, such full mesh any-to-any connection may not happen at the
> same time, but the possibility of any to any segment list exists, the
> overall effect is that the any to any notification is needed *
>
>  So registration model handled outside of active link state nodes IMO
> still is far superior to flood and forget (via timeout) type of model.
>
> *[WAJ] Invent the new truck will alleviate the burden of the
> station(Router).  Utilize the existing flood mechanism to meet the above
> scenarios are the most efficient way.  Incremental SPF or other mechanism
> can be used to parse such unreachable information on the receiver to
> decrease Tony’ worry for the stability of “vital truck”.*
>
>
>
> Best,
>
> R.
>
>
>
___
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, Robert:

 

From: Robert Raszuk  
Sent: Tuesday, March 29, 2022 3:53 PM
To: Aijun Wang 
Cc: Tony Li ; Aijun Wang ; lsr 

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

 

Aijun,

 

Your email is written prove that my question the other day which remain not 
answered is valid. 

 

I asked is the scope of PUA/PULSE to only signal service endpoints or is this 
to also carry any to any liveness across all areas/levels in the link state IGP 
? 

 

It seems clear that you say is the latter. Not sure if PULSE authors are of the 
same opinion. 

[WAJ] The scope of PUA can cover and aim to solve both scenarios.

 

If every node is interested in every other node's liveness that we are 
redefining scope of the work here, but I may still argue that not every node in 
the network will have a segment endpoints terminating on every other node.

[WAJ] Yes, such full mesh any-to-any connection may not happen at the same 
time, but the possibility of any to any segment list exists, the overall effect 
is that the any to any notification is needed 

 So registration model handled outside of active link state nodes IMO still is 
far superior to flood and forget (via timeout) type of model. 

[WAJ] Invent the new truck will alleviate the burden of the station(Router).  
Utilize the existing flood mechanism to meet the above scenarios are the most 
efficient way.  Incremental SPF or other mechanism can be used to parse such 
unreachable information on the receiver to decrease Tony’ worry for the 
stability of “vital truck”.

 

Best,

R.

 

___
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?

[Robert Raszuk]

Aijun,

Your email is written prove that my question the other day which remain not
answered is valid.

I asked is the scope of PUA/PULSE to only signal service endpoints or is
this to also carry any to any liveness across all areas/levels in the link
state IGP ?

It seems clear that you say is the latter. Not sure if PULSE authors are of
the same opinion.

If every node is interested in every other node's liveness that we are
redefining scope of the work here, but I may still argue that not every
node in the network will have a segment endpoints terminating on every
other node. So registration model handled outside of active link state
nodes IMO still is far superior to flood and forget (via timeout) type of
model.

Best,
R.

On Tue, Mar 29, 2022 at 3:40 AM Aijun Wang 
wrote:

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

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

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

[Acee Lindem (acee)]

I agree with Tony that these other PUB/SUB efforts aren’t directly applicable. 
I don’t necessarily agree that YANG is evil though  However, note that the 
I2RS effort (where such a route monitoring capability was envisioned) was for 
the most part unsuccessful.


Thanks,
Acee

From: Lsr  on behalf of Tony Li 
Date: Friday, March 25, 2022 at 7:20 AM
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 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
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?

[Tony Li]

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 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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr