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

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

Haifeng -

We now at least agree that the only issue needing discussion is the limitation of being DIS for more than 255 LAN cicuits.

You have cited two deployment cases that you believe require the protocol limitation to be addressed:

1)Data Center

For this to be an issue in datacenter you would need a deployment where a single IS is connected to more than 255 LANs - all of which are being used in multi-access mode (NOT P2P mode) - and for which it is required that the same IS be DIS in all cases. I know of no expected datacenter deployment case which comes close to this requirement. Certainly datacenter networks can be large and scale to many routers and links - but that does not imply that a single IS would be required to be DIS on 255+ LAN circuits.

2)Hub-spoke

Scale Hub-spoke networks present challenges to link state routing protocols. For the 255 LAN cicuit limitation to be an issue you would have to deploy more than 255 spokes connected to the same hub - all in the same L1 area. This would introduce other significant issues (e.g. heavy LSP flooding requirements to the spokes) which would be undesirable and require the ISs on the spokes to meet much greater scale requirements. This is not a deployment solution that I would recommend.

So I am still not convinced that there is a demonstrable need to solve the limitation of being DIS for more than 255 LAN cicuits.

   Les


> -----Original Message-----
> From: Zhanghaifeng [mailto:[e-mail]]
> Sent: Thursday, July 18, 2013 2:57 AM
> To: Les Ginsberg (ginsberg); [e-mail];
> [e-mail]
> Cc: [e-mail]
> Subject: Re: draft-lz-isis-relax-interfaces-limit-00
> 
> 
> Les,
> 
> What I call RFC 5303 is NOT interoperable is that if the remote router
> doesn't support RFC 5303, it's no way to extend P2P interface space. BTW,
> what we interested is the LAN interface, so put RFC 5303 aside.
> 
> There do have requirement of 255+ DIS in network like data center, or some
> large hub-spoke networks which hub router always undertake the role of DIS
> according to the consideration of performance.
> 
> Now, let's make it more clear about the interoperability of our proposed
> solution.
> 
> Extending IS in our solution is totally different with Virutal IS defined in
> RFC 5311, see the figure bellow:
>    +-------------------+                  +------------------+
>    |    Virtual System    |                    |  Virtual System     |
>    |     system-id   = S' |                    |   system-id   = S''  |
>    |       is-alias-id = S  |                    |   is-alias-id = S     |
>    +-------------------+                  +-------------------+
>              |    /\                                              |    /\
>   cost=0 |    |cost=max-1                 cost=0 |    |cost=max-1
>              |    |                                               |    |
>             \/    |                                               \/   |
>    +--------------------------------------------------+
>    |                   Originating System                              |
>    |                      system-id = S                                  |
>    |
> |
>    +--------------------------------------------------+
>                |    /\                                 |    /\
>    cost=0  |    |cost=1            cost=0 |     |cost=1
>                |    |                                   |     |
>               \/    |                                  \/    |
>    +-------------------+          +-------------------+
>    |   Extending System |           |  Extending System  |
>    |      system-id   = E' |           |  system-id   = E''    |
>    |                               |           |
> |
>    +-------------------+         +-------------------+
>        /        \                                        /       \
>       I'1 ...   I'255                             I"1  ... I"255
>      /            \                                   /           \
>     R'1           R'255                      R"1          R"255
> 
> Extending IS works almost samely to Original IS, hellos with remote router
> R'/R" with Extending system-id which must be different with Virtual IS. So IS
> neighbor can be advertised in the Extending IS's LSP and will not reintroduce
> the the issues associated with RFC 3786 Mode 2 operation. It's interoperable
> even with legacy system that do not support RFC 3786/5311 except the
> restriction bellow:
> 
> Do not support ECMP that multiple interfaces plugged in from different
> Systems.
> 
> <We find cost 0 between Original IS and Extending IS bidirectionally may not
> interoperable with legacy system that do not support iSPF when ECMP, we
> planned to redefine one way(Extending IS --> Original IS) to 1 as described
> above.>
> 
> Haifeng
> 
> ________________________________________
> 发件人: Les Ginsberg (ginsberg) [[e-mail]]
> 发送时间: 2013年7月17日 2:58
> 到: zhanghaifeng 00645; linchangwang 04414; [e-mail]
> Cc: [e-mail]
> 主题: RE: draft-lz-isis-relax-interfaces-limit-00
> 
> 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!