Re: [mpls] I-D Action: draft-ietf-mpls-bfd-directed-22.txt

[Greg Mirsky <[e-mail]>]

Hi Dhruv,
thank you for your comments and suggestions. Please find my notes below
tagged by GIM>>. Also, attached are the diff highlighting updates and the
new working version.

Regards,
Greg

On Tue, May 2, 2023 at 11:57 AM Dhruv Dhody <[e-mail]> wrote:

> Hi,
>
> Please find some comments on the I-D -
>
> ## Minor
>
> * Section 1
>
>     * IP/MPLS LSP reads a bit weird; Should this be only MPLS LSP instead
> of IP/MPLS?
>
GIM>> Thank you for pointing this out to me. I agree; it doesn't make
sense.  Accepted your proposed fix.

>
>
>     * Some text for experimental status should be added in terms of scope
> of the experiment, what are the next steps etc.
>
GIM>> The following text is proposed:
NEW TEXT:
   The LSP ping extension, described in this document, was developed and
   implemented resulting from the operational experiment.  The lessons
   learned from the operational experiment enabled the use between
   systems conforming to this specification.  More implementations are
   encouraged to understand better the operational impact of the
   mechanism described in the document.

>
>
> * Section 3.1
>
>     * LSP Ping [RFC 7110] uses the term Reply Path, is that usage
> different from Reverse Path in this I-D? It might also be a good idea to
> talk about RFC 7110 in the introduction. BTW is there any relationship
> between the two?  (I later saw you have some text in Section 5 but it lacks
> any context)
>
GIM>> LSP Ping is an example of the Echo Reply/Response mechanism. In BFD
Asynchronous mode, actors transmit BFD Control messages periodically and
independently of each other. Also, usually, one BFD system is referred to
as active because it initiates the BFD session. The other BFD system is
referred to as passive. Considering that, would you agree that a Reverse
Path (from the perspective of the active BFD peer) is an acceptable term
for BFD?

>
>     * For the Target FEC Stack sub-TLV we need references. Is the use of
> non-multicast clear for the reader, do we need to be more specific? Looking
> at the registry, is this the correct list ? Not all of them use the term
> multicast!
>
GIM>> Thank you for your thoughtful question. We attempt to establish
terminology equivalency in Section 3.1 as follows:
   Multicast Target FEC
   Stack sub-TLVs, i.e., p2mp and mp2mp, SHOULD NOT be included in
   Reverse Path field.
Do you think that is clear?

>
>
>         * RSVP P2MP IPv4 Session
>
>         * RSVP P2MP IPv6 Session
>
>         * Multicast P2MP LDP FEC Stack
>
>         * Multicast MP2MP LDP FEC Stack
>
>         * P2MP Pseudowire sub-TLV
>
>         * P2MP Policy MPLS Candidate Path
>
>     * Suggest to use MUST NOT here -> "Multicast Target FEC Stack sub-TLVs
> SHOULD NOT be included but .." because you further state that on receiving
> it MUST send echo reply as error!
>
GIM>> Agree with your suggested update.

>
>
>     * In the text "For example, if the egress LSR cannot find the path
> specified in the Reverse Path TLV, it MAY establish the BFD session over an
> IP network, as defined in [RFC5884]."; it is inappropriate to use MAY for
> an example of a configuration option
>
GIM>> Would the following update address your concern:
OLD TEXT:
   For example, if the egress LSR cannot find
   the path specified in the Reverse Path TLV, it MAY establish the BFD
   session over an IP network, as defined in [RFC5884].
NEW TEXT:
   For example, optionally, if the egress LSR
   cannot find the path specified in the Reverse Path TLV, it will
   establish the BFD session over an IP network, as defined in
   [RFC5884].

>
> * Section 4
>
>     * Here as well as section 2 highlights co-routed cases only. But one
> can use any reverse path including of a different FEC type. Do we have a
> usecase to highlight the need to support different reverse paths? If not
> the logical question would be - should one limit the usage?
>
GIM>> In the course of discussions with ITU, two types of bi-directional
LSP were defined - associated and co-routed. Of course, associated
bi-directional LSP is also a valid use case for the proposed mechanism.
Additionally, I imagine that the same mechanism can be used to monitor with
a single BFD session two unidirectional LSPs between a pair of LERs.
Co-routed bi-directional LSP intended as an example only.

>
>
> * Section 6.2
>
>     * The range 192-247 is RFC required and thus you should not say the
> allocation is via "Standards Action"! This I-D is also experimental.
>
> * Section 7 should refer to and follow the template of RFC 7942 including
> the boilerplate text!
>
GIM>> Thank you for pointing me out to RFC 7942. Updated Section 7. Please
let me know if it is according to the RFC 7942 recommendations.

>
>
> ## Nits
>
> * Abstract
>
>     * s/extension to MPLS LSP echo request/extension to the MPLS LSP echo
> request/
>
>     * s/system request that the remote BFD peer transmits/system requests
> that the remote BFD peer transmits/
>
>     * Expand LSP
>
GIM>> Done, done, and done.

>
> * Section 3.2
>
>     * I suggest to not use MUST in this section. It has already been
> stated in Section 3.1, this section works best as a listing of return codes
>
GIM>> I agree. Please let me know if the updated text is acceptable.

>
> * Section 6.1
>
>     * s/"TLVs and sub-TLVs" sub-registry/"TLVs" sub-registry/
>
GIM>> Done.

>
> Thanks!
> Dhruv
>
> On Mon, Mar 27, 2023 at 2:32 PM <[e-mail]> wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This Internet-Draft is a work item of the Multiprotocol Label
>> Switching (MPLS) WG of the IETF.
>>
>>    Title           : Bidirectional Forwarding Detection (BFD) Directed
>> Return Path for MPLS Label Switched Paths (LSPs)
>>    Authors         : Greg Mirsky
>>                      Jeff  Tantsura
>>                      Ilya Varlashkin
>>                      Mach(Guoyi) Chen
>>    Filename        : draft-ietf-mpls-bfd-directed-22.txt
>>    Pages           : 9
>>    Date            : 2023-03-27
>>
>> Abstract:
>>    Bidirectional Forwarding Detection (BFD) is expected to be able to
>>    monitor a wide variety of encapsulations of paths between systems.
>>    When a BFD session monitors an explicitly routed unidirectional path
>>    there may be a need to direct egress BFD peer to use a specific path
>>    for the reverse direction of the BFD session.  This document
>>    describes an extension to MPLS LSP echo request that allows a BFD
>>    system request that the remote BFD peer transmits BFD control packets
>>    over the specified LSP.
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mpls-bfd-directed/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-mpls-bfd-directed-22.html
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-bfd-directed-22
>>
>> Internet-Drafts are also available by rsync at rsync.ietf.org:
>> :internet-drafts
>>
>>
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>