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

[Greg Mirsky <[e-mail]>]

Hi Dhruv,
thank you for your helpful review and kind words. The new version of the
draft is now uploaded. The authors are ready for the next steps to move the
work further.

Regards,
Greg

On Fri, May 19, 2023 at 6:30 PM Dhruv Dhody <[e-mail]> wrote:

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