Re: [mpls] Opsdir last call review of draft-ietf-mpls-bfd-directed-27

[Greg Mirsky <[e-mail]>]

Hi Joe,
thank you for your thoughtful comments and suggestions. Please find my
notes below tagged by GIM>>. Also, attached is the new working version of
the draft.

Regards,
Greg

On Fri, Apr 12, 2024 at 7:18 PM Joe Clarke via Datatracker <[e-mail]>
wrote:

> Reviewer: Joe Clarke
> Review result: Has Nits
>
> I have been asked to review this document on behalf of the OPS
> directorate.
> While overall, I found the document readable and clear, I do have a few
> comments and a question, so I chose a state of Has Nits.  However, I feel
> it is
> mostly ready.  I also appreciate the Operational Considerations section
> and the
> additional MTU text suggested by Andrew.
>
> One comment I have is around terminology and abbreviations.  I know this
> is an
> mplswg document, but you did expand BFD and LSP.  I think it would be
> helpful
> to expand FEC and LSR, too.
>
GIM>> Added.

>
> The other comment I have is around use ingress and egress "BFD peer".  I
> like
> this terminology, but you have cases in Section 1 where you use ingress and
> egress BFD "system".  In Section 3.1, you mix in "egress LSR".

GIM>> Thank you for the suggestion. In most instances, it is a remote LSR
that is the actor processing MPLS echo request. Updated as you've
suggested. But on one occasion I changed to "egress BFD peer" as follows:
OLD TEXT:
   the egress LSR MUST
   transition to transmitting periodic BFD Control messages as defined
   in Section 7 [RFC5884].
NEW TEXT:
   the egress BFD peer
   MUST transition to transmitting periodic BFD Control messages as
   defined in Section 7 [RFC5884].

In Section 5,
> you mix in "ingress BFD node".  I would suggest consistent terminology.  I
> like
> peer and peer LSR also works for me.

GIM>> Found two occurences and applied update, as you suggested.

>
> On that topic, thank you for the example in Section 4.  I would just add
> that
> perhaps you label or describe node A as the ingress BFD peer [LSR] and H
> as the
> egress BFD peer [LSR].  It would help tie the figure to the rest of the
> text.
>
GIM>> Thank you for your consideration and the advice. As the text explains
operation with MPLS Echo Request messages to bootstrap controlled BFD
sessions, I've labeled nodes A and H as ingress and egress LSR peers
respectively. Now, the text is as follows:
   In the network presented in Figure 2, ingress LSR peer A monitors two
   tunnels to the egress LSR peer H: A-B-C-D-G-H and A-B-E-F-G-H.  To
   bootstrap a BFD session to monitor the first tunnel, the ingress LSR
   peer A MUST include a BFD Discriminator TLV with Discriminator value
   (e.g., foobar-1) and MAY include a BFD Reverse Path TLV that
   references H-G-D-C-B-A tunnel.  To bootstrap a BFD session to monitor
   the second tunnel, ingress LSR peer A, MUST include a BFD
   Discriminator TLV with a different Discriminator value (e.g., foobar-
   2) [RFC7726] and MAY include a BFD Reverse Path TLV that references
   H-G-F-E-B-A tunnel.


           C---------D
           |         |
   A-------B         G-----H
           |         |
           E---------F

                Figure 2: Use Case for BFD Reverse Path TLV

   If an operator needs egress LSR peer H to monitor a path to the
   ingress LSR peer A, e.g., H-G-D-C-B-A tunnel, then by looking up the
   list of known Reverse Paths, it MAY find and use the existing BFD
   session.

>
> Finally, my question.  In the Operational Consideration, what would (or
> should)
> happen to the underlying service while the LSP ping is processed in the
> case of
> reverse-path FEC failure?  Is there guidance to provide to maintain service
> while this new session might be established?
>
GIM>> That, in my opinion, is the formative question; thank you for that.
It is assumed that the operator controls the network to which the Reverse
PAth Control TLV is applied. If theat is the case, the failure of the
installed reverse path is a case of the network failure. The operator, I
assume that from the ingress BFD peer, is notified, and then can switch the
reverse path of the BFD session. I imagine, that there could be other
switchover policies, but I believe that it is essential that the ingress
BFD peer detects the network failure if the reverse path of the BFD session
fails. WDYT?