Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00

"Nobo Akiya (nobo)" <nobo@cisco.com> Thu, 05 June 2014 14:42 UTC

Return-Path: <nobo@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60521A008F for <isis-wg@ietfa.amsl.com>; Thu, 5 Jun 2014 07:42:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.151
X-Spam-Level:
X-Spam-Status: No, score=-115.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eurdm7HomO4t for <isis-wg@ietfa.amsl.com>; Thu, 5 Jun 2014 07:42:33 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19CF1A017F for <isis-wg@ietf.org>; Thu, 5 Jun 2014 07:42:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8026; q=dns/txt; s=iport; t=1401979341; x=1403188941; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=J14NV8IIIsfxcZ2F2+Q4oHvRYl4cSY9ldHtT2hSclhI=; b=I9yHNyJItiTzN56DD73dThFiIaOfk5aD8vg+2h4EinTHx34vZP3v5CpB ZdPg6qWdstWaCU4JCF4rg6pe2OxZ9RLaovModGHh/nfDTHfgZcRYvpcyk 9uHog3jmYpe4Y9M3C0zRSrcQCmJql5qBul1nS+HDizOsP8pjwtps+b5F9 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFANyAkFOtJA2M/2dsb2JhbABZgmUiUliCbLhfhzkBGXQWdIIlAQEBAwEBAQEgEToLBQcEAgEIEQEDAQEBAgIGHQMCAgIfBgsUAQIGCAEBBA4FCIgmAwkIAQysbJ9+DYYNF4EqiAmDCYFlMQcGgm82gRUElgmCEIM5jAOFd4M4gi8
X-IronPort-AV: E=Sophos;i="4.98,981,1392163200"; d="scan'208";a="50523675"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP; 05 Jun 2014 14:42:18 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s55EgIoF011726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jun 2014 14:42:18 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 5 Jun 2014 09:42:18 -0500
From: "Nobo Akiya (nobo)" <nobo@cisco.com>
To: Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
Thread-Index: Ac9z2gorbAmJYe4UTpeoTQ6gc4g+PgIyyZiAAQ96rAAACcOIkP//x6aAgABHMjA=
Date: Thu, 5 Jun 2014 14:42:17 +0000
Message-ID: <CECE764681BE964CBE1DFF78F3CDD3941E1D8679@xmb-aln-x01.cisco.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <CA+b+ERmCusprkp3nYcwUtK4F0qmiv6-DogsEQ7vcJSgPRaHuPg@mail.gmail.com> <CECE764681BE964CBE1DFF78F3CDD3941E1D8412@xmb-aln-x01.cisco.com> <CA+b+ERndrSVcWmWWhHBOP==oub+V0gcMeLZ9X1dyKd9AfYHvXg@mail.gmail.com>
In-Reply-To: <CA+b+ERndrSVcWmWWhHBOP==oub+V0gcMeLZ9X1dyKd9AfYHvXg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [161.44.212.71]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/jrZ6uwIgIGxsJtevXna0iCu-ErQ
Cc: "draft-xu-isis-mpls-elc@tools.ietf.org" <draft-xu-isis-mpls-elc@tools.ietf.org>, "isis-chairs@tools.ietf.org" <isis-chairs@tools.ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 14:42:39 -0000

Hi Robert,

Please see in-line.

> -----Original Message-----
> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert
> Raszuk
> Sent: Thursday, June 05, 2014 9:43 AM
> To: Nobo Akiya (nobo)
> Cc: Xuxiaohu; isis-chairs@tools.ietf.org; draft-xu-isis-mpls-
> elc@tools.ietf.org; isis-wg@ietf.org
> Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
> 
> Hi Nobo,
> 
> Well the range size would be as big as most ECMP paths you have. Say
> 32 or 64 as example.
> 

Number of ECMP paths doesn't necessary equal to number of hash buckets in implementations. In addition, SID advertising node would need to be aware of upper bound ECMP paths (and hash buckets) from all [potential] ingresses to itself in order to advertise the right number of SIDs ... or always advertise _max_ number of SIDs for ECMP.

> As to the forwarding table size in the core it is rather implementation
> dependent .. you really do not need to do exact match for all labels in a
> range (unlike with atomic 20 bit wide MPLS label) it is still much less then
> you have entries on the ingress and egress .. as those are in millions.

Still, in an SR network consisting of 100 nodes ... each network node used to have 100 node SID forwarding entries (assuming one SID advertised per node) but now each network node will have 3200 or 6400 or 12800 node SID forwarding entries. That's a huge increase. Sure the forwarding table can do some aggregation but number of "resources" reserved, consumed, advertised and OAM requires to support them are still enlarged significantly.

