For operation of the base protocol, there is no need for IS-IS to advertise parallel adjacencies to the same neighbor nor to advertise link attributes such as local/remote L3 addresses i.e., it is not required to build a correct SPT. So historically implementations may have chosen to suppress these advertisements (thus saving LSP space and potentially some unnecessary LSP updates) unless there was a use case for the link attribute information. TE enablement clearly required advertisement of such information. The use of Segment Routing also requires such advertisement.
There is certainly nothing to prevent any implementation from advertising such information even in the absence of enablement of a feature like TE.. It creates no interoperability issues. So I think the issue raised is easily addressed without requiring either of the suggested solutions below. Les > -----Original Message----- > From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Hannes > Gredler > Sent: Friday, August 21, 2015 2:41 AM > To: peng.sha...@zte.com.cn > Cc: i...@ietf.org; spring@ietf.org; isis...@ietf.org > Subject: Re: [Isis-wg] questions about draft-ietf-idr-ls-distribution-11 > > hi peng, > > On Thu, Jul 02, 2015 at 10:13:57AM +0800, peng.sha...@zte.com.cn wrote: > | 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? > > i'd be in favour of 1) - /hannes _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
