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
- [OSPF] 转发: New Version Notification for draft-xu-… Xuxiaohu
- Re: [OSPF] : New Version Notification for draft-x… Curtis Villamizar