Thank you for your comments, suggestions, and discussion. It all helped to make the document better.
Best regards, Greg On Thu, Jan 21, 2021 at 12:40 PM Alvaro Retana <aretana.i...@gmail.com> wrote: > Thanks Greg! > > On January 21, 2021 at 3:10:29 PM, Greg Mirsky (gregimir...@gmail.com) > wrote: > > 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 <aretana.i...@gmail.com> > 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 (gregimir...@gmail.com) >> 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 <aretana.i...@gmail.com> >> 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
