[Isis-wg] Comments on draft-chen-isis-sl-overheads-reduction-00.txt

[Christian Hopps <[e-mail]>]

Hi Zhe,

So to expand on what was mentioned in the meeting. This solution is
specifically changing the base standard in an incompatible way to
accomplish it's goal. Multiple area addresses are a case in the base
standard used for:

7.1.5 Manual area addresses

    Within a routeing domain, it is often convenient to associate more
    than one area address with an area. There are a number of reasons
    why assigning more than one area address may be useful, including
    the following.

    a) There may be more than one addressing authority involved in the
    assignment of addresses in the routeing domain, yet it is not
    efficient to require a separate area for each addressing domain.

    b) At times it may be necessary to reconfigure a routeing domain by
    dividing an area into two of more areas, or combining a number of
    areas into a single area. These reconfigurations could not be done
    during normal routeing domain operation if only a single area
    address per area were permitted.

You'll also run into problems with maximumAreaAddresses which has been 3
(or the value 0 which implies 3) for so long that it may be invariant in
deployed implementations. In any case this value would have to be
changed to be greater than the maximum number of leaf nodes on all
routers b/c:

IIH's
8.2.5.2 (a.1) If the Maximum Area Addresses field of the PDU is not
    equal to the value of the IS’s maximumAreaAddresses then the PDU
    shall be discarded and a maximumAreaAddresses-Mismatch event
    generated, unless the IS only implements a value of three for
    maximumArea-Addresses, in which case this check may be omitted.

LSPs
7.3.15.1 (a.5):
    If this is a level 1 LSP, and the Maximum Area Addresses field of
    the PDU is not equal to the value of the IS’s maximumAreaAddresses
    then the PDU shall be discarded and a maximumAreaAddresses-Mismatch
    event generated, unless the IS only implements a value of three for
    maximumArea-Addresses, in which case this check may be omitted.

SNP
[same] ...

Thanks,
Chris.

Chenzhe (NGIP Lab) <[e-mail]> writes:

> Hi all,
>
> A New Internet draft has been submitted. Any comments are welcome.
>
> Best regards,
> Zhe
>
> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]]
> 发送时间: 2017年1月6日 17:39
> 收件人: Chenzhe (NGIP Lab) <[e-mail]>; Xuxiaohu <[e-mail]>
> 主题: New Version Notification for draft-chen-isis-sl-overheads-reduction-00.txt
>
>
> A new version of I-D, draft-chen-isis-sl-overheads-reduction-00.txt
> has been successfully submitted by Zhe Chen and posted to the IETF repository.
>
> Name:		draft-chen-isis-sl-overheads-reduction
> Revision:	00
> Title:		Overheads Reduction for IS-IS Enabled Spine-Leaf Networks
> Document date:	2017-01-06
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-chen-isis-sl-overheads-reduction-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-chen-isis-sl-overheads-reduction/
> Htmlized:       https://tools.ietf.org/html/draft-chen-isis-sl-overheads-reduction-00
>
>
> Abstract:
>    When a Spine-Leaf topology adopts the Intermediate System to
>    Intermediate System (IS-IS) routing protocol, the Leaf node receives
>    Link State Packets (LSPs) from all the other nodes thus having the
>    entire routing information of the topology.  This is usually
>    considered unnecessary and costly.  This document describes a
>    solution to this problem by assigning different area identifiers
>    (AIDs) to the Leaf nodes.  The solution requires that an IS-IS router
>    SHOULD check a Level-1 LSP's AIDs before it advertises the LSP to its
>    neighbor.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg