Hi Alvaro, I much appreciate your quick response and the clarifying questions. Please find my answers in-lined under GIM>> tag. I will upload the document with the additional updates from my answers.
Regards, Greg On Thu, Jan 21, 2021 at 8:51 AM Alvaro Retana <[email protected]> wrote: > 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? > GIM>> I've added text to the description of the Length field: o The Length field is 4 for the IPv4 address family and 16 for the IPv6 address family. The TLV is considered malformed if the field is set to any other value. > 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. > GIM>> You're right, making it explicit with: The BFD Discriminator attribute that does not include the Source IP Address TLV MUST be handled according to the "attribute discard" approach, as defined in [RFC7606]. > > > 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
