Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

"Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@nokia.com> Tue, 21 January 2020 18:36 UTC

Return-Path: <andrew.stone@nokia.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 F1126120047 for <pce@ietfa.amsl.com>; Tue, 21 Jan 2020 10:36:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 bGSlr7pAKe94 for <pce@ietfa.amsl.com>; Tue, 21 Jan 2020 10:36:09 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60121.outbound.protection.outlook.com [40.107.6.121]) (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 AD4E212003F for <pce@ietf.org>; Tue, 21 Jan 2020 10:36:08 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IFWz8pBRShpQ76n+hxfekVPB3WS0eXBYX5zw4KSXFAIC78HdxWm1hWF0iFB6omTTlu3WBVeEKggo/7WWbCYSYo0QnCN7dF783jyON09o/clc9Cq0GnMHG3xrEfTGB70UDZKUzzYkbyLxgf9pdXQz+VZsVYJit5BtbrvNQueSnoiJ38Y2AtZWCcpow+CdOQAUQ4bmqr7GdcelSu+3JgfXWBpIFIFXv0c53rfHQe+0lnNFtsfENPC+rvOJTJcJq6xl4JwBpo15frB1pgi6LqYVhhCDirE2xtnYHRIj1rV2QYZP7Zk2+N2LBT1Db+BQma8Sat7erHDyWDBqmJJbI6ijnQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ykb5ZZ5+Q6OuC9KY/XDMEU9AoYcHo3MAUlT2m1zNonI=; b=SvmLOy2JkJzLZ7SIHg+e3u9YoqsuKN7Za6HH/ALXvdKA8sJH3oIXie8mcRIA9ZPk6yDabuXJLWr6eoZEFkGQJCmk7QHtlOHuQBYgFac6Z4Qw07m3Ev/LYKXY7Joq5jP4fmJa+67SyhPnjri4dIy/GcBX26sDPSdUnc1pM9cn+nI/bngZADOVPbGbHD9oOHXCcEwgAbWrPCIFt5LQErHmw2QjYZVOzPH0+hu5R2pElWQI4TibYYVo3ZkOoNp/1zBMCujI5sl8oy27aSIWEjpatVjysGCy/eR1mDuTrRMOqzhLZX/Mdl3FGbdWLBwjskw5FDFXX3/VDzxuCT5xFZYtaw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ykb5ZZ5+Q6OuC9KY/XDMEU9AoYcHo3MAUlT2m1zNonI=; b=MY4BHlrlBCdR002dHIR7k33Wjg4j+iJ4337NKavpAMLPEUT0WJs5uzDkS9JmnQgAmI5+ngmjVrv8/unTfM9wL89CZsKkv0rzC5hfrMJuZzXro0fhb25aZz1sAA1x26f68MweKyAHfqZcTZN8/qbi1rOTr6ap/j14N+tDu4c+0gQ=
Received: from AM0PR0702MB3619.eurprd07.prod.outlook.com (52.133.46.160) by AM0PR0702MB3715.eurprd07.prod.outlook.com (52.133.46.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.14; Tue, 21 Jan 2020 18:36:06 +0000
Received: from AM0PR0702MB3619.eurprd07.prod.outlook.com ([fe80::4139:54b9:238:669c]) by AM0PR0702MB3619.eurprd07.prod.outlook.com ([fe80::4139:54b9:238:669c%7]) with mapi id 15.20.2665.015; Tue, 21 Jan 2020 18:36:06 +0000
From: "Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@nokia.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>
CC: Rakesh Gandhi <rgandhi.ietf@gmail.com>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?
Thread-Index: AQHVzR6uiqJrBBVhq0SzaEKl30U2oKfvvJyUgAPq14D//7q+AIABhvmAgAA8DwA=
Date: Tue, 21 Jan 2020 18:36:06 +0000
Message-ID: <3587FF7A-97B3-43A4-B6B9-62197935B91F@nokia.com>
References: <e69cdba1-69c2-583c-3eaf-f14265a45d74@orange.com> <AM0PR0702MB361983EFB33D2C615673225591300@AM0PR0702MB3619.eurprd07.prod.outlook.com> <CAMZsk6cEMDgxSBDssvp1YZeZrt_8q6iYhr-C6yu40n6w=fKrVg@mail.gmail.com> <4EA592A4-4749-4743-8255-BFE7D296A61C@nokia.com> <CAB75xn5vCmD5DV0rCz2DaE0310O8UCkh-=0veD7yBXJB3npApw@mail.gmail.com>
In-Reply-To: <CAB75xn5vCmD5DV0rCz2DaE0310O8UCkh-=0veD7yBXJB3npApw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.21.0.200113
authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.stone@nokia.com;
x-originating-ip: [135.245.20.27]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ecad6c8a-6a80-4a47-c97b-08d79ea0c6fe
x-ms-traffictypediagnostic: AM0PR0702MB3715:
x-microsoft-antispam-prvs: <AM0PR0702MB37155D1FDEAA62652C113E98910D0@AM0PR0702MB3715.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0289B6431E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(376002)(136003)(346002)(39860400002)(366004)(199004)(189003)(478600001)(33656002)(5660300002)(186003)(2616005)(26005)(81156014)(2906002)(81166006)(8676002)(8936002)(54906003)(6512007)(316002)(6506007)(6486002)(64756008)(66446008)(76116006)(91956017)(86362001)(66556008)(71200400001)(6916009)(66946007)(66476007)(4326008)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0702MB3715; H:AM0PR0702MB3619.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /yMy83HWUd1wYxv2B8q7Nuq95FMKXgeZ36wY2XmSP1VYqKA3Hc8E4yeQ9+eN042SoE3d5amuvm0RyLBZh8oo75MCUR+SzATXjuV0yq6WVlV1arkU7KO6UFBAc59ySF5x8XqZOWx73oOWIBQayG4zZmHWDk9JUzoRb0O9CxJbSu5NRSCIH0H7kWNMV0DgAjuPJFcvtqbIDrztjS/EWj+hvKbIh/qTXkRYBRy2DDA9yjQD3Taa7cR7U2AchejZILt/qTePzOGaL6Y6lkHzIrlBBFpftAbC2fU5EJ9AKpqFx40Y5jCVTSVowKQR+BVMEP73OxNe7hnbSj6lxlt2RJaT8XsE8G2sG3Sq1XVc/xeKPYvTek6/5oQD+MYSh05oC8NRmig0te7MVGoU5Xhrr9PPCioUZOfv3ItjSwfJI8ANmzzqBeOiIpNlwLcyk7sHhXU6
x-ms-exchange-antispam-messagedata: 1h7ZAAjAWJSWMiSGuem+xv6BjmpUqTfMffHNkdphcfxV4Z/EQKSd9YCj5SYOCCl1hfPZB8+zZFoaQK+LRtRTiCkfxJUKseR4cMj8rWuK1UnUUkeV1ITzZ6PK/2CBo/vVj/ugHNirRkOC02qislejWg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <E43BF5092A83604EAA7D73A57A9321FE@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ecad6c8a-6a80-4a47-c97b-08d79ea0c6fe
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 18:36:06.5237 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jtDIaNeF0pMN8zUoUQV09zkMjBiPLrdxQvjldRFKg+ja8mGgf21OWxnkITSXZ9/IeukihWD5g4Kc0tm8vZ8aRw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3715
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/LnTR_PfHlNG4BRyKLvkQuGdAmbU>
Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?
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: Tue, 21 Jan 2020 18:36:15 -0000

Hi Dhruv,

Thanks for the reply and feedback. 

Could an implementation of PCE not simply just return error during that situation? In diversity if too many LSPs grouped together and PCE computationally can't support it, it returns a PCERR. So I would reason that if bidirectionally associated and notify PCCs is necessary, but was configured between SR and RSVP, that's also an error due to the (current) unsupported feature set. I see this as trying to protect against day-0 misconfig by changing the wire encoding within the protocol (which I'm not necessarily against..). While I have doubt if it's a valid use case or requirement in a production deployment, and it may have been acknowledged before, but this essentially blocks associating SR LSP with RSVP LSP bidirectionally for PCE to compute.  

Since the overall workflow doesn't change by this new type def, and if SR<->RSVP associated is not reasonable requirement, and If consensus has already been reached on this, and implementation already exist, I'm okay with parking this topic. 

Still hoping for feedback regarding my comments on section 5. I see that as being more significant, since it influences the workflow and at the moment I don't see the dependency on draft-li-pce-controlled-id-space as necessary to achieve notifying PCCs of reverse paths. 

Thanks again,
Andrew

 
On 2020-01-21, 5:01 AM, "Dhruv Dhody" <dhruv.ietf@gmail.com> wrote:

    Hi Andrew,
    
    Speaking as a WG contributor and snipping to -
    
    
    > For bidirectional associating two LSPs, does PCC/PCE need an additional way to distinguish whether it's an SR or an RSVP bidirectional association? Would that not be implicit based on the path setup type of the LSPs which have been associated together? In other words, do we actually need double-sided bidirectional SR association group object defined? draft-li-pce-sr-bidir-path-06 seems to imply the behavior is basically the same as MPLS-TE (minus the RSVP signalling of course) and the object encoding is the same, so does yet-another object need to be defined? From a PCEP message encoding p.o.v within an association object structure, are 2 SR LSPs that different than associating 2 RSVP LSPs?
    >
    >
    >
    > <RG> Main difference is that in case of RSVP-TE, the egress node learns the reverse LSP via RSVP signaling whereas in case of SR, the egress node learns the reverse LSP via PCE.
    >
    >
    >
    > <Andrew> Yes, I realize that, however the association structure is about informing PCE to associate two LSPs together, is it not? It’s not related to how 2 LSPs learn each opposite reverse path. To be specific, my comment is regarding section 3.1. To instruct PCE “make these 2 bidirectional” is a separate task than how the LSPs learn of each other’s reverse LSP and path in my opinion. So to inform PCE “these 2 LSPs are bidirectional, make them so” is the same instruction irrelevant of how each LSP learns of each others path. For SR, yes there is the added process where PCE may need to tell the PCC the opposite path, but that decision is a behaviour post-association being provided, which can be determined as necessary by the LSP path setup type of the associated LSPs. So if the goal of to instruct PCE “these 2 LSPs are bidirectional”, that instruction is common between LSPs whether they are RSVP or SR. Essentially defining 'Double-sided Bidirectional SR Path Association Group' is not required (unless there’s something else in that object we foresee being specific to SR in the future).
    >
    
    I remember this being discussed in the mailing list, and the decision
    was that there are enough of a difference between the processing of
    double-sided bi-directional for RSVP-TE and SR paths to have different
    association types for the ease of implementation. Implementers were
    also worried that the PST of the first LSP that joins the associations
    would decide the next action and could lead to issues. In case one
    tried to add SR and RSVP-TE path in one association, where one peer
    may add SR first and reject RSVP-TE and other pcep peer may add
    RSVP-TE first and reject SR and there could be some mismatch. This was
    done mainly for the ease of implementations.
    
    Thanks!
    Dhruv