Re: grow: anycast ops draft

[Pekka Savola <[e-mail]>]

On Wed, 17 Nov 2004, Kurt Erik Lindqvist wrote:
> some comments and sorry for the late reply.

No problem, I reciprocated :).  I haven't commented on the issues we 
seemed to be agreeing about.

> On 2004-11-08, at 13.23, Pekka Savola wrote:
>> On Mon, 1 Nov 2004, Joe Abley wrote:
>>> Kurtis Lindqvist and I squeezed this draft through before the cut-off:
>>>
>>>  http://www.ietf.org/internet-drafts/draft-kurtis-anycast-bcp-00.txt
>> something we should be producing.  A loud 'yes' for the adoption for
>> this as
>> WG item!
>
> I saw Dave already send that out.

In case it wasn't clear, I was also opting for adopting this document 
now :).

>>    Where a routing advertisement from a node corresponds to a single
>>    Service Address, this coupling might be such that availability of
>> the
>>    service triggers the route advertisement, and non-availability of
>> the
>>    service triggers a route withdrawal.  This can be achieved using
>>    routing protocol implementations on the same servers which provide
>>    the service being distributed.
>>
>> ==> The last sentence is a required but not sufficient condition.  The
>> draft
>> should also expand the text (at least a paragraph) to say how the
>> routing
>> protocol (or some other means) monitors the "health" of the service.
>
> Geoff had the same comment and I sent some suggestion of new text to
> him, please let me know if you think that is sufficient or if you think
> we should add more text.

I checked the text and it seems OK.

>>    For services which are distributed across the global Internet using
>>    BGP, equal-cost paths are normally not a consideration: BGP's exit
>>    selection algorithm usually selects a single, consistent exit for a
>>    single destination regardless of whether multiple candidate paths
>>    exist.  Implementations of BGP exist that support multi-path exit
>>    selection, however, and corner cases where dual selected exits route
>>    to different nodes are possible.  Analysis of the likely incidence
>> of
>>    such corner cases for particular distributions of Anycast Nodes are
>>    recommended for services which involve multi-packet transactions.
>>
>> ==> I fear that the BGP ecmp has to become more prominent here. 
>> AFAICS, it's implemented and used especially for stub ASs which, 
>> for some reason, want to provide this kind of more balanced load 
>> balancing.
>
> I am not really sure how you feel ecmp should be emphasized even more?
> It's a full chapter on it's own....

I meant that the issues with ECMP should be emphasized more, in 
particular with edge networks, which try to distribute the load as 
evenly as possible (e.g., over two T1s or T3s or whatever).

Just as a suggestion, maybe one approach here might be rewording this 
a bit like:

    For services which are distributed across the global Internet using
    BGP, equal-cost paths are normally not a consideration: BGP's exit
    selection algorithm usually selects a single, consistent exit for a
    single destination regardless of whether multiple candidate paths
    exist.

    However, implementations of BGP exist that support multi-path exit
    selection, and many end-sites are using these techniques to try to
    ensure uniform outbound and inbound traffic balancing.  Analysis of
    the likely incidence of
    such corner cases for particular distributions of Anycast Nodes are
    recommended for services which involve multi-packet transactions.

>>  - the second and third paragraphes are not really accurate.  It 
>> depends on how the preferences are selected.  If you hook up an 
>> anycast node to its first-hop ISP, almost always the ISP will 
>> consider that exit preferable, so strict RPF works.  (Where it may 
>> not work is further upstream, but there strict RPF-like techniques 
>> are not applied in any case..) Even if strict RPF did not work, you 
>> could still use feasible path RPF as described in RFC3704.
>
> The case I had in mind I described in the mail to Geoff. Does that make
> the case clearer? I agree we should update the text to make it more
> clear though.

I checked the text, and I'm not still 100% sure of this case.  Are you 
describing something like:

                            [anycast node]
                                 |
                            [customer ISP/site]
                    peer         | 1)        peer
    [anycast node] ------- [ transit ISP ] ------- [peer ISP] --- [anycast node]
                     2)          | 4)         3)
                             (upstream)

Where have you envisaged that strict uRPF would be used?  1), 2), and 
3)?  Or just at 1)?

I will note that Feasible Path RPF (or its administrative trick 
equivalents) should work in all cases 1)-3): then each border router 
would see the link as preferable, but that particular preference might 
not necessarily be propagated to other routers w/ iBGP.

>> The way I see it, the biggest issue with RPF-like techniques is when
>> people
>> don't employ them, and use static access lists instead.  As anycast
>> addresses might not conform to the local topology, the guy/gal who has
>> written the ACLs might have forgotten the anycast prefix(es)
>> completely.
>
> I am assuming that if you connect an anycast service, you will also
> accept traffic to those prefixes. If you point gun to foot and pull
> trigger, you will shoot yourself in the foot...

Agree, of course.  From above, I'm not sure that strict uRPF is 
typically a problem especially if you are able to do some tricks with 
it (like assign a weight for the prefix in the ingress policy, or use 
feasible uRPF).. but rather those folks who don't have any 
'automation' at all.

>> 6.  Security Considerations
>>
>> ==> this section probably needs to discuss, with a short paragraph, 
>> issues relating to availability.  A badly implemented anycast 
>> solution has a good chance to decrease the availability rather than 
>> increase it. As any anycast node is capable of blackholing its 
>> users, it's often also good sense to provide multiple independent 
>> addresses/services to achieve the same service.  E.g., there should 
>> be a couple of addresses in DNS for service X, which would be 
>> anycasted by differerent sets of nodes.
>
> I see your point, but is that really something for a security
> considerations section?

Availability is one important aspect of security, so if this 
discussion doesn't go here, it should go into a separate subsection 
and be referred to from here.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/