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

[Dhruv Dhody <[e-mail]>]

Hi Greg,

Sorry for the late reply! I did a quick browse! Looks great!

Thanks!
Dhruv

On Fri, May 12, 2023 at 10:42 AM Greg Mirsky <[e-mail]> wrote:

> 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
>>>
>>