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

"Nobo Akiya (nobo)" <nobo@cisco.com> Fri, 06 June 2014 00:12 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 DFD971A0363 for <isis-wg@ietfa.amsl.com>; Thu, 5 Jun 2014 17:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.152
X-Spam-Level:
X-Spam-Status: No, score=-115.152 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, SPF_PASS=-0.001, 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 MrTLHb9jtJUw for <isis-wg@ietfa.amsl.com>; Thu, 5 Jun 2014 17:12:13 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F221A035B for <isis-wg@ietf.org>; Thu, 5 Jun 2014 17:12:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3446; q=dns/txt; s=iport; t=1402013527; x=1403223127; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ix1J4YwFQl9tj8ITPCylaLGLvsp5T1ITYUf7lP4LTJE=; b=CrWxCnGfq7NUtkSTrojjfEWbl8Js+rpXsuMwJ/Cp4uocPdXaR9vk0cIV 23/OpqQQiJe8MpUb7Rt+IzQQhPLQWRpsvMZlsUU09fKYizFeesWmQarzo bImQj+nwefTHW6DYJ27GPFgfVS6R9PZC2aQjtru1smsAgsGkUc1DxoDPf E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag8FAHYGkVOtJV2S/2dsb2JhbABZgmUiUliCbMAqARlvFnSCJQEBAQMBDhURMRQFCwIBCBIIAgYLFQICAjAVAg4CBA4NiDIIAQytCKV+F4EqjHcxBwqCazaBFQSbUpF6gziCLw
X-IronPort-AV: E=Sophos;i="4.98,984,1392163200"; d="scan'208";a="50674899"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP; 06 Jun 2014 00:12:06 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s560C66N023481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jun 2014 00:12:06 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 5 Jun 2014 19:12:06 -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//x6aAgABHMjD//8tngIAADs+A///kHmCAAJU4AIAAQprw
Date: Fri, 6 Jun 2014 00:12:06 +0000
Message-ID: <CECE764681BE964CBE1DFF78F3CDD3941E1D9087@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> <CECE764681BE964CBE1DFF78F3CDD3941E1D8679@xmb-aln-x01.cisco.com> <CA+b+ERnX+mVwnWf-jtZEUYRuZhEU-VmztrdObfdwmzrXz=erVQ@mail.gmail.com> <A1E50D8AD6310E47A6C10F075AEDC022017C54BB60@ONWVEXCHMB01.ciena.com> <CECE764681BE964CBE1DFF78F3CDD3941E1D8F3C@xmb-aln-x01.cisco.com> <CA+b+ERkRLR5+3Qn1d8gSn0zPeEh5eCFTTddb1zwTDMr5se1=zg@mail.gmail.com>
In-Reply-To: <CA+b+ERkRLR5+3Qn1d8gSn0zPeEh5eCFTTddb1zwTDMr5se1=zg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.243.16]
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/rBTkTQ1zdYoNPmPrFW0X2dvxkQk
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: Fri, 06 Jun 2014 00:12:15 -0000

Hi Robert,

Please see in-line.

> Hi Nobo,
> 
> Inline ...
> 
> > In MPLS, there's no standards in load balancing. Meaning an
> > implementation may load balance only on the top label, only on the
> > bottom label or set of labels which may or may not be the entire label
> > stack.
> 
> Practically I do not know any implementation which would ignore top label
> as an input for hash, but you are correct that there is no standard and that
> such implementation is possible in theory.
> 
> > To take this into account, every SID advertised will need to be
> > advertised as a "range", even service SIDs.
> 
> Nope. I do not think this needs to be extended to service SIDs at all.
> After all services require transport and transport SIDs is all we care about for
> IP/MPLS loadbalancing.

If (and only if) there is an implementation that load balances only on the bottom label, then service SID is what gets used for load balancing.

> 
> > And what you are suggesting is that the "range" needs to be 7 or 8
> > bits out of 20 bits.
> 
> 5 bits gives option for 32 ECMP paths, 6 - 64, 7-128 that should do it :)

That (7 bits) will realistically be sufficient, although this will be break if someone has >128 hash buckets.

> 
> > Yes even SID advertisements can be optimized to take the "range" into
> > account, but still a very big link/service label space & SRGB is
> > required for this.
> 
> I think for v6 forwarding this is clearly beneficial. Hence such optimization in
> SR architecture is welcome.

For v6, this sounds good.

> 
> If MPLS is going to benefit from it remains to be seen or agreed up on. I was
> just trying to share quick thought which just came up when reading this
> thread.

Yes and it's great that this topic is finally getting much-needed discussions ... although we need a lot more :)

One other thing that I'd like to point out is that EL is the first thing that has come close to standardizing the load balancing on MPLS data plane, and it is setting up the "infrastructure" for improved OAM techniques (ex: CC per ECMP path). Whether we go with EL or something else on MPLS based SR, I think it'll be very beneficial to really think about the OAM angle.

Thanks for interesting discussion!

-Nobo

> 
> >> Is this still more appealing then say mpls over UDP draft ;-) ?
> >> http://tools.ietf.org/html/draft-ietf-mpls-in-udp-05
> >
> > I prefer not to get into this topic for now :)
> 
> :-)
> 
> Cheers,
> R.