Re: [OSPF] Re: [AOSPF] Anycast Extension to OSPFv3 (draft-wang-aospf-00) - Authors' Technical Considerations

Naiming Shen <naiming@cisco.com> Fri, 29 December 2006 23:35 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0RGJ-0008Tm-Oc; Fri, 29 Dec 2006 18:35:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0RGI-0008Tc-Rh for OSPF@ietf.org; Fri, 29 Dec 2006 18:35:42 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0RGH-0004nt-Gv for OSPF@ietf.org; Fri, 29 Dec 2006 18:35:42 -0500
Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 29 Dec 2006 15:35:41 -0800
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kBTNZeYu023147; Fri, 29 Dec 2006 15:35:40 -0800
Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kBTNZRUH020523; Fri, 29 Dec 2006 15:35:36 -0800 (PST)
Message-ID: <4595A644.2060107@cisco.com>
Date: Fri, 29 Dec 2006 15:35:32 -0800
From: Naiming Shen <naiming@cisco.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: curtis@occnc.com
Subject: Re: [OSPF] Re: [AOSPF] Anycast Extension to OSPFv3 (draft-wang-aospf-00) - Authors' Technical Considerations
References: <200612292134.kBTLYCtE040008@workhorse.brookfield.occnc.com>
In-Reply-To: <200612292134.kBTLYCtE040008@workhorse.brookfield.occnc.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2619; t=1167435340; x=1168299340; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=naiming@cisco.com; z=From:=20Naiming=20Shen=20<naiming@cisco.com> |Subject:=20Re=3A=20[OSPF]=20Re=3A=20[AOSPF]=20Anycast=20Extension=20to=2 0OSPFv3=20(draft-wang-aospf-00)=0A=20-=20Authors'=20Technical=20Considerat ions |Sender:=20; bh=7vc/J72Ia4Z8qfw/iBp9rJu9CknvbeWkd8uPGBZTAfk=; b=rXvnj8yZR6LCIkkC4FSIeBBA6H0+wxlBkMVCUOBPnO/4lrZMow7mIZVE4RJVMPkHGSGWEFxv LS0X8WiJ4Z0KveFDQa8QnDTrUVoEESW4iScVP4+B4MZi4jAC8NL9+8RU;
Authentication-Results: sj-dkim-8; header.From=naiming@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: OSPF List <OSPF@ietf.org>
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org


Curtis Villamizar said the following on 12/29/2006 01:34 PM:
> In message <4594A87C.6090204@cisco.com>
> Naiming Shen writes:
> 
>>>It is unfortunate that routers still allow per-packet ECMP to be
>>>configured.  At least providers know not to use this feature.  But we
>>>can all be sure that somewhere out there someone ignorant of the
>>>problems has enabled it.
>>
>> 
>>I completely agree. Per-packet ECMP should not be used normally,
>>especially in provider's networks. But I did experience some cases
>>( a while ago ) on international links, there were some dominant
>>prefixes which led to very uneven link bandwidth usages due to flow
>>based algorithm. I think if folks in the routing area still think
>>things like anycast having this issue, then to signal this attribute is
>>useful and can be easily done; otherwise, there is absolutely no issue
>>in terms of anycast prefiexes(ipv4 or ipv6).
> 
> 
> 
> Maybe you missed the point.  The alternative to per-packet ECMP is not
> per-prefix ECMP.  The hash based ECMP is only uneven if one or a small
> number of host pairs dominate the traffic flow.
> 
> The only time that it mattered was when one dominante vendor didn't
> offer hash based ECMP.  Per-prefix ECMP could be very uneven.  That
> was a decade ago.

The majority of the router software now is certainly 4-tuple based hash,
but it does not mean in all the cases even load distribution can be
achieved.

> 
> As far as anycast goes even with per-packet ECMP, everything is fine
> if the application can send one packet that is returned with the
> unicast address of an anycast server and use the unicast address from
> then on.  This sort of probe can be repeated periodically if

Sure, then this involves application awareness of anycast knowledge
and explicit configuration, it's error-prone to say the least.
That would certainly be a big restriction.

> necessary.  A load influenced anycast could be done within an IGP by
> changing a cost but load might tend to slosh (all to one server, then
> another).  What might work better for that would be an underlying
> multicast with limited TTL (reaches multiple close servers, all of
> which respond with their loadings).  Limited deployment of multicast
> might be an issue and non-optimality of a multicast tree with fixed RP
> might also be an issue.  There are plenty of tools in the tool box to
> implement an anycast end user service without resorting to a new
> address type and any change to routing.
> 
> The WG is OSPF and we're off topic at this point.

Agreed.

- Naiming

> 
> Curtis

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf