Greg: Hi!
I trust that the changes we’ve discussed are reflected in the diffs. About the new text below…. It looks ok to me. Just a couple of questions: When is this new TLV considered malformed? Given that it is required for p2mp, what action should the receiver make if it is not included? I’m ok with the action being Attribute Discard; I just want that to be explicit. I’ll clear my DISCUSS when the update is posted. Thanks! Alvaro. On January 21, 2021 at 10:59:41 AM, Greg Mirsky ([email protected]) wrote: Hi Alvaro, after the discussion with our AD and Chairs, we have prepared an update with a new Source IP Address TLV. The Source IP Address TLV is required in the BFD Discriminator attribute is the BFD Mode is set to P2MP value. Below is the updated text. - In Section 3.1.6: An optional Source IP Address TLV is defined in this document. The Source IP Address TLV MUST be used when the value of the BFD Mode field's value is P2MP BFD Session. For the Source IP Address TLV fields are set as follows: o The Type field is set to 1 Section 7.3. o The Length field is 4 for the IPv4 address family and 16 for the IPv6 address family. o The Value field contains the address associated with the MultipointHead of the P2MP BFD session. The BFD Discriminator attribute MUST be considered malformed if its length is smaller than 11 octets or if Optional TLVs are present, but not well-formed. If the attribute is deemed to be malformed, the UPDATE message SHALL be handled using the approach of Attribute Discard per [RFC7606]. - In Section 3.1.6.1 o MUST use the IP address included in the Source IP Address TLV of the BFD Discriminator attribute as the source IP address when transmitting BFD Control packets; - In section 3.1.6.2 the IP address in the Source IP Address TLV included the BFD Discriminator attribute in the x-PMSI A-D Route; Also, all updates resulting from our discussion are highlighted in the attached diff file. Please let me know if this update addresses your comment on the origin of the PE address used in the P2MP BFD session. I much appreciate your review, comments, and suggestions. Best regards, Greg On Wed, Dec 23, 2020 at 12:36 PM Alvaro Retana <[email protected]> wrote: > 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
