Re: [Rift] [RIFT][Non equal cost anycast]

<xu.benchong@zte.com.cn> Mon, 29 July 2019 02:01 UTC

Return-Path: <xu.benchong@zte.com.cn>
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA5812004C for <rift@ietfa.amsl.com>; Sun, 28 Jul 2019 19:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 fRqzknyAC1N0 for <rift@ietfa.amsl.com>; Sun, 28 Jul 2019 19:01:47 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFC29120044 for <rift@ietf.org>; Sun, 28 Jul 2019 19:01:46 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 0FEC5D457705A5CECB26; Mon, 29 Jul 2019 10:01:44 +0800 (CST)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl2.zte.com.cn with SMTP id x6T21dZI027642; Mon, 29 Jul 2019 10:01:39 +0800 (GMT-8) (envelope-from xu.benchong@zte.com.cn)
Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid201; Mon, 29 Jul 2019 10:01:32 +0800 (CST)
Date: Mon, 29 Jul 2019 10:01:32 +0800 (CST)
X-Zmail-TransId: 2af95d3e537c8fe0df45
X-Mailer: Zmail v1.0
Message-ID: <201907291001327532177@zte.com.cn>
In-Reply-To: <CA+wi2hMg6gx_nnHCu7iP9S3snAjL=qAWObx3Hh=bUgzF=vz+3A@mail.gmail.com>
References: 201907261737515797054@zte.com.cn, CA+wi2hMg6gx_nnHCu7iP9S3snAjL=qAWObx3Hh=bUgzF=vz+3A@mail.gmail.com
Mime-Version: 1.0
From: <xu.benchong@zte.com.cn>
To: <tonysietf@gmail.com>
Cc: <prz@juniper.net>, <rift@ietf.org>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn x6T21dZI027642
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/4x6nOfmzOYeZcZizLA1FjZ0FsVw>
Subject: Re: [Rift] =?utf-8?q?=5BRIFT=5D=5BNon_equal_cost_anycast=5D?=
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Routing in Fat Trees <rift.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rift>, <mailto:rift-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rift/>
List-Post: <mailto:rift@ietf.org>
List-Help: <mailto:rift-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rift>, <mailto:rift-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jul 2019 02:01:50 -0000

Tony

Does this mean that when S-SPF calculate, we cannot select the best nexthop with the smallest distance, all the nexthops must be added to the forwarding table, and distance is used as the basis for “Non equal cost anycast” on the forwarding plane.

N-SPF uses the method of 5.3.6.1 and the BAD instead the distance.




--Benchong










原始邮件



发件人:TonyPrzygienda <tonysietf@gmail.com>
收件人:徐本崇10065053;
抄送人:Antoni Przygienda <prz@juniper.net>;rift@ietf.org <rift@ietf.org>rg>;
日 期 :2019年07月27日 03:34
主 题 :Re: [Rift] [RIFT][Non equal cost anycast]



Benchong, as always, when people start implement they start to ask the real questions ;-) Yes, any cast in RIFT is much closer to what you would consider “true any cast” than IP is which is really just ECMP on same address. In RIFT anycast on different distance nodes is a normal thing. 

First, it it important to understand the difference between mobility and any cast on the fabric. if a prefix moves on the fabric without using the mobility attributes it can appear in two locations @ once of course (if the new TIE floods faster than the previous location manages to purge the prefix). That's not a proper anycast of course, that's just an artefact. If the prefix properly attaches timestamps by some means (such as 6lo) it will be understood as having moved, otherwise it will be any cast for a bit. 


And then, of course there is true any cast which is equal to two prefixes advertised from two nodes being equal. RIFT is loop-free which means that it doesn’t really care all that much about distance so if a packet enters from ToF it can be forwarded to any leaf showing any cast. That allows true “service on any cast” architecture. In case when you route from the leaf the packet will use default (unless an implementation does their own things the spec doesn’t mention but doesn’t suppress either) until it pops up far enough it sees any cast @ which point in time it will turn the packet south (assuming all anycast is on leafs). if balancing of any cast over whole metric is desired then the packet needs to be pushed all the way to the ToF using tunnels or some other solution. 


So, basically, any cast is just a funky next-hop on a prefix that can point to two different nodes & metric can be used to balance or ignored and the spec does not need to say more I think. 


This little diatribe should make it into RIFT applicability statement in some form I think ... 


-- tony 





On Fri, Jul 26, 2019 at 5:57 AM <xu.benchong@zte.com.cn> wrote:



Hi,Tony

Can you talk about REQ6, How does RIFT support it? Is it benefiting from the default route?

"  REQ6:    Non equal cost anycast must be supported to allow for easy

            and robust multi-homing of services without regressing to

            careful balancing of link costs."





Thank you!


Benchong






_______________________________________________
 RIFT mailing list
 RIFT@ietf.org
 https://www.ietf.org/mailman/listinfo/rift