Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

"Acee Lindem (acee)" <acee@cisco.com> Tue, 26 May 2020 11:49 UTC

Return-Path: <acee@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 71C713A0EFE; Tue, 26 May 2020 04:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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, 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=lLm8yC5D; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zUMwlP2s
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 jNScZaQA0cRv; Tue, 26 May 2020 04:49:16 -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 60FDF3A0E80; Tue, 26 May 2020 04:49:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5708; q=dns/txt; s=iport; t=1590493756; x=1591703356; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wcPQAZ1ssRlPvatIO8vaaDMW39szIh+nYUuhq8+LCqc=; b=lLm8yC5DSMY9JlAmqPKVT5KV6rS3zy9cDRv4E7pj4DukX3cT08IKEHUk 8j7gjVGCtZ+6bUpXAlbAZ16zuKG9VwEBauaF5LFqq6KgFtdX1A4KevhtQ kvz0zxPr9J63v7Jpcl6mDiUbxCFccQcq687IALKh8+tH5aqdak0OQep3T Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3Aa5iUnheJKeNqC6hxdceJYSHYlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQAdfU7vtFj6zdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutaFjbo3n05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZCgC1Ac1e/5NdJa1mDg8BAQEBCQE?= =?us-ascii?q?SAQUFAUCBR4FUUQeBRy8sCoQbg0YDjRwliXqOQoJSA1ULAQEBDAEBLQIEAQG?= =?us-ascii?q?ERAIXgXckOBMCAwEBCwEBBQEBAQIBBQRthVYMhXMBAQECARIREQwBATcBDwI?= =?us-ascii?q?BCA4MAiYCAgIfERUQAgQBDQUigwSCTAMOIAGhYwKBOYhhdoEygwEBAQWFMw0?= =?us-ascii?q?Lgg4JgQ4qgmSJYBqCAIERJwwQgk0+gh6BejaDFDOCLZFmkSOPVkoKglSON4V?= =?us-ascii?q?JhFwdngKQTow6kSgCBAIEBQIOAQEFgWkigVZwFWUBgj5QGA2QQDiDOooYPnQ?= =?us-ascii?q?3AgYBBwEBAwl8i0kBgQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.73,437,1583193600"; d="scan'208";a="501803694"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 May 2020 11:49:15 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 04QBnF5Z024885 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 May 2020 11:49:15 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 26 May 2020 06:49:15 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 26 May 2020 06:49:14 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 26 May 2020 07:49:14 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bo5yuZlgtmRDXpWKTo2SHcCSidS6N7uou9hXM1vXqAsQ6Xa/1euCjB0MrwXsHIc2Mgg5Qj0fris+rInkphh1VeOeHm108NzXBqCJP+4fwDTeU4ZC7PCZbQth6yyXc+L5DZJ1h2ZUjarEvCYQv3XC5/ZolS3KFIzkrdF0HsHNpE7YM+kyAt+l1jyGW4LPZvVnePLm7hgYKj6x30A4Ho0UBDgI9ShZknmzW4isNHWyxVB7mBEXv7pOoz/FvvoxloqDlSg90514loTK02ZUvc7tpP+W0WCwpKTTIrLMmdDV9EOfgBqcs1KLsljxka4g2+nxvnatJSnYur50RgAcpv2Y6g==
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=wcPQAZ1ssRlPvatIO8vaaDMW39szIh+nYUuhq8+LCqc=; b=eMiDp9xc0uK3ay9s9sdM+yNJKfgnsTd4kKNWLHXas1wZT0O/tM129SD8Gg5zX3c4HQuGi8foHlcLTjHkFVzzXqhPJ7U47aznjtvxmCs0Suuxi7IsJ/P14okiVE9e6GDmozY0I7DaJ5RNRXxNQEfMN0ElyYU37uq8bqpLWZu48aAXTYxv+16F7gzSLTtiKFaFlxqHtU8lsSwVT/ojD1GuBgWLW/fIwqL4KlDPq+8oS9Mukd19EfNOU3F+H7t4jGAij/ehYU8xDHVWXkKqDrvK9+4y8sxgCQk2UKw29SSB2l5faHcjrET5IivRfVhwwYrZM5GepX9sEKWBp0pcPvu+Fg==
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=wcPQAZ1ssRlPvatIO8vaaDMW39szIh+nYUuhq8+LCqc=; b=zUMwlP2sg3iw4jUVFhTMNJVNHQwIiatB05jRXpRHk2MWIpHV5c90CD7D6xh2ZJiVX1aMu0Z69nqA87gWowUBla6k9bs0QXOEJfD4p3tZ14y++LwQDjDLk0+eH5ZsuvFFgjbJPaU/Qr4krr1F0dy9nwBWNBbGUXsBDW3pH7LcFRo=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3110.namprd11.prod.outlook.com (2603:10b6:a03:8a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.27; Tue, 26 May 2020 11:49:13 +0000
Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::4950:e26c:503f:768e]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::4950:e26c:503f:768e%6]) with mapi id 15.20.3021.027; Tue, 26 May 2020 11:49:13 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>
CC: "draft-ietf-isis-mpls-elc@ietf.org" <draft-ietf-isis-mpls-elc@ietf.org>, The IESG <iesg@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
Thread-Index: AQHWLi8YMiDtiOiXz0umkwYeF81nrKiyUmOAgACgLQCAAURHAIAF0RUA
Date: Tue, 26 May 2020 11:49:13 +0000
Message-ID: <1852869A-2678-4AA7-AEB9-F7A3014A7191@cisco.com>
References: <158992828112.6026.1646593855480055081@ietfa.amsl.com> <1242ad52-bb48-8526-b65b-d413e0cd9e25@cisco.com> <20200521193856.GJ58497@kduck.mit.edu> <CAMMESsxo56ZK+DKBMkKvFcXf+1GFPF+wDtRCW=+md8WCoKODxw@mail.gmail.com>
In-Reply-To: <CAMMESsxo56ZK+DKBMkKvFcXf+1GFPF+wDtRCW=+md8WCoKODxw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.37.20051002
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3e536624-2d3a-4702-cf18-08d8016acfa0
x-ms-traffictypediagnostic: BYAPR11MB3110:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB3110983CE8AF85AE8E746E03C2B00@BYAPR11MB3110.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 041517DFAB
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: sjoafCCnvghl+lTN82+XSCQPpkPLH+DJGA2PDDMCZy/jVb27lsVMm5zzznQ5aezi4ISfMUpx3caU6sc96aoEz86SL/lNrzrM/sKgEvR+UefVMRPlo/JaSjyi/KoDSFet1LuNmvrzzffg93TwC3roJR7QLPhCiOJxtJAkkxNqYW5HYtaHf/PSmzAQPg1UK5usgsBtjcfPbza5qnSim1Suz/i4wLQmL8+F5xhiUWKaHagmXX3+W1YWPxi2pKuSuP8OQwg8OrcQxZI0vce/eKJic1zmztQate25CKtHnEVlTu1T15sz6xgmq1cHIQb3Jq8rIA/pP1TTX/nhF8wENctNcQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(396003)(136003)(366004)(66946007)(6636002)(76116006)(64756008)(33656002)(66556008)(66446008)(91956017)(8936002)(6512007)(8676002)(5660300002)(478600001)(71200400001)(2616005)(86362001)(6486002)(54906003)(66574014)(4326008)(26005)(66476007)(110136005)(6506007)(53546011)(36756003)(186003)(316002)(2906002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: QYBtJ7ahq0YgNV+MSxne3d1T7a/zukusGRLIy1C38sN5T5UZMA+U1wpP62YlAi09H31zzhpJi5DuihVOwFk+lfe+BEcn0UAvhJudICClCssPxVBmR2yw926S/Yn/L9H1Fvlyu+wcN0VVrS4IfmBuzMSCfbvBOdG12ODbtfglP6NfYlChfLThBAolY872hy2AH3LmcTcl8o+DiKedw7gQ+U0LakW9RqnxCQvIQ6BrbnP5cfhUR5XDDO9CBLGfsI3Ks3HXXrcDfwdEmFBklzRAKPaY76liXw4HiIldtVemHQoOOm3J+Q5Z6VEJQJV93Kx9CY7q7Cd1Sqd7B+WcEKVc+DQzX/tgfdN+dBeGD5oh6FE2MWrPp33GEnodwWXF0DZRZnphVsz5eD0uO0QXh72MAvdnl9TCQ44l+ke8RIEmCduzWMRkwgMuW/SJ+hoWXOmnCxNeMwxoGY0e6ntt8mdiYiUCXG5M3PYRPSJ5ylsUlR4=
Content-Type: text/plain; charset="utf-8"
Content-ID: <CD136430B0887B4182002AB360CD60DE@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e536624-2d3a-4702-cf18-08d8016acfa0
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 11:49:13.3769 (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: IZgcKo6oBA5fzlgY0BFbAdvoxjU0zeJF/5b6h6mX3kmv5UBCswDwdhQa2hv3jbQS
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3110
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/q89j_zdsTCQ4hzT-rtBr8c91jo8>
Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
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: Tue, 26 May 2020 11:49:26 -0000

Hi Alvaro, 

See inline. 

On 5/22/20, 10:59 AM, "Alvaro Retana" <aretana.ietf@gmail.com> wrote:

    On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote:


    Peter:

    Hi!


    > With respect to Alvaro's clarification, your answer for (1) makes sense;
    > thanks! I think Alvaro has offered to help work out what (if any)
    > additional text we might want to be sure that the answer to (2) is clear in
    > the document.

    I think that #1 is where some clarification could be useful. :-)


    I'm including both ISIS and OSPF suggestions below to consolidate the
    discussion.


    ...
    > > My interpretation of Ben's question is two-fold:
    > >
    > > (1) Would ISIS routers normally propagate the information to a
    > > different level? The ELC is a new prefix attribute flag -- are prefix
    > > attributes always propagated (unchanged) to other levels? If so, then
    > > the requirement (MUST) is not needed. My reading of rfc7794 is that
    > > the propagation is optional...
    >
    > depends on the attribute or a bit. Some are propagated some are not.
    > That's why we are saying this one MUST be preserved.

    Right.

    For ISIS I think the current text is in line with the specification of
    the other bits in rfc7794.  No changes are needed.

    If anything, you may want to change the order of this sentence to
    address Ben's comment:

    OLD>
       When a router propagates a prefix between ISIS levels ([RFC5302], it
       MUST preserve the ELC signaling for this prefix.

    NEW>
       The ELC signaling MUST be preserved when a router propagates a prefix
       between ISIS levels ([RFC5302]).

    [Similar for OSPF.]



    I think that for OSPF it is not that simple...

    For OSPFv2: rfc7684 says that the "scope of the OSPFv2 Extended Prefix
    Opaque LSA depends on the scope of the advertised prefixes", which I
    assume means that for intra-area prefixes the scope will be
    area-local...so the ABR wouldn't simply propagate it; it would have to
    originate a new LSA.

I agree with the changes but have suggested alternate text. 

    Suggestion (Add to 3.1)>
       When an OSPFv2 Area Border Router (ABR) distributes information between
       connected areas it SHOULD originate an OSPFv2 Extended Prefix Opaque LSA
       [RFC7684] including the received ELC setting.  If the received information
       is included in an LSA with an AS-wide scope, then the new LSA is not needed.

I'd suggest:

      When an OSPFv2 Area Border Router (ABR) advertises prefix information between
      areas and ELC information is was advertised for the prefix in the source area, the
      ABR SHOULD originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] propagating
      the prefix's source area setting. If the ELC setting, is also advertised in an OSPFv2
      Extended Prefix Opaque LSA with AS-wide scope, the additional LSA origination
      Is not needed. 


    For OSPFv3: The PrefixOptions are *in* the LSA, but I couldn't find
    anything in rfc5340 saying that the received values should be copied
    into the Inter-Area-Prefix-LSA (nor that they should not).

    Suggestion (Add to 3.2)>
       When an OSPFv3 Area Border Router (ABR) distributes information between
       connected areas, the setting of the ELC Flag in the Inter-Area-Prefix-LSA
       MUST be the same as the received value.

I'd suggest:
      
      When an OSPFv3 Area Border Router (ABR) advertises information between
      areas, the setting of the ELC flag in the Inter-area-prefix-LSA MUST be the
      propagated unchanged. 

Thanks,
Acee




    > > (2) If the propagation is not automatic, and the L1L2 router doesn't
    > > support this specification, then what are the drawbacks/failure
    > > scenarios? IOW, for multi-level operation is it a requirement that
    > > the L1L2 support this specification?
    >
    > drawback are identical to what is mentioned in the Security
    > Considerations section.

    I think that text is ok.


    Thanks!

    Alvaro.