Re: [Pce] Opsdir last call review of draft-ietf-pce-association-bidir-10

Hi Al,
Thanks for the comments.
Please see inline for one comment with <RG2>...

On Thu, Jan 28, 2021 at 1:23 PM MORTON, ALFRED C (AL) <acm@research.att.com>
wrote:

> Hi Rakesh,
>
>
>
> Thanks for adding the new reference to RFC7551 in the requirement we’re
> discussing.
>
> Please see below for replies *[acm]* on this and other comments.
>
>
>
> Al
>
>
>
> *From:* Rakesh Gandhi [mailto:rgandhi.ietf@gmail.com]
> *Sent:* Wednesday, January 27, 2021 8:30 PM
> *To:* MORTON, ALFRED C (AL) <acm@research.att.com>
> *Cc:* ops-dir@ietf.org; draft-ietf-pce-association-bidir.all@ietf.org;
> last-call@ietf.org; pce@ietf.org
> *Subject:* Re: [Pce] Opsdir last call review of
> draft-ietf-pce-association-bidir-10
>
>
>
> Thank you Al for the review.
>
> Please see replies inline with <RG>...
>
>
>
> On Wed, Jan 27, 2021 at 6:23 PM Al Morton via Datatracker <
> noreply@ietf.org> wrote:
>
> Reviewer: Al Morton
> Review result: Has Nits
>
> This document defines PCEP extensions for grouping two unidirectional
> MPLS-TE LSPs into an Associated Bidirectional LSP.
> Specifically, this document defines two new
> Association Types, "Single-sided Bidirectional LSP Association" and
> "Double-sided Bidirectional LSP Association", as well as
> "Bidirectional LSP Association Group TLV" to carry additional
> information for the association.
>
> Comments:
>
> Thank you for including Section 8, Manageability Considerations.
>
> I'm seeking clarification for the following requirement (although it may be
> completely clear to those who are knee-deep in this terminology):
>
> Section 4.1
> ...
>    o  The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs
>       of the Single-sided Bidirectional LSP Association on the
>       originating endpoint node MUST be the same, albeit with reverse
>       endpoint nodes.
>
> as currently written, the requirement says that
> two preceding nouns MUST be the same.
>
> But is it:
> "The Tunnel *containing the* forward and reverse LSPs..."?
> Or is it,
> "The *Tunnels associated with the* forward and reverse LSPs ..." ?
> Or something else?
>
>
>
> <RG> How about following text?
>
> The Tunnel (as defined in [RFC3209]) containing the forward and reverse
> LSPs of the Single-sided Bidirectional LSP Association on the originating
> node MUST be the same [RFC7551], both LSPs albeit with with reverse
> endpoint nodes.
>
> *[acm] *
>
> *Some relevant text from 7551 seems to be:*
>
> *3.1.1* <https://tools.ietf.org/html/rfc7551#section-3.1.1>*.
> Single-Sided Provisioning*
>
>    For the single-sided provisioning, the Traffic Engineering (TE)
>
>    tunnel is configured only on one endpoint.  An LSP for this tunnel is
>
>    initiated by the initiating endpoint with the (Extended) ASSOCIATION
>
>    and REVERSE_LSP Objects inserted in the Path message.  The other
>
>    endpoint then creates the corresponding reverse TE tunnel and signals
>
>    the reverse LSP in response using information from the REVERSE_LSP
>
>    Object and other objects present in the received Path message.
>
>
>
> *So would it also be correct to say:*
>
>
>
> The forward and reverse tunnels (as defined in [RFC3209]) containing the
> forward and reverse LSPs of the Single-sided Bidirectional LSP Association
> on the originating node MUST be the same bi-directional tunnel (as
> described in section 3.1.1 of  [RFC7551]), albeit both LSPs have reversed
> endpoint nodes.
>
>
>
> *OR,*
>
> The Tunnel (as defined in [RFC3209]) containing the forward and reverse
> LSPs of the Single-sided Bidirectional LSP Association on the originating
> node MUST be have the same LSP parameters (as described in section 3.1.1 of
>  [RFC7551]), albeit both LSPs have reversed endpoint nodes.
>
>
>
<RG2> This looks good.

Thanks,
Rakesh

*?*
>
>
>
> [RFC3209] simple definitions are (both seem to be unidirectional):
>    LSP Tunnel
>       An LSP which is used to tunnel below normal IP routing and/or
>       filtering mechanisms.
>    Traffic Engineered Tunnel (TE Tunnel)
>       A set of one or more LSP Tunnels which carries a traffic trunk.
>
> -=-=-=-=-=-=-=-
> Another request for clarification:
> 5.6.  State Synchronization
>    During state synchronization, a PCC MUST report all the existing
>    Bidirectional LSP Associations to the Stateful PCE as per [RFC8697].
>    After the state synchronization, the PCE MUST remove all stale
>    Bidirectional LSP Associations.
>
> What is the procedure to determine a stale association, a time-out
> or simply the absence of a previously association in a report?
> Is there a passage covering stale determination in 8697, another
> reference, or a passage in the current memo that I missed?
>
>
>
> <RG> The absence of the previous association in a report. I could not find
> any relevant text in the RFC 8697. How about following?
>
> 5.6.  State Synchronization
>
>    During state synchronization, a PCC MUST report all the existing
>    Bidirectional LSP Associations to the Stateful PCE as per [RFC8697].
>    After the state synchronization, the PCE MUST remove all previous
>    Bidirectional LSP Associations absent in the report.
>
> *[acm] *
>
> *thanks, that helps.*
>
>
>
>
>
> -=-=-=-=-=-=-=-
>
> Editorial:
> 4.2.  Bidirectional LSP Association Group TLV
>
>    The "Bidirectional LSP Association Group TLV" an OPTIONAL TLV for use
> s/an/is an/
>
>
>
> <RG> Ack.
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
>
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/pce__;!!BhdT!1WR3RmPG7BhQ_nNCb0hbDVOQZhEzQHMzuBWP0hqrdiQyj1w4AbxdWTqiWfBB$>
>
>