Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Mon, 29 June 2020 21:13 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1628A3A0D30; Mon, 29 Jun 2020 14:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=J/qq2L2E; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0A4fJtN9
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 3AkHtnOXtKVJ; Mon, 29 Jun 2020 14:13:19 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ECBE3A08CD; Mon, 29 Jun 2020 14:13:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25264; q=dns/txt; s=iport; t=1593465199; x=1594674799; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=C0SLF/E1d70CngwsG8AsqDBLfUGAGnyMCwIS2xdcJ+4=; b=J/qq2L2EQM8CUYbMejq5w2vbZG3XSkldLLo6qDz0868GKRdZLjp6LCRU elun2ItjFzzj/2bxrzpbWmVgxsE6ZCw1luIo4M0UYZMonJ9ZeHXgdQtDB B1ly5u8eDDHruuEaZQ2PfwhCYRLbYj2VOvWqhPj0VMx58jrqbmRfLPqqY 8=;
IronPort-PHdr: 9a23:wb9fCRGp+PBXpohB6zOyQZ1GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e401QebQYLd+rRAirmev6PhXDkG5pCM+DAHfYdXXhAIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtJH8DvIVnT8TW+6DcIEUD5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOAACuWPpe/5hdJa1gGgEBAQEBAQEBAQEDAQEBARIBAQEBAgIBAQEBgXcEAQEBAQsBgSIvUQdvWC8shDGDRgONTIoBjliBLoEkA1ULAQEBDAEBGAEKCgIEAQGERwIXghMCJDUIDgIDAQELAQEFAQEBAgEGBG2FWwyFbgEBAQEDAQEQEQoTAQEpAwsBDwIBCBEEAQEoAwICAh8GCxQJCAIEAQ0FCBqDBYF+TQMuAQ6iagKBOYhhdoEygwEBAQWFOQ0Lgg4DBoE4AYJmhXyEAxqBQT+BVIIfLj6BBAGBFUIBAQKBXxUWCYJgM4Itjn6DNoZBmzpNCoJclE6FDoJziSuQWoIckU6McZFkAgQCBAUCDgEBBYFUATcpgS1wFTuCaVAXAg2OHQwXg06DRoFOhUJ0AgEBMwIGAQcBAQMJfJAGAQE
X-IronPort-AV: E=Sophos;i="5.75,295,1589241600"; d="scan'208,217";a="522123205"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jun 2020 21:13:18 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 05TLDIbP010334 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Jun 2020 21:13:18 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 29 Jun 2020 16:13:18 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 29 Jun 2020 16:13:17 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 29 Jun 2020 16:13:17 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U9vX0t11KCQpcrX3uYv+LwdAw3lU3Is8IO2wSoPNiss8L3YBK0tkglZJx61oco//JxdFuqumL8HgjpLIkD++GXH3H62AtdZRIoIc1WDf3YAjzW05wzClDeUS06U7+LMG1x9h5+O2oJiHuv1Zl0/WpFLoxNIf4JXKLzh+7aN3lcgzo2kq64/18l7hoxZQxwurLDmMJI2IsyDxh+iz11WlHksZF3+xcTkZQbPnr1vmaTkvMPmAXbujnQjWxzdCWZ3Lzp0xPbiM9AsEz07Z8Xb6Y3xUQ5pkO6nubRHp2XFrP4hCxo+AjPSv5AL9jMTTEExDJp8ldyR0MPzrCYhyc74Uhg==
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=C0SLF/E1d70CngwsG8AsqDBLfUGAGnyMCwIS2xdcJ+4=; b=cxXJftlPpTeggzg4yKO0Tm+4ll6mi3ILMnl/gyAaVaoNR9SORQf5YRhYkHPrjp/ijjTd3yzSA6XEkZZwYUJwSIDjesEo3uxAVmibCjqQO942cPginCdg6J2g5h2Jtr+gZnr7FsFhpkcWkCWSTgVGOu5xoYG0vZpQfwVP0EfCGZfVPVXcA08Jody3Js+gllvdqiHOr2HMug+P8NT0Dpjh39pPcmDP899aBc7wz46JYRIru6tZJwODy3WF9Wrlwm8+DFkYCuNM848n0vJKzAgZsgOuESbpWbDa9s9UqqS6gCowX1rmeLnMNJKhpAadv89IK3lS5hjk9pxgzUixUsX/dQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C0SLF/E1d70CngwsG8AsqDBLfUGAGnyMCwIS2xdcJ+4=; b=0A4fJtN9nz9V7RkGDFBr6e/kyOUL6qWkT/4Eny9+NjL5H4QHOC3qTZUprVMLc5USJaAR1uUikZDfBA/dEJg69ohpjlb7tOHBnt43mPSXAUtWrxh6kml6S9perqeo7nzqtOJ9N9HPjixwibgXbkyqwaXc+Jo4z3IuTA0p1jeZ81Q=
Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by BY5PR11MB4069.namprd11.prod.outlook.com (2603:10b6:a03:191::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20; Mon, 29 Jun 2020 21:13:16 +0000
Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::744b:761f:b385:f1e2]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::744b:761f:b385:f1e2%7]) with mapi id 15.20.3131.027; Mon, 29 Jun 2020 21:13:16 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "tony.li@tony.li" <tony.li@tony.li>, Hannes Gredler <hannes@gredler.at>
CC: "draft-li-lsr-isis-area-proxy.authors@ietf.org" <draft-li-lsr-isis-area-proxy.authors@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy
Thread-Index: AdZHOuOSJsSZJI/1RpqA6MX1gMmczwACEYAAAAQI3yAAA1bPAAAL12DQABb/a4AAyykTAAACsEmAAMrS8wAAAl7jwA==
Date: Mon, 29 Jun 2020 21:13:16 +0000
Message-ID: <BY5PR11MB4337679D71209F283F763E4FC16E0@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <BY5PR11MB4337892CA6ADFD4F2E9B653FC1990@BY5PR11MB4337.namprd11.prod.outlook.com> <EB07BFF9-B4AF-41BE-94F0-25E229FA25FD@tony.li> <BY5PR11MB4337E58E8B775A7086281C21C1990@BY5PR11MB4337.namprd11.prod.outlook.com> <29A0CD92-1D33-4B06-B0CF-D17BE89A9B60@tony.li> <BY5PR11MB4337A5745218D4C36D45ACDCC1960@BY5PR11MB4337.namprd11.prod.outlook.com> <3276AA3E-F540-41B6-A4DC-4FCD1CD57EFF@tony.li> <02873225-A2F2-4017-913B-742929C668B7@gredler.at> <40DD6A60-D2D6-4C2F-A1B3-E096030749E2@tony.li> <D700056F-2CDD-4595-9ABE-6ECE4F556331@tony.li>
In-Reply-To: <D700056F-2CDD-4595-9ABE-6ECE4F556331@tony.li>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: tony.li; dkim=none (message not signed) header.d=none;tony.li; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2602:306:36ca:6640:9464:a7c3:f753:fa97]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4d859e1e-ca71-4534-9b88-08d81c713dbf
x-ms-traffictypediagnostic: BY5PR11MB4069:
x-microsoft-antispam-prvs: <BY5PR11MB40693FAD7C442F6EDB6D1A88C16E0@BY5PR11MB4069.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 044968D9E1
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bD4tu21orYaSCzV1e7trGchunpq5A6NJPQVs06vCSqu1plbCSJ4QjzZYUKVOo+4u+jdjCwJ6HrUzJ24hUa1K4b2Ycc7qDxhJLbKt9OF2o9F5W3HZeiJ5D13+fMz96evTseEL9pjtWcDQKwG+hIkZxrVvz3ev61xWbTOlJKuRjXsv6yV/z2x8wbozDRxo6XarX3NxK8Jd4qzHFB9K49vDJ039cjVTRYklyoxafPby7/Nw9hS3W+YhsvKL1DkN9cwwSwoNeRSjakXooTDABeQCQi4+ODbsgUlqmzmkj+dMZXPo4Wgfdi5h/OMMXZ0iRqe0I6ggQqoslAMsa71+fBIc+V8Scy7iAK0oHxVHMviZGTcWVusl2+wFIVY3yfLC5A/JgdVGJMCk4UTv5KTLnbL3Ow==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(136003)(396003)(376002)(346002)(5660300002)(966005)(316002)(2906002)(478600001)(53546011)(6506007)(52536014)(66574015)(4326008)(86362001)(54906003)(110136005)(64756008)(66446008)(9686003)(33656002)(7696005)(55016002)(83380400001)(8676002)(186003)(66476007)(66946007)(76116006)(166002)(66556008)(8936002)(71200400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: +4ko86Vz4P/4t0bHg9O2YGi267/WaTZMDq4JqgRQhLSCvebcLbwiVC4RRiOTq5Qc+XtWCA5cgDD8IxktNxDRgC0SUlGPn5C/OPHXtNjHm6ei9akmkVmolZvYY1DITDCS45JFCnKSrgGYxMOJx95wHc+ZuZ5XdLcH7v3ACeNes54XXJmZF/dX0OU2s66ujYdltgP816def5wfv/B4VjPmH2IOHHQ4JXxuvqp7lnVuM3vgtYfyPdY8FIaQRhk1sQdb6ONHk65UatRb50YQgCGUS4HRTBhQkceA25GTmx+Rz1Dw7cnL+vvqXTXYr6pwwadtzfAoWHUeffAJe4Yb5FJV8npUP6x9FPlwvsSKMBF6XzXVY06CEwZoTrR5j98t+b6gxOlJ2zF1IN6ltXpD89lNu4HNBsMHW8XcCBykEbHb7qwISKZXHa9NpG0smsRAVLSWleoR9qsqQr1DxItl3jUZvXNG+XEH1jzqMPc8JRpedc07Xup9QVHXZzuEdN8UQU7Q4IXXbDy3+wF4s6N/TzgldDWTO2R+T/rTJT3O9RPkYQZ3g6IA1E+khYdL6sAm9yH/
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY5PR11MB4337679D71209F283F763E4FC16E0BY5PR11MB4337namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4d859e1e-ca71-4534-9b88-08d81c713dbf
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 21:13:16.3955 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pE4YNCebKI3RfnqT/imhpDow0f5q/DtxdosxnZvHp2TISsOJuXYiyUz7VXe6jcelzSwdPauDmnV1Zf4SiYNtjA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4069
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/aJoMSPcdXZpm3vGzcJ-14Olqpno>
Subject: Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2020 21:13:22 -0000

Tony –

OLD:
1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Inside Node TLV - Top level TLV

3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID

4)Area Segment SID - Top Level TLV

