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

"MORTON, ALFRED C (AL)" <acm@research.att.com> Thu, 28 January 2021 18:23 UTC

Return-Path: <acm@research.att.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 790923A1034; Thu, 28 Jan 2021 10:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level:
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 o5QeeK1oFInC; Thu, 28 Jan 2021 10:23:37 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CAB3A0CA2; Thu, 28 Jan 2021 10:23:36 -0800 (PST)
Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 10SI5S62038528; Thu, 28 Jan 2021 13:23:36 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049287.ppops.net-00191d01. with ESMTP id 36b6pfcx1f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jan 2021 13:23:35 -0500
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 10SINYAk031628; Thu, 28 Jan 2021 12:23:35 -0600
Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [135.46.181.149]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 10SINSqY031276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Jan 2021 12:23:28 -0600
Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [127.0.0.1]) by zlp30499.vci.att.com (Service) with ESMTP id 40C0C401B721; Thu, 28 Jan 2021 18:23:28 +0000 (GMT)
Received: from clph811.sldc.sbc.com (unknown [135.41.107.12]) by zlp30499.vci.att.com (Service) with ESMTP id 15DFF401B720; Thu, 28 Jan 2021 18:23:28 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 10SINRYZ011586; Thu, 28 Jan 2021 12:23:27 -0600
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 10SINLID011021; Thu, 28 Jan 2021 12:23:21 -0600
Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.86]) by mail-blue.research.att.com (Postfix) with ESMTP id B7B7C10A1A92; Thu, 28 Jan 2021 13:23:20 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas1.research.att.com ([fe80::e881:676b:51b6:905d%12]) with mapi id 14.03.0487.000; Thu, 28 Jan 2021 13:23:31 -0500
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: Rakesh Gandhi <rgandhi.ietf@gmail.com>
CC: "ops-dir@ietf.org" <ops-dir@ietf.org>, "draft-ietf-pce-association-bidir.all@ietf.org" <draft-ietf-pce-association-bidir.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Pce] Opsdir last call review of draft-ietf-pce-association-bidir-10
Thread-Index: AQHW9RUvd60TFqAWVESNozWagatjZ6o9TqeQ
Date: Thu, 28 Jan 2021 18:23:31 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF0147691277@njmtexg5.research.att.com>
References: <161178976521.30445.7921080637059611565@ietfa.amsl.com> <CAMZsk6drYw_yNkMCZ_rS9bbProh76jfHJpjLjncsYzCBQBWB7Q@mail.gmail.com>
In-Reply-To: <CAMZsk6drYw_yNkMCZ_rS9bbProh76jfHJpjLjncsYzCBQBWB7Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [24.148.42.167]
Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF0147691277njmtexg5resea_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-28_12:2021-01-28, 2021-01-28 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 mlxscore=0 priorityscore=1501 mlxlogscore=999 bulkscore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 clxscore=1011 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101280087
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/NbZnP1QXZ-EOSII1zWXHrn7jhZw>
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 18:23:40 -0000

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<mailto: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.

?

[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<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/pce__;!!BhdT!1WR3RmPG7BhQ_nNCb0hbDVOQZhEzQHMzuBWP0hqrdiQyj1w4AbxdWTqiWfBB$>