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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 15 Jul 2013 21:51:15 +0000

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 16 Jul 2013 18:58:26 +0000

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:[email-masked]]
> Sent: Tuesday, July 16, 2013 2:10 AM
> To: Les Ginsberg (ginsberg); [email-masked];
> [email-masked]
> Cc: [email-masked]
> 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) [[email-masked]]
> 发送时间: 2013年7月16日 5:51
> 到: linchangwang 04414; zhanghaifeng 00645; [email-masked]
> Cc: [email-masked]
> 主题: draft-lz-isis-relax-interfaces-limit-00
> 
> Folks -
> 
> 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."
> 
> 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!

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 19 Jul 2013 01:24:12 +0000

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

> Sent: Thursday, July 18, 2013 2:57 AM
> 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
> 
> 发送时间: 2013年7月17日 2:58
> 到: zhanghaifeng 00645; linchangwang 04414; [email-masked]
> Cc: [email-masked]
> 主题: 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. :-)
> 
> 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.
> 
> 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
> 
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 25 Jul 2013 20:41:33 +0000

Haifeng -

The limitation of being DIS for more than 255 LAN cicuits only arises within the scope of a flooding domain (typically an L1 area). For the hub-spoke case, the issue would only arise if all of the following were true:

a)All spokes were placed in the same level-1 area
b)You chose to make the hub router DIS on all spoke facing interfaces

If you did that, using standard IS-IS flooding rules all spoke routers would receive all of the LSPs from all other spokes. Such a deployment would place a great burden on the spoke routers because of the size of the LSPDB - whether the spoke routers also acted as DIS on the hub facing LANs would add neglible overhead to the spoke routers as compared to the cost of maintaining such a large LSPDB.

If you don't want to burden spoke routers with the LSPDB from all other spokes (understandable) then you have two choices:

1)Place each of the spokes in a different L1 area - in which case the DIS limitation is not an issue
2)Use some proprietary implementation (as you suggest below) to suppress the sending of LSP topology info describing one spoke to other spokes. In this case as you are not exposing topology information to the spokes (specifically not sending pseudo-node LSPs) then the DIS limitation is an issue local to the hub and can be addressed by proprietary implementation on the hub.

As regards the other cases you mention below, having more than 255 neighbors is NOT equivalent to being required to be DIS for more than 255 LANs. Highlighting this is the main reason draft-ietf-isis-wg-255adj-02 was written. And being connected to more than 255 LANs is also not equivalent to needing to be DIS on more than 255 LANs.

   Les

> Sent: Thursday, July 25, 2013 2:17 AM
> For scalable hub-spoke network, those with a few LSPs will not suffer from
> heavy LSP flooding, and we can depend on database filter and advertise
> default route on the hub to mitigate the pressure on the spkoes. We have seen
> 300+ spokes in an area by using OSPF in an internet corporation's DC in
> China.
> 
> The network using virtual router which operate multiple physical devices as
> logically one, e.g. IRF of HP, more networks can be plugged in, accordingly
> the number of IS-IS neighbors probably beyond 255.
> 
> In financial networks, we saw a trend of constructing flat networks which
> decrease the number of aggregation routers to save investment, the number of
> IS-IS neighbors we saw is 200+ for now, and it's increasing.
> 
> Basically，you require 255+ LAN interfaces, you require 255+ DISs potentially.
> 
> 
> Haifeng.
> 
> 发送时间: 2013年7月19日 9:24
> We now at least agree that the only issue needing discussion is the
> limitation of being DIS for more than 255 LAN cicuits.
> 
> 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
> 
> 
> > > -------------------------------------------------------------------------
> --
> > --