NEW: (Please check my interpretation)

1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID
   Sub-TLV Inside Node ???

3)Area Segment SID - Top Level TLV

Am I correct so far??

If so, a couple more comments/suggestions:

a)Could the Area Proxy TLV become a bit more generic and allow advertisement of the capability (implied by presence of the TLV)?
If  so, the Router Capability sub-TLV could go away.

b)If the Area Segment SID is (as you suggest) a generic thing not specific to Area Proxy, then I would point you to https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1
This allows SIDs to be advertised in the SID Binding TLV for a special purpose (see the Mirror SID). One could imagine another flag bit to indicate this is an Area SID.
I think this would need to be vetted with SR  folks – but I would like to avoid advertising a SID in a way different from all other SIDs i.e., SIDs currently are always a sub-TLV of some top level TLV – whether it be Prefix Reachability (Prefix-SID), IS Neighbor (Adjacency SID), or Binding SID (Mirror SID).

   Les


From: Tony Li <tony1athome@gmail.com> On Behalf Of tony.li@tony.li
Sent: Monday, June 29, 2020 12:52 PM
To: Hannes Gredler <hannes@gredler.at>
Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; draft-li-lsr-isis-area-proxy.authors@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy



Hi,

The authors have conferred and we would like to propose the following changes:

- The semantics of the Inside Node TLV will be folded into the Area Proxy TLV.

- The Area Proxy TLV will have its scope expanded to include pseudonodes.

- No change to the Area Segment SID TLV encoding.

Comments?   Especially from our Designated Experts?

Regards,
Sarah, Vivek, Gyan, and Tony



On Jun 25, 2020, at 12:04 PM, tony.li@tony.li<mailto:tony.li@tony.li> wrote:


Hi Hannes,

Thanks for your comments.  We will propose an alternate encoding.

Tony



On Jun 25, 2020, at 10:47 AM, Hannes Gredler <hannes@gredler.at<mailto:hannes@gredler.at>> wrote:

Hi Tony,

I do share Les’ concerns on burning top-level 8-bit code point space at this point.

At this point it is not me to judge wether CAP TLV or GENAPP TLV or something else should be a more appropriate place.
Please let's have a WG discussion on this.

Thanks,

/hannes


On 21.06.2020, at 18:50, tony.li@tony.li<mailto:tony.li@tony.li> wrote:


Les,

We don’t have to resolve this now.
One of my motivations for sending this was related to Early Allocation of code points. Since you have already asked once, I am assuming that if WG adoption is achieved it will be swiftly followed by an early allocation request – and as one of the Designated Experts I wanted to share my concerns sooner rather than later.


I appreciate that.  Do others share Les’ perspective on the relative tradeoffs?  Especially our other Desginated Experts?


Would this argue for advertising “this is a boundary circuit” in pseudo-node LSPs for boundary circuits rather than advertising “inside” on all inside pseudo-nodes?

You could do it that way.  It inverts the semantics and inverts the deployment.  Logically, it should have the same effect.  However, it then is seen by outside nodes.  Since they need not support Area Proxy, this seemed like a riskier approach, thus we opted for marking inside pseudonodes.

[Les:] My point was largely motivated by the statement in the draft:

“Area Proxy Boundary multi-access circuits (i.e.  Ethernets in LAN
   mode) with multiple Inside Edge Routers on them are not supported.”

So it seems advantageous to be able to prevent this from happening – which requires some signaling on the circuit in question.



I think that the case that you’re concerned about is already easily detected.  Recall that an Inside Edge router will generate IIH’s onto a boundary circuit using the Proxy system ID.  Thus, if an Inside Edge router receives an IIH with a source address of it’s own proxy system id, then it has encountered this issue.

Tony


_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr