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

Reply via email to