No. Summarization and LPM routing inherent to IP based routing and is native to SRv6 and that discussion is completely orthogonal to the requirement for SRv6 IGP extension for IPv6 data plane.
One of the major benefits of SRv6 over MPLS is that it does not rely on MPLS exact match and E2E LSP and can use LPM match as the SRv6 locators can be LPM summary routes in steering between areas with way point SR-TE BSID policies on ABRs or ASBRs to stitch the E2E path. SRv6-BE BGP service overlay the egress PE signals the L2 L3 VPN service SID for BGP overlay route to SR source node or for SRv6-TE egress PE colors overlay route using RFC 9012 Color extended community for the E2E path instantiation. As the signaling is egress to ingress for the path instantiation, the seamless MPLS style domain wide flooding for E2E LSP stateful path is not required. However summarization is still valuable in an SRv6 domain for summarization of SIDs flooded via SRv6 IGP extension domain wide. Kind Regards Gyan On Mon, Nov 22, 2021 at 8:59 AM Robert Raszuk <[email protected]> wrote: > > Are you saying this draft is useless ? > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ > > Thx, > R. > > > On Mon, Nov 22, 2021 at 2:54 PM Gyan Mishra <[email protected]> wrote: > >> >> Correction related to SRv6 as if uses the native IPv6 data plane it does >> out of the box support summarization. >> >> A gap still exists for MPLS and SR-MPLS. >> >> Kind Regards >> >> Gyan >> >> On Mon, Nov 22, 2021 at 7:18 AM Aijun Wang <[email protected]> >> wrote: >> >>> >>> >>> Aijun Wang >>> China Telecom >>> >>> On Nov 22, 2021, at 18:44, Tony Przygienda <[email protected]> wrote: >>> >>> >>> Just to prop a voice of support to Tony Li's arguments which I have >>> nothing further to add really. He basically elucidated ;-) with flourishes >>> what I wrote in my short, terse email I think. >>> >>> As he says "you either make easy choices and get an operationally >>> unstable environment at scale/large disturbances or you make hard >>> architectural choices & scale much better over time". >>> >>> >>> [WAJ] Easy choices doesn’t definitely get operationally unstable >>> environment(we have explained in previous mails). And would you give some >>> examples to illustrate “hard architecture but scale much better over time?” >>> >>> Examples of that are abound in systems design but it's unfortunately >>> often RFC1295 (4). As a sidenote: IETF has no intention or mechanism to >>> stop people doing unscalable, poorly designed things with their specs >>> >>> >>> [WAJ] like RIFT or flood reflector solutions in IGP? >>> >>> and that was ok as long people did not try to push them onto the whole >>> world without listening to folks who took the scar tissue to get us the >>> IETF working specs we have today which seems to have become fashionable in >>> last couple of years. >>> >>> >>> And fast flooding is a red herring here IMO, it does nothing but >>> accelerate the control loop, if the control loop is positively stable, it's >>> good, if the control loops are oscillating or start to negatively amplify >>> accelerating things just melts everything faster. >>> >>> >>> [WAJ] There is no control loop oscillation. We track only the down event. >>> >>> >>> Ultimately, having followed this "discussion" my opinion is still that >>> if authors would like to abuse IGP as "domain wide broadcast" for >>> liveliness notification the "events" draft is far less fragile and >>> convoluted but should be kept in a service instance as basically "event >>> based BFD substitute" to not start to cause head-blocking on IGP resources. >>> >>> >>> [WAJ] Seems you are not listening other person’s discussion. Please >>> refer to Acee’s comments at >>> https://mailarchive.ietf.org/arch/msg/lsr/zzaPetGzjHsu49KcyBrixQlo5G8/ >>> >>> And AFAIR Robert observed it's still not a very good indication compared >>> to BFD, a good solution would be e.g. in PE case a (hierarchical) MP2MP BFD >>> PMSI (assuming UDP healthy = TCP healthy which is however far less an >>> assumption than "flooding feels transport is OK"). >>> >>> >>> [WAJ] Current solutions are not aimed only the BGP overlay service, but >>> also the tunnel services. For tunnel services how you build MP2MP PMSI? >>> >>> >>> -- tony >>> >>> On Mon, Nov 22, 2021 at 7:55 AM Tony Li <[email protected]> wrote: >>> >>>> >>>> Les, >>>> >>>> >>>> The problem is that restricting the prefix length does nothing to limit >>>> the number of advertisements that get flooded. In a high-scale situation, >>>> when there is a mass failure, it would lead to a flooding spike. That’s >>>> exactly not the time to stress the system. >>>> >>>> *[LES:] As I have stated previously, I share your concern about the >>>> behavior during massive events – and some care has to be taken to prevent >>>> making a bad situation worse.* >>>> *That said, the WG (including you and I) is taking on enhancements to >>>> support much faster flooding – on the order of hundreds (perhaps thousands) >>>> of LSPs/second. We believe this can be done safely (though proof has not >>>> yet been established).* >>>> >>>> >>>> >>>> And the point of doing that was to help improve IGP convergence time… >>>> >>>> >>>> *So, if you believe (as your active participation suggests) that IGPs >>>> can support faster flooding – why do you believe they cannot support >>>> liveness notification at a similar scale?* >>>> >>>> >>>> >>>> … not waste our time by inflating the LSDB by the same amount that we >>>> sped up flooding. >>>> >>>> Also, I don’t see how faster flooding has ANYTHING to do with it. >>>> Adding negative liveness information is primary a scale issue. >>>> >>>> >>>> >>>> *I get that you consider such notifications as architecturally >>>> undesirable – we can agree to disagree on that point.* >>>> *But I don’t get why you think the IGP’s ability to handle large scale >>>> events is a showstopper in this case.* >>>> >>>> >>>> >>>> I am opposed to anything that adds to the scale of the LSDB. Doubly so >>>> if it does so during failures, when the IGP is already under stress. As you >>>> well know, making an IGP stable during normal operations is one thing. >>>> Ensuring that it is stable during worst case topological changes is quite >>>> another. Adding scale during a mass failure is pessimal timing. >>>> >>>> T >>>> >>>> >>>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr >>> >>> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> *Email [email protected] <[email protected]>* >> >> >> >> *M 301 502-1347* >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
