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

Rakesh Gandhi <rgandhi.ietf@gmail.com> Thu, 28 January 2021 01:30 UTC

Return-Path: <rgandhi.ietf@gmail.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143A63A0FEB; Wed, 27 Jan 2021 17:30:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFBzxIdZXC1n; Wed, 27 Jan 2021 17:30:55 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3880C3A1031; Wed, 27 Jan 2021 17:30:17 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id f2so4380694ljp.11; Wed, 27 Jan 2021 17:30:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P7le9nGzEnqBuuY3a2b7Ac4NrUw0ZfSxUpYu3lpIdS8=; b=U6mdEqaOYNAQ/XD6phIiDpIoJTjhl0hMME4Ihfsdbdyq7vIPtUr8WmPlhEtlbzZo+D ddJHJQajMBO61bXYijLrskuDUsyEugvPLGwAkj6ZcpmhY8QHuyuz/IEUTzasIZfE+rt5 clQq4CCDlX1pzNm2xjv9efeaFPydpcggU9PgDEncfB3j4a+FHQGUrDQ77SKRN6tsQCFL vFcmFE/EhTgFfqubq41CEd5XmMWlR9Sp6kLFXeic27/sTnue7Nq5Y8XytOv7PFqIxG45 q2zILXDjWzlnB8ts2/rgKYd4k/FqNbk7FxJFyPZBjCO0YTDieQqk87eF4VKVfDXy9TJh PRpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P7le9nGzEnqBuuY3a2b7Ac4NrUw0ZfSxUpYu3lpIdS8=; b=S/T892/cRQ5M17e2fu/sTj8B47iT4bHluvqllKsQH2iRwiafBieD/jbjGVecrUtMEd Rwrj8CLch0CoPee997Ge0FGchQ8wiQbYgLX+G0nIFWz9IrFZ00PXzDpSbCaCKydsAYTL xS5bFXkT4jeAGBLOHx+iDJZBOLDWEv7TYpDAB5pXLTqZbLqiEVkWMmQuMNXQy/6TtEN0 iL3rFdC4Liy6waFNoJPJQghjzrHrixGGFjVtahjCOq4OEN5ELPly8YnS75T2tYYoZNaw CKHHo62IoWrfg6cHsE+FB1UUmD/SEZziaSLBruq5JJftwkHD1q2a/urtX69ODeYULQp8 cXmQ==
X-Gm-Message-State: AOAM530HGFsZSZFQhuP91h28eqajc2JTOypou2Bq4UXzteDDrBpF4q2B dxcKBSQubWxkkmg5swtkeLPsrziyifKk9CeBXQ==
X-Google-Smtp-Source: ABdhPJwPZXTRsgJrzVGtlyem4mKJrA4EkjnMIV5Mpu2ZIlAKrmDcs/AAtHTsHXsC7p3hFbyo6ZIYULj2QOO6Xz0SpE4=
X-Received: by 2002:a2e:7114:: with SMTP id m20mr7162063ljc.296.1611797414989; Wed, 27 Jan 2021 17:30:14 -0800 (PST)
MIME-Version: 1.0
References: <161178976521.30445.7921080637059611565@ietfa.amsl.com>
In-Reply-To: <161178976521.30445.7921080637059611565@ietfa.amsl.com>
From: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Date: Wed, 27 Jan 2021 20:30:03 -0500
Message-ID: <CAMZsk6drYw_yNkMCZ_rS9bbProh76jfHJpjLjncsYzCBQBWB7Q@mail.gmail.com>
To: Al Morton <acmorton@att.com>
Cc: ops-dir@ietf.org, draft-ietf-pce-association-bidir.all@ietf.org, last-call@ietf.org, pce@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005ed33705b9ebd440"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/5oVTIW0lIGoks7S5iP57V3S2srQ>
Subject: Re: [Pce] Opsdir last call review of draft-ietf-pce-association-bidir-10
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jan 2021 01:30:58 -0000

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.



> [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
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>