Re: [OSPF] : New Version Notification for draft-xu-mpls-el-capability-signaling-igp-00.txt

Curtis Villamizar <curtis@ipv6.occnc.com> Wed, 11 September 2013 15:04 UTC

Return-Path: <curtis@ipv6.occnc.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 5ADBA21E8121 for <ospf@ietfa.amsl.com>; Wed, 11 Sep 2013 08:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xroffyw937id for <ospf@ietfa.amsl.com>; Wed, 11 Sep 2013 08:04:41 -0700 (PDT)
Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id B99CF11E81BB for <ospf@ietf.org>; Wed, 11 Sep 2013 08:03:45 -0700 (PDT)
Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r8BF2B2U005856; Wed, 11 Sep 2013 11:02:11 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201309111502.r8BF2B2U005856@gateway1.orleans.occnc.com>
To: Xuxiaohu <xuxiaohu@huawei.com>
From: Curtis Villamizar <curtis@ipv6.occnc.com>
In-reply-to: Your message of "Tue, 10 Sep 2013 00:59:05 -0000." <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820CC37@NKGEML512-MBS.china.huawei.com>
Date: Wed, 11 Sep 2013 11:02:11 -0400
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] : New Version Notification for draft-xu-mpls-el-capability-signaling-igp-00.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: curtis@ipv6.occnc.com
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: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Sep 2013 15:04:50 -0000

In message <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820CC37@NKGEML512-MBS.china.huawei.com>
Xuxiaohu writes:

> Hi all,
> 
> The following draft defines a mechanism to signal the Entropy Label
> Capability (ELC) using ISIS and OSPF, which is applicable in the
> case where the label advertisement is also done via that IGP.
> 
> Any comments and suggestions are welcome.
> 
> Best regards,
> Xiaohu


Xiaohu,

This is a short document and it uses the OSPF Router Information (RI)
Opaque LSA defined in [RFC4970] and IS-IS Router CAPABILITY TLV
defined in [RFC4971].

That won't work if some of the interfaces are ELC and others are not.
This would be a common case in transition or after transition if a
spare card was not ELC but otherwise useable and was needed after a
card failure.

ELC must be on a per interface basis.

While you are at it, please also consider including the following

  0) whether the interface can terminate an LSP with ELI and EL (aka
     ELC, what you planned to cover),

  1) whether the interface can find an ELI and EL in the label stack
     and make use of it,

  2) at what maximum depth can the entropy occur (maybe 0 for more
     than 255 or more than 65535 which would be absurd),

  3) whether the search for entropy is terminated when the EL is
     encountered (RFC6790 says "SHOULD" and some people including me
     think that should have been a "MUST"),

  4) whether reserved labels are ignored (may matter for GAL,
     therefore MPLS-TP protected by EL),

  5) whether reserved extended labels are ignored,

  6) whether the interface will look below the stack for entropy (ie:
     looks for 4 or 6 in first payload nibble and needs PWE CW if
     payload is not IP).

Note that for MPLS-TP to be carried protected by ELI and EL, #1 plus
either #3 or #4 (or both) must be true.  Also note that #4 and #5 can
be true even if #0 and #1 are not true and #4 would be sufficient for
MPLS-TP with no labels under the stack.

These would be better in a bit map in one TLV rather than one TLV each
(though #2 needs an integer).

Curtis