I still see tackling EL to be appealing :)

Thanks!

-Nobo

> 
> Cheers,
> R.
> 
> 
> On Thu, Jun 5, 2014 at 3:15 PM, Nobo Akiya (nobo) <nobo@cisco.com>
> wrote:
> > Hi Robert, Xu,
> >
> >> That means that perhaps one could really analyze if the tuple ELI +
> >> EL (one or
> >> many) is that much needed as opposed to advertise wider range of SIDs
> >> and simply use those in flat layer for loadbalancing reasons ?
> >> Just mapping different flows on ingress to different label from said range.
> >
> > That's an interesting idea, but I'd like to highlight one down side. "wider
> range of SIDs" will likely have to be fairly large/wide to have good
> probability of good ECMP distribution throughout the network, and that will
> likely result in a significant increase in forwarding table in every network
> nodes. Obvious side effects include increased SRGB, increased memory
> usage, debugging difficulty, increased number in in-band-OAM to test all
> forwarding entries.
> >
> > Considering above, perhaps fitting in EL to MPLS based SR is still a
> reasonable option to discuss. It's not a trivial topic, but I think this is an
> important topic that has lacked attention.
> >
> > Xu, I think draft-xu-isis-mpls-elc should have a reference to draft-kini-
> mpls-spring-entropy-label. And I agree with Stephane, there's minimal
> benefit in progressing draft-xu-isis-mpls-elc before draft-kini-mpls-spring-
> entropy-label.
> >
> > Thanks.
> >
> > -Nobo
> >
> >> -----Original Message-----
> >> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Robert
> >> Raszuk
> >> Sent: Thursday, June 05, 2014 8:25 AM
> >> To: Xuxiaohu
> >> Cc: isis-chairs@tools.ietf.org;
> >> draft-xu-isis-mpls-elc@tools.ietf.org; isis- wg@ietf.org
> >> Subject: Re: [Isis-wg] Request for WG adoption of
> >> draft-xu-isis-mpls-elc-00
> >>
> >> Hi Xu,
> >>
> >> Actually let me express an opinion that while for other MPLS
> >> signalling protocols the concept of entropy label as describe in RFC
> >> 6790 may be useful I would rather question if the same applies to
> >> segment routing architecture.
> >>
> >> Fundamental difference here is that other MPLS signalling protocols
> >> bind labels to FECs. SR on the other hand binds SIDs (which one of
> >> the special case of can be label) to nodes or links. That means that
> >> number of such bindings will naturally be orders of magnitude less in the
> SR concept.
> >>
> >> That means that perhaps one could really analyze if the tuple ELI +
> >> EL (one or
> >> many) is that much needed as opposed to advertise wider range of SIDs
> >> and simply use those in flat layer for loadbalancing reasons ?
> >> Just mapping different flows on ingress to different label from said range.
> >>
> >> Also that not only can accomplish egress node loadbalancing, but also
> >> all via nodes will have no problem with such input to a hash function
> >> regardless if they are SR capable or not ?
> >>
> >> Maybe rather then copying all fixes of MPLS original architecture to
> >> SR its better to adjust SR architecture to at least not repeat the
> >> same mistakes we have already made in the past ?
> >>
> >> Comments ?
> >>
> >> Cheers,
> >> R.
> >>
> >>
> >>
> >> On Sat, May 31, 2014 at 10:05 AM, Xuxiaohu <xuxiaohu@huawei.com>
> >> wrote:
> >> > Hi WG co-chairs,
> >> >
> >> > This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00)
> >> > describes
> >> how to advertise the MPLS Entropy Label Capability (ELC) using IS-IS
> >> in SPRING networks. Since
> >> (http://tools.ietf.org/html/draft-ietf-isis-segment-
> >> routing-extensions-00) has been adopted as a WG draft, as co-authors
> >> of draft-xu-isis-mpls-elc-00, we hope you could consider the WG
> >> adoption for this draft as well.
> >> >
> >> > Best regards,
> >> > Xiaohu (on behalf of all-authors)
> >> >
> >> > _______________________________________________
> >> > Isis-wg mailing list
> >> > Isis-wg@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/isis-wg
> >>
> >> _______________________________________________
> >> Isis-wg mailing list
> >> Isis-wg@ietf.org
> >> https://www.ietf.org/mailman/listinfo/isis-wg