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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Sat, 20 June 2020 23:45 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 0AAD23A07A7; Sat, 20 Jun 2020 16:45:19 -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_H3=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=afyBfj68; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=L3ezq3CH
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 s9U7F_jrGIta; Sat, 20 Jun 2020 16:45:16 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63FC53A07A6; Sat, 20 Jun 2020 16:45:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29686; q=dns/txt; s=iport; t=1592696716; x=1593906316; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J/xgdj56dU+1YWokKLA7P6S+/2LcL9XW7qXmDGWiaI4=; b=afyBfj68EtQjpjGjQK8Ftngf1EVPjQpt514LnIGnXyPIR43pGWnd30cl KWmZCKquPWmv/PlwqQ4g6PzB1vomw7YMBZWXEUetKGduzC8AyKi4/Hl02 7CG4iK7DE3Srdo/pRBIftY/6HMpDe8+XJm8RdAYoxFQPrvoCEUSEbSfRg Y=;
IronPort-PHdr: =?us-ascii?q?9a23=3AevEs8xy+gc4cCazXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWHt+lqik6PWYSIo/5Hiu+DtafmVCRA5Juaq3kNfdRKUA?= =?us-ascii?q?NNksQZmQEsQavnQU32JfLndWo2ScJFUlI243a9IA5RGZW2a1jbuHbn6zkUF1?= =?us-ascii?q?32PhZ0IeKgHInUgoy32um+9oeVbR9PgW+2YKh5K1O9qgCCuw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AAARn+5e/4ENJK1mGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBggqBIy8jBigHb1gvLIQkg0YDjUGKAI5UglI?= =?us-ascii?q?DVQsBAQEMAQElCAIEAQGBMoMVAheCEQIkOBMCAwEBCwEBBQEBAQIBBgRthVs?= =?us-ascii?q?BC4VyAQEBAQMSEQoTAQEpDgEPAgEIEQQBASsCAgIfER0IAQEEDgUIEweDBYF?= =?us-ascii?q?+TQMuAQ6sHgKBOYhhdoEygwEBAQWBRkGDQQ0Lgg4DBoE4gmeJfBqBQT+BEAF?= =?us-ascii?q?Dgk0+gQQBgRVCAgMBgTIrJAeCZzOCLYsIhyGGOospj39MCoJaiEKGI4R0ZYU?= =?us-ascii?q?LgnGJJJJmkSuKFYJYkVsCBAIEBQIOAQEFgWoigVZwFYMkUBcCDYhZhUUMF4E?= =?us-ascii?q?CAQiCQ4NGgU6FQnQ3AgYBBwEBAwl8jUmBZmABAQ?=
X-IronPort-AV: E=Sophos;i="5.75,260,1589241600"; d="scan'208,217";a="788166985"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jun 2020 23:45:09 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 05KNj9gR014169 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 20 Jun 2020 23:45:09 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 20 Jun 2020 18:45:09 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 20 Jun 2020 18:45:08 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 20 Jun 2020 18:45:09 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R8Of7xYj78nMDTcJ+JZcxwNrlwbbjtJSsNOE/RqdDnmQFym1Kfq7803eR260MHlbXcqt9i4is3NDj2ni4y0ZNlq/S3Oav+xqZXQStKLdk2b5y6t/WR1oE4MlHQWBE0y9CXLwRV5JnKPqgdaonTuusmfCzALt/hEHDXwv80K25w5NKvRjpkyp19ZY1TtmEatl0WBeM8AG+r+NkEXoAerUrh5RHmkJvp/03QatKPHrsRdChd07f9TneWa2KBJwwF2C2ID8QWtgV0RcO5UY7AOp+jOibmInFWcCZlYRbQAlS4qr4Pd85N6lG+ezmNl9Ob2G+iW+MY2/nUWSdUbFufa+og==
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=J/xgdj56dU+1YWokKLA7P6S+/2LcL9XW7qXmDGWiaI4=; b=jwsysxz9PCIhbmgh5qZbesxEpVRwXsWQc7gVQglGRPieFFJlkP09XCF4MZ0xIACyOeTn33KPALso7Q48vIDuVtqBpeu4PYIYniFsWhFZfVlqVUxCO3K/h0kTOhzp1PPx0ILerrOoVSiWJqKL18ENY0wkx7IGzERTgB7d0rPBcIDLDX2uvxoemySshLt7/nRpk4Ofczw1cWZOMcuCtl3AIo+nvm4Dzwu9HRI20clcRZQwQ8Z4cjyyC8w8+rlwAwBxRFFR1gQoJSp/eYUmvXiSNrEZYBFGoLtxkuYbVcOsk87e25p7ntbkPtzMkhtp1bluJkFeBsxMM9LYwJvxWtN5og==
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=J/xgdj56dU+1YWokKLA7P6S+/2LcL9XW7qXmDGWiaI4=; b=L3ezq3CHhW05LQxPyshKUcsDjQ6csb4zdhv92Jw+rmcWiF1ANI0XZK2W9h/PjS9Ll91HTFtDud1ZXp9WeLfn7nz14IdOfD+R0/ACm099HSobR3T0cMOMzfgDCDPYn6We+mPGzL1yy3MB8OR0S4unX4UjG3gNxMcU2PCCyXndLlY=
Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by BYAPR11MB3830.namprd11.prod.outlook.com (2603:10b6:a03:fc::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Sat, 20 Jun 2020 23:45:06 +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.3109.025; Sat, 20 Jun 2020 23:45:06 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "tony.li@tony.li" <tony.li@tony.li>
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: Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy
Thread-Index: AdZHOuOSJsSZJI/1RpqA6MX1gMmczwACEYAAAAQI3yA=
Date: Sat, 20 Jun 2020 23:45:06 +0000
Message-ID: <BY5PR11MB4337E58E8B775A7086281C21C1990@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <BY5PR11MB4337892CA6ADFD4F2E9B653FC1990@BY5PR11MB4337.namprd11.prod.outlook.com> <EB07BFF9-B4AF-41BE-94F0-25E229FA25FD@tony.li>
In-Reply-To: <EB07BFF9-B4AF-41BE-94F0-25E229FA25FD@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:b409:59a0:81d9:1082]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2a221b36-d753-4f48-3bcd-08d81573f617
x-ms-traffictypediagnostic: BYAPR11MB3830:
x-microsoft-antispam-prvs: <BYAPR11MB38306092A544DB30F665F31EC1990@BYAPR11MB3830.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0440AC9990
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rgMF5Tq7v6+NxEHah2Tngamy/zyTLcZOftMFUwIxdV4jiy9BHPR8GqB8fN8h8g5bOwCxwAmpuPzlja5Hwbb28pV1V4+nqJWkoyAJhXhMzabWrWMDLGYqDS8cisSczmGTG9jAAnBrVYJMfVEJObBHvrhzjNjT29lkgVoisnqQZG5kyqg6lHbe5StgZAkxpHOszEeCOsgbnu4q0+G6WM+ZJkNnxRnSwAEZY7SKM0CzdWcTj4yloumr42vlnmut2Jb20EMLDf0SELfd3VQPVrxKCEcgjnAUrEW5Howu2IW1bueZR9lvCFdU//NdV5hdtveTgeJZP/ehnAP8oBZLHPtvlCa3U8m+P+XzjnQJQZSJ18AhEps8IyDIZPJ/EOOGW0zVvk9KyvFIl5hnbma+vFLoPg==
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)(396003)(376002)(136003)(346002)(83380400001)(966005)(86362001)(6916009)(8936002)(66574015)(8676002)(478600001)(71200400001)(54906003)(9686003)(2906002)(55016002)(52536014)(7696005)(186003)(66476007)(66556008)(76116006)(66446008)(66946007)(166002)(5660300002)(316002)(64756008)(53546011)(4326008)(33656002)(6506007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Fzszc6rJdW3litmI+hkxpO+lKgoUKIze5BT7ImCdPPElMb7FEd0YP8+p5V/uis40iIHyuTnXcZBxAZ1fBOgh0V7WjJH3TscgPrvD8QUc615l0mgJ9tBoMlnYWb0n4lOMXr0To2SYyqEGsqMaXPjtDmJNWA/LfrWPTNMMO1ZdmLgevPSP/XgwcWUaejbVZlg8Vs2ipRMTMNYnoAufnd5THaHesW9k/GqoZcfyW40o8oht9yHnLFbhi7+06loW3MrsUU33KmUbx4pylFgVrwASBmtGAWxO0MGjAobRhDXsd7HvtVdTG3tAmcrziTANoKzZ30obY4x8yQbu1NoZbGMmluBx3LYvEwVpNVAgvQyHE7JomZYR7i7WB9ppxmo1tp06T96Kf2vufarzg4ijMMrxBfX6wpVi3IswWWpGfulKp/8QC1XAEj1+4nWutqh7fjnK4cURQUbQhQY+6+YoSSeH5Vx45EZt2I6h7x5cFRneGTpFmuDxS4Mb+kwAUNrAbPaFi+WUajhHZMmZWq7aQ6agaiG41A9N4f4di+1jShNqwOi0Jwcr0T3Ga78S0uquCPX+
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY5PR11MB4337E58E8B775A7086281C21C1990BY5PR11MB4337namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a221b36-d753-4f48-3bcd-08d81573f617
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2020 23:45:06.5965 (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: nhsA8kU/yxIj91OUf1xwuS36iClXsIdSnDlyc6PcpyT6rWB50I5CbAvHyzSOdcf+emoFVv5bbR/4scJTaXVD3A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3830
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/cv4O7yKPYSA3j1Eadv91ychMnOo>
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: Sat, 20 Jun 2020 23:45:19 -0000

Tony –

Thanx for the quick response.

Putting the Inside Node TLV aside for the moment, it would seem to me to be advantageous (in a modest way) to have all information relating to Area Proxy contained in one advertisement. Using Router Capabilities TLV would accomplish that.
Your concern about “burdening” the Router Capabilities TLV seems unwarranted.
Every capability currently defined comes with additional information.
Multiple Router Capability TLVs are allowed (indeed even required to support different flooding scopes) – so TLV space is not limited.

Returning to Inside Node TLV, I share your concern about advertising Router Capabilities TLV in pseudo-node LSP. But what does it mean to advertise the Inside Node TLV in a pseudo-node LSP?
Presumably you need some capability indicator because even on boundary circuits the DIS will use the native systemid rather than the proxy systemid and therefore you cannot tell based on pseudonode-id alone what type of circuit this is.

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?

And do you need the “boundary circuit” indication in L2 IIHs (and perhaps P2P IIH as well??) as protection against improperly forming adjacencies on boundary circuits?

Regarding the Area SID advertisement, I take the point that this concept might be useful more generically, but as it is key to have the correct scope for the SID, it is hard to see how the advertisement could be used apart from the context (Area Proxy in this case). So advertising it separately doesn’t seem useful.

Regarding consistent SRGBs, you might find https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments/ worth reading as something attempting to address a similar problem. It isn’t easy.

   Les


From: Tony Li <tony1athome@gmail.com> On Behalf Of tony.li@tony.li
Sent: Saturday, June 20, 2020 1:41 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Cc: draft-li-lsr-isis-area-proxy.authors@ietf.org; lsr@ietf.org
Subject: Re: Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy


Hi Les,

Thank you for your comments.  Please see my comments inline.


draft-li-lsr-isis-area-proxy-06  currently proposes the use of one new sub-TLV of Router Capabilities TLV and three new top level TLVs


It should probably be noted that the Area Segment SID is somewhat orthogonal to the rest of Area Proxy.   It could be conceivably be used without
Area Proxy, or with another solution.

It would not be unreasonable to consider the Area Segment SID to be a proposal logically independent of Area Proxy.  Thus, Area Proxy really is requesting two new top level TLVs.


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


Comments:
This seems unnecessarily profligate in its consumption of top level TLV code points – something to which, as a Designated Expert for the IS-IS registries,  I pay close attention.
I can imagine an alternative encoding which utilizes a single sub-TLV within the Router Capabilities TLV:

Area Proxy Router Capability sub-TLV

  Type: TBD
  Length: Variable
  Value: Flags + Optional sub-TLVs

1 octet of Flags:

      0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+
      |I|L|P| RSVD  |
      +-+-+-+-+-+-+-+

I If set indicates Inside Node
L If set indicates capable of performing Area Leader functions
P If set indicates Proxy LSP advertisement
RSVD - for future allocation

Followed by optional sub-sub-TLVs

Sub-sub-TLV Area Proxy System ID
Sub-sub-TLV Area SID (Used only when P bit is set)

Please comment on this alternative.


One of the issues that drove us to introduce the Inside Node TLV was confusion about pseudonodes.  How does a node determine whether a pseudonode is Inside or Outside?  This is an important at flooding time because if it is Inside, it should be flooded externally.  We did not consider putting a router capability TLV into a pseudonode and opted for another top level TLV instead.

We chose to make the Area Proxy TLV a top level TLV because we felt that it was inappropriate to burden the Router Capabilities TLV with arbitrary amounts of additional data. In our humble opinion, the router capabilities TLV should be reserved for capabilities.  Yes, it’s true, we could put that data inside of the router capabilities TLV, but as we learned a long time ago with GUP, we can pretty much put anything anywhere. Just because we can doesn’t mean that we should.


Additional Questions:
It is not clear to me why Area SID requires two different advertisements :
1)As a sub-TLV of Area Proxy TLV and
2)As a top Level TLV in the Proxy LSP
Is it because you wanted a unique codepoint for the Proxy LSP advertisements?


We wanted the sub-TLV so that the Area Leader can distribute the value to all of the Inside Edge Nodes.

We wanted the top level TLV so that it could be distributed to the Outside area.


There is a statement regarding the SR Capabilities sub-TLV advertised by the Area Leader as having:

   "an SRGB identical to that advertised by all Inside Routers"

SR does not require all nodes to advertise identical SRGBs. Are you imposing
a new requirement in order to support SR and Area Proxy together? If so, what happens if all Inside Nodes do NOT advertise identical SRGBs?


Yes, that is a requirement that we are imposing and it applies to the Inside Nodes, and possibly only to the Inside Edge Nodes.  More thought from SR experts would be welcome here.

I disclaim all expertise in SR. :-)

The concern here is that the SID value advertised in the Area Segment SID TLV be interpreted identically by inside and outside nodes. If the SID is an index and the SRGBs are not identical, then there would be some inconsistency between how the inside and inside nodes would interpret the SID.  Thus, mismatched SRGBs is a misconfiguration.

Regards,
Tony