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 <[email protected]> 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. > [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. -=-=-=-=-=-=-=- > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
