Robert Very good point!
As for summarization and SR framework my thoughts are that inter-as or inter-area for both SR-MPLS and SRv6 you could have SR-TE BSID bind candidate path to forwarding plane at each area border hop or AS hop steering source routing E2E engineered path but you would still need to domain wide flood the loopbacks for SR-MPLS for prefix and node SID for steering and for SRv6 as well would have to flood locators, prefix and node SID as well as for seamless MPLS style building of E2E path as it does apply to SR framework. So I agree we would need IGP extension for both SR-MPLS and SRV6 for ABR & ASBR summarization to avoid domain wide flooding seamless MPLS E2E path instantiation. Kind Regards Gyan On Sun, Nov 21, 2021 at 11:56 AM Robert Raszuk <rob...@raszuk.net> wrote: > Gyan, > > You are missing IGP extensions required for Segment Routing (both SR-MPLS > and SRv6). If you summarize router information at the area boundary > nothing get's propagate outside of area and no one can build SR paths to > your area nodes. Game's over. > > And if you do not summarize you already have what is required. > > Thx, > R. > > > > > On Sun, Nov 21, 2021 at 5:19 PM Gyan Mishra <hayabusa...@gmail.com> wrote: > >> >> >> On Sun, Nov 21, 2021 at 6:50 AM Robert Raszuk <rob...@raszuk.net> wrote: >> >>> >>> > So we desperately need a viable IGP summarization >>> >>> And could you elaborate on how summarization is going to work with >>> Segment Routing ? Not that I am pushing anyone to go there, but looking >>> through the window this seems to be the current trend. >>> >> >> Gyan> SR-MPLS as it reuses the MPLS data plane but relies on IGP >> extension to flood SID label instead of LDP for prefix and node SID it’s >> still exact match host route so the solution we come up with for MPLS would >> apply to SR-MPLS. As for SRv6 it’s standard IP routing LPM based not FEC >> so summarization natively works. My thoughts for SRv6 is that the same >> component host route tracking can be used as well with SRv6 or IPv4 or IPv6 >> forwarding plane. >> >>> >>> We rely on leaking as additional information is attached to host routes. >>> Stopping that breaks the game. >>> >> >> Gyan> Agreed the flooding of host routes for seamless MPLS is a >> requirement also for exact match FEC has to be a host route. >> >>> >>> And btw LDP FECs where always host routes + label so unlike you say - >>> nothing new needed there. As I recall even TDP was carrying host addresses >>> with tags. >>> >> >> Gyan> Understood that LDP LIB and LFIB label mapping message FEC TLV has >> to contain the exact match host route for the MPLS forwarding plane so >> basically we are back in the same boat with RFC 5283 as it’s not a complete >> solution as it just fixes the IGP RIB/FIB making summarization possible but >> does not fix summarization with LDP as LDP still has to maintain all the >> host routes. >> >> I will try to work on MPLS based update to fix RFC 5283 so LDP can use >> summarization LPM match. >> >> Thx, >>> R. >>> >>> On Sun, Nov 21, 2021 at 3:46 AM Gyan Mishra <hayabusa...@gmail.com> >>> wrote: >>> >>>> >>>> Most all operators have not deployed RFC 5283 LDP inter area extension >>>> due to the fact that it shifts the seamless MPLS flooding requirement and >>>> scalability problem from the RIB/FIB to the LFIB. >>>> >>>> So we desperately need a viable IGP summarization solution mitigate >>>> domain wide flooding of host routes. >>>> >>>> Gyan >>>> >>>> On Sat, Nov 20, 2021 at 9:17 PM Gyan Mishra <hayabusa...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> Robert >>>>> >>>>> RFC 5283 provides LDP extension for inter area for LPM summary FEC >>>>> however in this specification the component prefixes are probated via LDP >>>>> which is how the LDP inter-area extension is able to support >>>>> summarization. >>>>> >>>>> The problem here is you make IGP scalable with this LDP inter-area >>>>> extension but then you pass the buck to MPLS which now is not scalable as >>>>> all the flooded prefixes are summarized in the IGP but now the LFIB has to >>>>> suffer from the domain wide flooding. >>>>> >>>>> This issue with domain wide flooding gets much worse with seamless >>>>> MPLS with E2E LSP requirements from core to aggregation layer so now all >>>>> the area and levels within the entire domain had all host routes. This >>>>> can >>>>> be pretty tremendous for large operator networks and a huge scalability >>>>> issue that needs a solution. >>>>> >>>>> See section 7.2 >>>>> >>>>> The solution documented in this document reduces the link state database >>>>> size in the control plane and the number of FIB >>>>> entries in the forwarding plane. As such, it solves the scaling of >>>>> >>>>> pure IP routers sharing the IGP with MPLS routers. However, it does >>>>> not decrease the number of LFIB entries so is not sufficient to solve >>>>> the scaling of MPLS routers. For this, an additional mechanism is >>>>> required (e.g., introducing some MPLS hierarchy in LDP). This is out >>>>> of scope for this document. >>>>> >>>>> >>>>> Bottom of section 7.2 >>>>> >>>>> >>>>> For protocols and applications which need to track egress LER >>>>> availability, several solutions can be used, for example: >>>>> >>>>> - Rely on the LDP ordered label distribution control mode -- as >>>>> defined in [LDP >>>>> <https://datatracker.ietf.org/doc/html/rfc5283#ref-LDP>] -- to know the >>>>> av.ailability of the LSP toward the >>>>> >>>>> egress LER. The egress to ingress propagation time of that >>>>> unreachability information is expected to be comparable to the IGP >>>>> (but this may be implementation dependent). >>>>> >>>>> - Advertise LER reachability in the IGP for the purpose of the >>>>> control plane in a way that does not create IP FIB entries in the >>>>> forwarding plane. >>>>> >>>>> >>>>> Gyan> So for this to work for egress convergence availability tracking >>>>> you either are back to flooding the routes in the IGP or use LDP ordered >>>>> label distribution. >>>>> >>>>> >>>>> Even if you used LDP ordered label distribution is still does not solve >>>>> the problem of robbing Peter to pay Paul now dumping the flooding of host >>>>> routes on MPLS LFIB making it not scalable. >>>>> >>>>> >>>>> Most vendors by default use LDP ordered label distribution defined in RFC >>>>> 3036. >>>>> >>>>> >>>>> However, net-net the problem is not solved. >>>>> >>>>> >>>>> >>>>> >>>>> Kind Regards >>>>> >>>>> Gyan >>>>> >>>>> On Fri, Nov 19, 2021 at 3:25 PM Robert Raszuk <rob...@raszuk.net> >>>>> wrote: >>>>> >>>>>> Peter, >>>>>> >>>>>> >>>>>>> yes, but it's not specific to flat areas. Even in multi-area >>>>>>> deployments >>>>>>> the host routing is mandated by MPLS. >>>>>> >>>>>> >>>>>> In the early days of MPLS yes that was the case. >>>>>> >>>>>> But that "mandate" was fixed by Ina, Bruno and Jean-Louis in 2008 :) >>>>>> >>>>>> https://datatracker.ietf.org/doc/html/rfc5283 >>>>>> >>>>>> In these multi-area deployments >>>>>>> the host routes are sent everywhere, updates are triggered >>>>>>> regardless of >>>>>>> the failure type. IGPs are effectively providing liveness service >>>>>>> between PEs in any MPLS network. >>>>>>> >>>>>> >>>>>> That is true too - as folks just do not know how to configure BGP >>>>>> properly (if BGP is used for services). >>>>>> >>>>>> That leaves us the space what to do where there is no BGP carrying >>>>>> services. Or BGP implementation is broken and can not do the right thing. >>>>>> >>>>>> For the pulse proposal - no one answered the question posted what is >>>>>> a definition of mass failure. But maybe that will be the secret sauce of >>>>>> a >>>>>> vendor :) ? >>>>>> >>>>>> The fact that we are all in agreement that some network events will >>>>>> not work that well with the proposed solution seems to be a >>>>>> sufficient reason for me to consider different solution(s). >>>>>> >>>>>> Thx, >>>>>> R. >>>>>> >>>>> -- >>>>> >>>>> <http://www.verizon.com/> >>>>> >>>>> *Gyan Mishra* >>>>> >>>>> *Network Solutions A**rchitect * >>>>> >>>>> *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* >>>>> >>>>> >>>>> >>>>> *M 301 502-1347* >>>>> >>>>> -- >>>> >>>> <http://www.verizon.com/> >>>> >>>> *Gyan Mishra* >>>> >>>> *Network Solutions A**rchitect * >>>> >>>> *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* >>>> >>>> >>>> >>>> *M 301 502-1347* >>>> >>>> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* >> >> >> >> *M 301 502-1347* >> >> -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
