Re: [Isis-wg] draft-lz-isis-relax-interfaces-limit-00

["Les Ginsberg (ginsberg)" <[e-mail]>]

Haifeng -

RFC5303 does interoperate w legacy systems - if the neighbor does not support the extension (as indicated by the lack of the 3way TLV in IIHs) then adjacency formation reverts to ISO 10589 rules. See the last paragraph in Section 2.1.

draft-ietf-isis-wg-255adj-02 strategy can be used with or without RFC 5303. If used without RFC 5303 and you want to support more than 255 P2P circuits then some circuit ID reuse will occur which has some risks. The question then is if you want to eliminate the risks should we use RFC 5303 - which is widely implemented and deployed and proven to be interoperable - or should we define a new protocol extension? I think the answer to that is obvious. :-)

What remains is the limitation of being DIS for more than 255 LAN cicuits. 

The solution you have proposed is flawed. To appreciate why you have to closely read RFC 3786 - particularly Section 5. This requires that when operating in Mode 2 (the only mode which allows IS Neighbor advertisements other than an advertisement between the originating IS and the associated virtual ISs to be included in Extended LSPs) the originating LSP set and the associated extended LSP sets MUST be added to PATHS as one logical set of LSPs. Failure to do so introduces subtle issues in ECMP cases. Since legacy systems would not have this SPF modification only Mode 1 could safely be used until such time as all ISs in the area/domain were upgraded. When RFC 5311 was written Mode 2 was eliminated because we preferred a solution which was always interoperable with legacy systems and the scalability issues Extended LSPs are meant to address do not require IS Neighbor advertisements to be included in Extended LSPs.

Your proposal however REQUIRES that IS Neighbor advertisements be included in Extended LSPs - which reintroduces the issues associated with RFC 3786 Mode 2 operation. I repeat - this is NOT supported by RFC 5311 - quite intentionally so.

More importantly, there is no demonstrable need to solve the limitation of being DIS for more than 255 LAN cicuits.

If there is ever is a need to address the limitation of being DIS for more than 255 LAN cicuits there are other proposals out there which could be used to address this issue - albeit not in a way which is interoperable with legacy systems. But your proposal is also not interoperable with legacy systems as I have explained above.

In short, the problems which you are trying to address have either already been addressed or don’t need to be addressed.

   Les


> -----Original Message-----
> From: Zhanghaifeng [mailto:[e-mail]]
> Sent: Tuesday, July 16, 2013 2:10 AM
> To: Les Ginsberg (ginsberg); [e-mail];
> [e-mail]
> Cc: [e-mail]
> Subject: Re: draft-lz-isis-relax-interfaces-limit-00
> 
> 
> Thanks for comments!
> 
> The restriction we stated is about rfc5303, rfc5303 just extends the
> interface space of P2P, and can not interoperate with the legacy systems do
> not support that extension.
> 
> draft-ietf-isis-wg-255adj-02 also has restriction, We can't support more than
> 255 DISs simultaneously with it, and to P2P network, because using the same
> circuit-ID, there's side-effect stated in the text which later solved by
> rfc5303:
> "   point-to-point interfaces have been supported by sending the same
>    circuit ID on multiple interfaces. This reduces the robustness of
>    the ID change detection algorithm, since it would then be possible to
>    switch links between interfaces on a system without detecting the
>    change."
> 
> To our proposed solution,  it's a parallel way to rfc5311, Virtual IS in the
> latter is used to extend the LSP space, while Extending IS in the former is
> only used to extend the interface space, there's no intersection between
> Virtual ISs
> and Extending ISs, IOW, our solution does not depend on rfc5311. The
> interface exceeding 255 limit is enabled IS-IS in the name of Extending IS,
> from the point view of remote router, originating IS and Extending IS are
> separated ISs, because Originating IS and Extending IS will advertise NBR TLV
> with cost 0 bidirectionally, so 2-way check will not fail.
> 
> -Haifeng
> ________________________________________
> 发件人: Les Ginsberg (ginsberg) [[e-mail]]
> 发送时间: 2013年7月16日 5:51
> 到: linchangwang 04414; zhanghaifeng 00645; [e-mail]
> Cc: [e-mail]
> 主题: draft-lz-isis-relax-interfaces-limit-00
> 
> Folks -
> 
> In regards to your recent draft submission:
> 
> http://tools.ietf.org/html/draft-lz-isis-relax-interfaces-limit-00
> 
> You state that the solution described long ago in
> http://tools.ietf.org/html/draft-ietf-isis-wg-255adj-02
> 
> "...suffers from restrictions required to maintain interoperability with
> systems that do not support the extensions."
> 
> Please elaborate on what these restrictions are and what interoperability
> issues have been seen in the field.
> 
> To my knowledge the problem you are trying to solve does not exist.
> 
> Also, in regards to your proposed solution, if you advertise IS-neighbors in
> the extended LSPs you will find this is not fully interoperable with ISs
> which do not support the proposed extension. This is why RFC 3786 originally
> proposed two operating modes. In mode 1 (fully interoperable w legacy
> systems) the only IS-neighbor which could be advertised in extended LSPs was
> a neighbor to the Originating IS. In Mode 2 this restriction was removed but
> it required a change in the SPF algorithm and therefore the entire network
> needed to be upgraded.  In RFC 5311 (which obsoleted RFC 3786) Mode 2 was
> removed and only Mode 1 is supported. But your proposal REQUIRES that
> extended LSPs advertise the IS-neighbors which were formed using the
> additional system-id (otherwise 2-way connectivity check will fail). This is
> NOT supported by RFC 5311.
> 
>    Les
> -----------------------------------------------------------------------------
> --------------------------------------------------------
> 本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出
> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
> 邮件！
> This e-mail and its attachments contain confidential information from H3C,
> which is
> intended only for the person or entity whose address is listed above. Any use
> of the
> information contained herein in any way (including, but not limited to, total
> or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender
> by phone or email immediately and delete it!