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 14:28 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 3398C3A10E0; Tue, 26 May 2020 07:28:44 -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=ggSb+dzS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=c3Y96lxc
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 hgehwX45Ay9I; Tue, 26 May 2020 07:28:31 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834093A108B; Tue, 26 May 2020 07:28:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10946; q=dns/txt; s=iport; t=1590503304; x=1591712904; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=peuvsNoZuONSvXKvGyFvHiSMzU45fdL3fQ088KtMdps=; b=ggSb+dzSYg9HUFVjOzXH/uY+RjMnKwe7jBleQPGS5E26HsQUnyAptvNj XLPzsrUwD8V7+F6Bkfa6t5bThQC6pMjoj+ntixlIdACM0KVvXTgvTj9QR AS3bCH9CYc2vc4QLZZo4n8PwxeNN4QQeO7FeWkQpqO2wkmKl/3csXHwDY U=;
IronPort-PHdr: =?us-ascii?q?9a23=3ALjG2BhDXogcAVhYjPT5xUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw00A3CXJ7Q7LRPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGE8flbFqUqXq3vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAgCpJs1e/5FdJa1mDg0BAQEBAQE?= =?us-ascii?q?BAQUBAQESAQEBAwMBAQFAgUeBVFEHgUcvLAqEG4NGA40eJZg8gUKBEANVCwE?= =?us-ascii?q?BAQwBAS0CBAEBhEQCF4F4JDgTAgMBAQsBAQUBAQECAQUEbYVWDIVzAQEBAxI?= =?us-ascii?q?REQwBATcBDwIBCBgCAiYCAgIwFRACBAENBSKDBIJMAy4BojwCgTmIYXaBMoM?= =?us-ascii?q?BAQEFhSkYgg4JgQ4qgmSJYBqCAIERJwwQgk0+hBgBARIBIReCfTOCLZFmoUM?= =?us-ascii?q?KglSON4olHYJjiQKSHZBOnWICBAIEBQIOAQEFgWkiZnBwFWUBgj5QGA2QQDi?= =?us-ascii?q?DOooYPnQ3AgYBBwEBAwl8i0kBgQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.73,437,1583193600"; d="scan'208";a="772428939"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 May 2020 14:28:23 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 04QESNT8032516 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 May 2020 14:28:23 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 26 May 2020 09:28:23 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 26 May 2020 09:28:21 -0500
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 26 May 2020 10:28:21 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V8YkDKjhBi+O8O9POsXgnhNzf2dZR58mX485b2MiXqBgD0OdyTszyDYjLfdv/lNAr61P3knCNqFzuQ3TxV0a+YQSBA58bwaq+QZhiqAYPqjaGLeR0nISWdCMD9xb3xYvT4U6bNrAg5sVTAemOzg53J/m3Gu3lNQ5EV60Qf3Vo09hKj41Oz+t7MPtV4SQ4lbzY1mh/Pxgl3X/IAJRKXHFAYcYUq8UKetdm6HlsjtXhD9CoYV6BQPaL/f2imYP9dwbQ3ndn4ZnBCQErAeJ9+eoft8MyUqzZBtRyq4bD0ad1iV98OOJatnfuvkB6ZneFk1W7E1+H7STOnIkXtbi5YjhZA==
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=peuvsNoZuONSvXKvGyFvHiSMzU45fdL3fQ088KtMdps=; b=E5XHW1vnEHu6y23u5j+sczUO7YU4g7OPeHrQQ0P8xLfmtOMVt3y0I5Azp1IR3Xz0r74+HIHsvdP7iVUhhHmCXvEFhqveXROTdfgmefFqGVRG4suJeJRBrU1clkLspGxsGCsHHHT0m4WiikpPYyxJEajG1bLzO4neP7s5SfEieExcFQ6TdosFVW24tbtp60pC1GjCq5Bpp1FYaYGuV3TcYiiCpX5752rVK5kt8CZd+vRx8uPLA04nIGbRbDyL3rJ4nn2UJY4c2c/1ALpGQOWbz4HPWer90N4WgN/u5cbIstnyqaKbDT6cai9WWWdRXger6sCp5W3psQ+BjEMZiLuKdQ==
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=peuvsNoZuONSvXKvGyFvHiSMzU45fdL3fQ088KtMdps=; b=c3Y96lxcGKQlaxQAv6s6xwZmJTR4kQ4Qr4xDLQc1aQObLOfrq1fHqhcPdJfYQu2w9m1cYSDZyk937K35KOSMk3m8h4C9ZnWv2lZ07e70nbeBZpEXItWV8dZ35wPZowdrgCLOBFnHSnCAK65Wvsm6rj4+TJvaByJUEI7NtrJVw3c=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3112.namprd11.prod.outlook.com (2603:10b6:a03:85::13) 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 14:28:19 +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 14:28:19 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, Alvaro Retana <aretana.ietf@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>
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: AQHWLi8YMiDtiOiXz0umkwYeF81nrKiyUmOAgACgLQCAAURHAIAF23oAgAAcTICAAEgRgP//vbEA
Date: Tue, 26 May 2020 14:28:19 +0000
Message-ID: <0A45769F-40ED-45A8-8853-FFB346E09F03@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> <63cbb2b2-e7ec-3077-ab4d-258ce95e6ef7@cisco.com> <FCE03BA7-39DB-44A4-9E3A-93E8DC0CAB31@cisco.com> <88a5c560-cb61-78c2-3733-931ffe529b6b@cisco.com>
In-Reply-To: <88a5c560-cb61-78c2-3733-931ffe529b6b@cisco.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: cisco.com; dkim=none (message not signed) header.d=none;cisco.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: f90d0ebb-edbb-4b46-8aed-08d8018109b7
x-ms-traffictypediagnostic: BYAPR11MB3112:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB3112E0049264A23E51BEB9FAC2B00@BYAPR11MB3112.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 041517DFAB
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Tk/dgbJYLHIx/K8+2wl2jrk4q71nLGs23Wmok6C/aLY02ySTOk3O+26KBoRLt3vqgzM+2mgUELop3SZ25FoojAZqdG6TW5SC2Lb7yfIgrEjt9cfzluWgP7OXmYUpLcFGn4JaoShfGx0J3+K7vMsDFqoUqJtt+1mUB+9Ma0B1t7Cv07n/IicLZ6i0afeZNvwU0FHbHeNUgGxUVs/AToThjOSA2oRVZoPSn2NxkonsaWItB8Gqj0jPW6EY2t78sbb7bBrOb4vsoqnm8MqzYlUGdbATRZU30liyyrghLoQ0T4xesyIJmOv5ZvJEj+jmlOqcKpKGZO8huwMDamcAUq1tlw==
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)(366004)(376002)(346002)(39860400002)(136003)(396003)(478600001)(66556008)(64756008)(66476007)(26005)(6506007)(66574014)(53546011)(91956017)(2616005)(66446008)(86362001)(76116006)(186003)(66946007)(54906003)(110136005)(2906002)(36756003)(33656002)(71200400001)(5660300002)(8676002)(316002)(6486002)(6512007)(4326008)(8936002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Nh2ay702erDoInmIX5kHcQZ5HPDdqENghGsAAlx5YB/c3G8xjNBwCxVmEkA01K3wVixl7aRSd3hs96h7f5gwziTy9/vYVLf84mn9GaUs0AxWJ8Zj8epqUeE/g4BSMeWRUd5A82jVJ4IMK+ODYgnhxZU6qy2eK6xKR9wzCzgxYCbYvFzgYkdRyuBaFPj9fJPFW/L14WzKZPvsdRZuu7Vc5me65JaAyjTRZPg2wJfovDSYsNqhjFnXUFd7a0qK+dtB1iutfVLFKLXdKCPKqjefSSc206rEnUXwP7rHLfNgIsvVk529qPDzd+fpqCoUMJhfRiD9H8gqizsJ40S1JqeCF6FKjJY8IIpLsoYf11Rh38iiDjvOu6R6LErAUhFkSUeekajGQMnt2oKKZcNmtVI66nf2jsN2FdmBYBDwEVDTyU7LMBJFlTZmYVBrt90xqe0jDJfbKFzsOcplICTySfFdsYZc5pQo4XGqPbPIpHM/KMI=
Content-Type: text/plain; charset="utf-8"
Content-ID: <0A7E501C8DAB264882330FC83EFA1EC6@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f90d0ebb-edbb-4b46-8aed-08d8018109b7
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 14:28:19.6199 (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: NJcQeDdcE1wnwpy/X/ikJ93m1fI+2xeWv9Sh5YOgYA64iLeZFQV5B+aoX25POUlX
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3112
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/E_pho5dFcbAKgQxWhbj_pN2Dwik>
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 14:28:48 -0000

Hi Peter, 
Thanks - hopefully this will more than satisfy Ben's discuss.
Acee

On 5/26/20, 10:25 AM, "Peter Psenak" <ppsenak@cisco.com> wrote:

    Hi Acee,

    updated the text based on your comments.

    thanks,
    Peter


    On 26/05/2020 16:07, Acee Lindem (acee) wrote:
    > Hi Peter,
    > 
    > This is in response to the previous Email on your suggested text.
    > 
    > On 5/26/20, 4:26 AM, "Peter Psenak" <ppsenak@cisco.com> wrote:
    > 
    >      Hi Alvaro,
    > 
    >      please see inline (##PP)
    > 
    >      On 22/05/2020 16:59, Alvaro Retana 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.]
    > 
    >      ##PP
    >      done.
    > 
    > 
    >      >
    >      >
    >      >
    >      > 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.
    > 
    >      ##PP
    >      correct. It is always a new LSA that ABR needs to generate. Here it's
    >      actually two LSAs.
    > 
    >      >
    >      > 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.
    > 
    >      Here's my suggestion for OSPFv2 ABR related text:
    > 
    >      "The ELC signaling MUST be preserved when an OSPF Area Border Router
    >      (ABR) distributes information between connected areas. To do so, ABR
    >      MUST originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including
    >      the received ELC setting."
    > 
    > Ok - I change "connected areas" to "areas" and "ABR MUST" to "an ABR MUST".
    > 
    >      Here's my suggested text for OSPFv2 ASBR case:
    > 
    >      "When an OSPF Autonomous System Boundary Router (ASBR) redistributes a
    >      prefix from another instance of OSPF or from some other protocol, it
    >      SHOULD preserve the ELC signaling for the prefix if it exists. To do so,
    >      ASBR SHOULD originate Extended Prefix Opaque LSA [RFC7684] including the
    >      ELC setting of the redistributed prefix. The flooding scope of the
    >      Extended Prefix Opaque LSA MUST match the flooding scope of the LSA that
    >      ASBR originates as a result of the redistribution. The exact mechanism
    >      used to exchange ELC between protocol instances on the ASBR is outside
    >      of the scope of this document."
    > 
    > Sure - replace "ASBR SHOULD" with "an ASBR SHOULD", "that ASBR" with "that an ASBR", and "the ASBR is" with "an ASBR is" to be consistent.
    > Also, "originate Extended" with "originate an Extended".
    > 
    > 
    > 
    >      >
    >      >
    >      > 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.
    > 
    >      Here's my suggestion for OSPFv3 ABR and ASBR:
    > 
    >      "The ELC signaling MUST be preserved when an OSPFv3 Area Border Router
    >      (ABR) distributes information between connected areas. The setting of
    >      the ELC Flag in the Inter-Area-Prefix-LSA [RFC5340] or in the
    >      Inter-Area-Prefix TLV [RFC8362], generated by ABR, MUST be the same as
    >      the value the ELC Flag associated with the prefix in the source area."
    > 
    > Same change - replace "connected areas" with "areas" and "by ABR" with "by an ABR".
    > 
    >      "When an OSPFv3 Autonomous System Boundary Router (ASBR) redistributes a
    >      prefix from another instance of OSPFv3 or from some other protocol, it
    >      SHOULD preserve the ELC signaling for the prefix if it exists. The
    >      setting of the ELC Flag in the AS-External-LSA [RFC5340] or in the
    >      External-Prefix TLV [RFC8362], generated by ASBR, MUST be the same as
    >      the value the ELC Flag associated with the prefix in the source domain.	
    >      The exact mechanism used to exchange ELC between protocol instances on
    >      the ASBR is outside of the scope of this document.
    > 
    > Add "NSSA-LSA" as a case. Replace "by ASBR" with "by an ASBR" and "value the ELC" with "value of the ELC".
    > 
    > Thanks,
    > Acee
    > 
    >      thanks,
    >      Peter
    > 
    > 
    >      >
    >      >
    >      >
    >      >
    >      >>> (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.
    >      >
    >      >
    > 
    > 
    > 
    >