Robert **Top posting here**
So as the RR sits in the control plane completely disjoint from the forwarding plane, as far as a BGP base solution detection of liveliness PE down detection, this will yield false positive or negative and thus I don’t think is a viable alternative to IGP based solution. I agree if RR are not deployed or the RR is a PE or P box sitting in the forwarding plane then your BGP solution is viable. Many Thanks, Gyan On Mon, Nov 29, 2021 at 7:48 PM Gyan Mishra <[email protected]> wrote: > > On Mon, Nov 29, 2021 at 7:44 PM Gyan Mishra <[email protected]> wrote: > >> >> Robert >> >> On Mon, Nov 29, 2021 at 7:35 PM Robert Raszuk <[email protected]> wrote: >> >>> Hi Greg, >>> >>> If BFD would have autodiscovery built in, that would indeed be the >>>>> ultimate solution. Of course folks will worry about scaling and number of >>>>> BFD sessions to be run PE-PE. >>>>> >>>> GIM>> I sense that it is not "BFD autodiscovery" but an advertisement >>>> of BFD multi-hop system readiness to the particular PE. That, as I think of >>>> it, can be done in a control or management plane. >>>> >>> >>> Agreed. >>> >>> >>>> But if BFD between all PEs would be an option why RR to PE in the local >>>>> area would not be a viable solution ? >>>>> >>>> >>> >>>> GIM>>Because, in the case of PE-PE, BFD control packets will be >>>> fate-sharing with data packets. But the path between RR and PE might not be >>>> used for carrying data packets at all. >>>> >>> >>> 100%. But that was accounted for. Reason being that you have at least >>> two RRs in an area. The point of BFD was to use detect that PE went down. >>> >> >> Gyan> What Greg is alluding is a very good point to consider is that the >> RR in many cases in operator networks sit in the “control plane” path which >> is separate from the data plane path. So the E2E forwarding plane path >> between the PEs, the RR has no knowledge as is it sits outside the >> forwarding plane path. That being said the PE to RR path is disjoint from >> the PE-PE path so from the PE-RR RR POV may think the PE is up or down >> thus the false positive or negative. That would be the case regardless of >> how many RRs are deployed. >> > > Gyan> The RR being mutually exclusive of the forwarding plane is on > purpose as you very well know you don’t want to ever have traffic flow > accidentally forwarding through an RR as is not meant to forward traffic > due to different platform type which could be a NFV software box or > physical but made to handle control plan traffic not data plane traffic. > >> >>> You are absolutely right that it may report RR disconnect from the >>> network while PE is up and data plane from remote PEs can reach it. That is >>> why we have more than one RR. >>> >>> As far as fate sharing PE-PE BFD with real user data - I think it is not >>> always the case. But this is completely separate discussion :) >>> >>> Also please keep in mind that PE going down can be learned by RRs by >>> listening to the IGP. No BFD needed. >>> >>> >>>> Both would be multihop, both would be subject to all transit failures >>>>> etc ... >>>>> >>>> GIM>> I think that there's a difference between the impact a path >>>> failure has on the data traffic. In the case of monitoring PE-PE path in >>>> the underlay and using the same encapsulation as data traffic is >>>> representative of the data experience. A failure of the PE-RR path, in my >>>> understanding, may be not representative at all. BFD session between RR and >>>> PE may fail while PE is absolutely functional from the service PoV. >>>> >>> >>> Please keep in mind that this entire discussion is not about data plane >>> failure end to end :) Yes, it's pretty sad. This entire debate is to >>> indicate domain wide that the IGP component on a PE went down. >>> >>> No one considers data plane liveness and even as you observed data plane >>> encapsulation congruence. Clearly this is not a true OAM discussion. >>> >>> >>>> On the other hand, PE might be disconnected from the service while the >>>> BFD session to RR is in the Up state. >>>> >>> >>> Not likely if you keep in mind that to trigger any remote action such >>> failure would have to happen to all RRs. >>> >>> Thx a lot, >>> R. >>> >>> _______________________________________________ >>> 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* >> >> -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email [email protected] <[email protected]>* > > > > *M 301 502-1347* > > -- <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
