Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-mvpn-fast-failover-13: (with DISCUSS and COMMENT)

[Greg Mirsky <[e-mail]>]

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 <[e-mail]>
wrote:

> Thanks Greg!
>
> On January 21, 2021 at 3:10:29 PM, Greg Mirsky ([e-mail])
> 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 <[e-mail]>
> 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 ([e-mail])
>> 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 <[e-mail]>
>> 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.
>>>
>>