Tony,
On 19/11/2021 04:16, Aijun Wang wrote:
Hi, Tony:
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Tony Li
Sent: Friday, November 19, 2021 9:08 AM
To: Aijun Wang <[email protected]>
Cc: Tony Przygienda <[email protected]>; Les Ginsberg (ginsberg) <[email protected]>; Gyan
Mishra <[email protected]>; [email protected]; Christian Hopps <[email protected]>; Acee Lindem
(acee) <[email protected]>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR
Meeting Minutes
Hi Aijun,
At the risk of Tony confusion…
[WAJ] Will not confuse due to the different speaking and wording style.
Agreeing with T. Li here (i.e. BFD next-hops) and let me add that AFAIS the
confusion here is that a presence of a /32 route is used as SSAP liveliness
AFAIS and that's simply not what IGPs are here for if you consider their main
job to be fastest possible convergence in network _reachability_ only and not
signalling of service failures.
[WAJ] The problem is arose from the summary action of IGP, why let other
protocols solve it?
There is no ‘problem’ with the IGP. You seem to want liveness from the IGP.
That’s not a property that it was meant to provide.
today IGPs provide reachability for the host route of remote PEs. Both
up and down events are propagated everywhere. If such host route becomes
unreachable, it is being used by BGP PIC to trigger the reroute.
When summarization is in place, to help IGP to scale, the remote PEs'
reachability is announced in a form of a summary and host routes are
suppressed. Providing down notification for the host prefix covered by
the summary is similar in nature to what happens without the
summarization. And if that down notification can be done in smart way,
we are still better off compared to what we do today without a
summarization.
You can call it liveness or something else, but IGPs are already doing
so without the summarization. Arguing that it's not a property that IGPs
were meant to provide is misleading.
thanks,
Peter
[WAJ] The IGP advertises the summary reachability. The overlay service(BGP or
tunnel) established based on this information. But when the endpoint of these
overlay service is unreachable, the IGP still advertises the summary
reachability. IGP should leak the actual information in such situation, doesn't
insist that it can reach these failed address.
And, as we have presented in the IETF meeting, the ABR Need Not advertise such
information once there is prefix unreachable. The operator can configure the
tracked/interested prefixes on the ABR.
We want scalability. That implies abstraction and that means that you can’t get
a full link state database everywhere.
[WAJ] Yes. Current solution will not scarify the IGP scalability. As stated
above, Not all link/prefix failures information will be delivered.
If you’re willing to forgo scalability, then do so. Don’t use areas. Just have
a flat routing domain.
Hole punching is going to put you in exactly the same place, sooner or later.
You’re sacrificing scalability and adding another mechanism to do so. Why
bother?
Alternately resolving BGP over BGP as Robert suggests (if I read that correctly) and use RR to
scale out the SSAP nhop availability is possible I think architecturally without garbage-canning
IGPs as "network-wide fast broadcast mechanism" ... I doubt it will do "couple
millisecs" convergence ;-) but can be simpler hardware wise than trying to scale up BFD to
large number of very fast sessions.
[WAJ] The operator doesn’t also want the network is filled with various queer
designs or solutions.
Then why are you proposing one? [BTW, I realize that you intended no offense,
that’s probably NOT the best choice of words.]
There’s a reason that we’ve never gone down the path of hole punching before.
And yes, it’s been discussed before, decades ago.
[WAJ] With the Tunnel Technologies such as SRv6 are accepted/deployed, such
solutions will be needed more and more. I think it is different from the
situation existing decades ago.
Tony
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
