[Isis-wg] questions about draft-ietf-idr-ls-distribution-11

peng.shaofu@zte.com.cn Thu, 02 July 2015 02:16 UTC

Return-Path: <peng.shaofu@zte.com.cn>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB251A0423; Wed, 1 Jul 2015 19:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.21
X-Spam-Level:
X-Spam-Status: No, score=-104.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham
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 3UpcXC-w3L7U; Wed, 1 Jul 2015 19:16:02 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3681A014D; Wed, 1 Jul 2015 19:14:34 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 8E3A5989AC244; Thu, 2 Jul 2015 10:14:30 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 2161A4B26CF83; Thu, 2 Jul 2015 10:14:30 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t622E1I3031163; Thu, 2 Jul 2015 10:14:01 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn)
To: hannes@juniper.net
MIME-Version: 1.0
Sensitivity:
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OFD71E01DE.9A34B51A-ON48257E75.00332E66-48257E76.000C4535@zte.com.cn>
From: peng.shaofu@zte.com.cn
Date: Thu, 02 Jul 2015 10:13:57 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-07-02 10:14:01, Serialize complete at 2015-07-02 10:14:01
Content-Type: multipart/alternative; boundary="=_alternative 000C453348257E76_="
X-MAIL: mse01.zte.com.cn t622E1I3031163
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/ZSbYJhI3hTK4Fu8Uk8K1IX_D5hY>
Cc: idr@ietf.org, spring@ietf.org, isis-wg@ietf.org
Subject: [Isis-wg] questions about draft-ietf-idr-ls-distribution-11
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jul 2015 02:16:05 -0000

hi hannes & other authors

As described in [Link-State Info Distribution using BGP] (see Section 
3.2.2, “Link Descriptors”), the IP address TLVs (TLV code 259-262) or 
the link local/remote Identifier TLV (TLV code 258) are included in the 
link descriptor. 
“The information about a link present in the LSA/LSP originated by the 
local node of the link determines the set of TLVs in the Link Descriptor 
of the link.
      If interface and neighbor addresses, either IPv4 or IPv6, are 
present, then the IP address TLVs are included in the link descriptor, but 
not the link local/remote Identifier TLV.  The      link local/remote 
identifiers MAY be included in the link attribute.
      If interface and neighbor addresses are not present and the link 
local/remote identifiers are present, then the link local/remote 
Identifier TLV is included in the link descriptor.”

When the underlying IGP is IS-IS, LSP originated by the local node of the 
link MAY NOT include IPv4 interface address/IPv4 neighbor address or Link 
Local/Remote Identifiers sub-TLV in the (main) IS reachability TLV when 
MPLS Traffic Engineering is not configured for IS-IS (see Section 3.2, “
Sub-TLV 6: IPv4 Interface Address”, of [RFC5305] and Section 1.1, “Link 
Local/Remote Identifiers”, of [RFC5307], respectively). 

Thus, BGP-LS speaker MAY learn the mentioned link information, from LSP 
flooding process, without detailed interface IP/ID information of all IGP 
nodes in the BGP-LS domain.  If CONSUMER collect link-state information of 
whole domain only from one BGP-LS speaker, it can only establish one SPT , 
which root is the BGP-LS speaker. In some case, CONSUMER need create 
different SPT for different device. For example, in central spring 
network, the CONTROLLER need download ILM entry for a global label to each 
router, the ILM forwarding information is decided by each router's SPT. It 
is different for different router.
 
some solutions could be:
1) all IGP nodes in the BGP-LS domain are BGP-LS speakers, where only 
local link information need to be collected and sent to CONSUMER. 
2) one BGP-LS speaker, but all link are configured MPLS Traffic 
Engineering(not certainly including signal configuration).

Do you have any suggestions about this issue? 

thanks
deccan

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.