Re: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Mon, 11 April 2016 23:42 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AAF12D8D2; Mon, 11 Apr 2016 16:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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
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 bO4j-y55z5yW; Mon, 11 Apr 2016 16:42:07 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5747312D6DE; Mon, 11 Apr 2016 16:42:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2146; q=dns/txt; s=iport; t=1460418127; x=1461627727; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=j8FefVWMURrxZN+hgKSEjy1P7xz7qfWatkWcE/el6S4=; b=aLmyCmBNpqDISGGOU+ax0degQ6YREJ3k5p7Ch14JZQroM54dX876v6eH R7cBPo3wJS3w0VYuNkSJVIINYmea4PJ2xj7IH7gq7+Dkd50mTjdJzXy5s wP5xVHlXORCjNR+UcUhU/J6Y1cLJ5Rj5JcMgdAmo5OYh10OT4k8AUlTE6 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQBNNQxX/4MNJK1dgzdTfQa6XQENg?= =?us-ascii?q?XIXCoVsAoEwOBQBAQEBAQEBZSeEQQEBAQQBAQFrBAcMBgEIEQMBAlYLHQoEAQ0?= =?us-ascii?q?FiCcOwAYBAQEBAQEBAQEBAQEBAQEBAQEBEwSGIYRLihUFmAQBjguPDY8lAR4BA?= =?us-ascii?q?UKCMoE1bIkHfgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.24,470,1454976000"; d="scan'208";a="90680797"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Apr 2016 23:42:06 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3BNg6YD027533 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Apr 2016 23:42:06 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Apr 2016 19:42:05 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 11 Apr 2016 19:42:05 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, "draft-ietf-ospf-mpls-elc@ietf.org" <draft-ietf-ospf-mpls-elc@ietf.org>
Thread-Topic: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00
Thread-Index: AQHRlEvBpcuRzR4OpEWJ4X+miwJxNA==
Date: Mon, 11 Apr 2016 23:42:05 +0000
Message-ID: <D331AA68.3F8A8%cpignata@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.101.176]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <3FA822DBF86F84429D8594E3EC06C233@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/I-Ytg8uL0ZBwza7kdBkOUEMYBKY>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2016 23:42:09 -0000

Authors,

For this draft, it would be useful to also discuss and understand a few
other things, such as:

I. Has an approach similar to FAT-PW for LB (instead of the {ELI; EL}
Entropy Label approach) been considered? It would save label stack
entries, and allow precise positioning. Has this been ruled out?
II. Definition of behavior for networks with hybrid support (some nodes
support ELC, some do not). Like, can/should EL;ELI be used if some nodes
in the path do not support it? This will be a very common case. Some
downstream NHs might support it and some don¹t.
III. Are there multi instance or flooding scope implications?
IV. As specified, there is no relationship between ELC and RLDC. Seems
there is. Do these need to be supported simultaneously? Say, a node does
not support ELC but advertises RLDC, what¹s that mean?
V. There are several operational considerations which are just unadressed.
Say, a new LC is inserted in a node, which does not support ELC, or
supports a RLD smaller than what¹s been advertised. Or...
VI. No security implications sounds quite optimistic :-)

Thanks,

‹ Carlos. 

-----Original Message-----
From: OSPF <ospf-bounces@ietf.org> on behalf of "Acee Lindem (acee)"
<acee@cisco.com>
Date: Monday, April 11, 2016 at 2:38 PM
To: "draft-ietf-ospf-mpls-elc@ietf.org" <draft-ietf-ospf-mpls-elc@ietf.org>
Cc: OSPF WG List <ospf@ietf.org>
Subject: [OSPF] Signaling Entropy Label Capability Using OSPF -
draft-ietf-ospf-mpls-elc-00

>Authors, 
>
>We will soon be progressing the OSPFv2 SR draft. What is your intent for
>this draft? It is missing:
>   
>    1. A figure with the RI encoding like other OSPF documents
>    2. Discussion as to precisely how the capability would be used by a
>router in an OSPF routing domain. For example, must a router remove the EL
>if the next-hop doesn¹t support it?
>    3. A discussion of backward compatibility for the new
>Router-Information LSA capability.
>
>Thanks,
>Acee
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www.ietf.org/mailman/listinfo/ospf