On December 23, 2020 at 1:51:13 PM, Greg Mirsky wrote:
Greg: I have just one reply. I am also leaving in the text where we're waiting for Chair/AD input. Thanks!! Alvaro. ... > > > Method described in Section 3.1.2 monitors the state of the data > > > plane but only for an egress P-PE link of a P-tunnel. As a result, > > > network failures that affect upstream links might not be detected > > > using this method and the MVPN convergence would be determined by the > > > convergence of the BGP control plane. > > > > "...would be determined by the convergence of the BGP control plane." > > > > This is a case where it seems that combining §3.1.1/§3.1.2 would make > > sense. In fact, tracking the state of the root seems helpful in other > > cases too (below) that are looking at different things. You said > > before that you didn't think combining the methods make sense -- can > > you please explain why in this section? > > GIM3>> But that would be my personal opinion that the WG might not agree. > I'm always glad to discuss technical ideas, pros, and contras of that or > this approach to solve the problem but I feel uneasy adding my personal > opinions in the WG document. The document lists a set of techniques but how > they are combined in a product is left for product managers and developers > to decide. > Would you agree? The document already talks about combinations, specifically with root tracking. The text above already mentions "convergence of the BGP control plane", which I think makes direct reference to root tracking. §3.1.3 and §3.1.4 both say that "the downstream PE can immediately update its UMH when the reachability condition changes" -- this is the exact same text used in §3.1.1 to describe root tracking. The opinion of not combining is already not represented in the text, and there is direct reference to using an additional method. If you didn't mean to use the same text to refer to different things then perhaps some clarification would be in order. ... > > > > > > (2b) ... > > > > > > > > > > BTW, I agree with Jeff in > that bfd/idr should be given the opportunity > > > > to review this document. > > > > > > GIM2>> I'm leaving this decision to the AD and Chairs of BESS and BFD WGs. > > > > Yup. ... > > > > > > (18) §3.1.6.2(http://3.1.6.2): If the IP address doesn't map > > > > > > correctly at the downstream PE (for example, a different local > > > > > > address is used that doesn't correspond to the information in the > > > > > > PMSI attribute), what action should it take? Can the tunnel still > > > > > > be monitored? > > > > > > > > > > GIM>> There's a possibility that the same downstream PE is monitoring > > > > > more than one P-tunnel. Since each Upstream PE assigns its own BFD > > > > > Discriminator, there's a chance that the same value is picked by more > > > > > than one Upstream PE. > > > > > According to Section 5.7 of the RFC 8562: > > > > > IP and MPLS multipoint tails MUST demultiplex BFD packets based on a > > > > > combination of the source address, My Discriminator, and the identity > > > > > of the multipoint path that the multipoint BFD Control packet was > > > > > received from. Together they uniquely identify the head of the > > > > > multipoint path. > > > > > > > > > > We may consider adding the source address in the BFD Discriminator > > > > > attribute as an optional TLV. I think that might be a good extension > > > > > that can be introduced in a new document. > > > > > > > > Why wait for a new document? You made a pretty good case for > > > > signaling the source address. > > > > > > GIM2>> I'd like to defer this question to our AD and BESS WG Chairs. > > > > Again, you made a good case for why it is needed for the mechanism to > > work. Leaving it for later might just leave a hole. Sure, let's hear > > from the Chairs/AD. _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
