Robert On Mon, Nov 29, 2021 at 7:35 PM Robert Raszuk <rob...@raszuk.net> 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. > > 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > -- <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
