Subject: Re: grow: draft-ietf-grow-anycast

From: Tom Sanders <[email-masked]>
Date: Fri, 26 Aug 2005 12:41:50 +0530

>    _____
>    (     )
>   ( a   a )
>    (     )
>     0___0
>     |   |
>     1   1
>      \ /
>       2

> Two anycast instances exist in AS 0.  Each border router advertises
> the prefix for a.  2, in the above example, is the first chance for
> ecmp.  As long as 2 deterministically sends its traffic for a given
> flow to the same peer, we don't have a problem.   If we don't send
> them deterministically, we have a problem.

Is this really an issue. Most of the boxes can do this pretty neatly.
This is after all what we mean by a "flow". All traffic that hits the
"flow" gets forwarded to the same nexthop.

> If there's just one instance of a, then the traffic iwill
> consistently end up at that a regardless of the path.  Most vendors
> will be sane enough to insist that the bgp paths are otherwise
> identical.  You not only have to have them be identical, you must
> have the flow directed deterministically.  You can skip this last
> step if a wont have multiple instances.

I may have misunderstood you so please correct me if thats indeed the
case. Even if there is only one instance of "a", 2 can still do ecmp.
It can send traffic destined to "a" via the two attachment points to
1.

> In the cases where a is present from multiple origin ASes, I'm not aware
> of a BGP ecmp implementation that will load balance the traffic.

Ok. Is this the scenario that you're talking of?

a (AS 7)  b (AS 8)
|              |
 \            /
   \        /
   1     1 (AS)
     \    /
      \ /
       2 (AS)

"a" is present in ASes 7 and 8 respectively. 2 routers in AS 1 can
reach both these routers.

This is an interesting case. 

1, in this example, should tells other ASes that it can reach two
instances of "a". It needs to advertise information aboout AS 7 and AS
8 to avoid AS path loops. It has to tell everyone about this.

> While I'm sure you can say your implementation "does the right thing"
> and the $OTHER_LARGE_VENDOR "does the right thing", it's hard to say
> that everyone does the right thing.  If anyone doesn't, there's a problem.

Yes.

> Honestly, just given normal Internet topology changes, relying on
> a given path to a given anycast instance being stable for a large
> traffic flow seems somwehat unlikely.  But I'll leave it to those who
> keep such statistics to speak on the subject.

>> There is no reason why BGP needs or should treat "anycast" different
>> from unicast... in fact it MUST NOT know whether there is more than one
>> advertisement for a prefix. This kind of text is harmful.

I can think of a scenario when you MUST tell others if you have more
than one advertisement for a prefix. If a prefix has been learnt from
two different sources (ASes) AND if you want to distribute the flows
across these ASes then you *need* to tell othes about these two paths,
for them to run their loop detection algorithm.

Thanks
Toms.

_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/

---

From: Patrick Verkaik <[email-masked]>
Date: Fri, 26 Aug 2005 01:53:59 -0700 (PDT)

> for them to run their loop detection algorithm.

Doesn't AS_SET cover this case?

	Patrick

---

From: Tom Sanders <[email-masked]>
Date: Fri, 26 Aug 2005 19:02:38 +0530

> Doesn't AS_SET cover this case?

But now you bunch all the ASes togethar and you lose all AS path
granularity that you had. As a side effect, you lose all information
to run your AS Path regular expressions against.

Toms.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 26 Aug 2005 10:30:32 -0400

Tom,

> "flow" gets forwarded to the same nexthop.

That's the entire point.  In order for anycast to work properly,
all traffic for the flow must be sent along the same path.

As Dean put it in a recent message, per-packet load balancing
would very likely break anycast.

> It can send traffic destined to "a" via the two attachment points to

In the example topology, if there is a single instance of a, using the
de facto BGP ECMP behavior, then the traffic will almost always
hit the same host.  Therefore, in that topology, PPLB on an ECMP
path wouldn't break things.

However, we are unable to know if there is one or more instances of
the anycast source to know if we should prohibit PPLB or not.

> 8 to avoid AS path loops. It has to tell everyone about this.

2 will have two paths: <1 7> and <1 8>.  By current BGP ECMP behavior,
they wouldn't be ECMP paths since the AS PATH differs.

In the presence of a BGP extention that can advertise both paths
rather than just a single best path, the above *might* be a valid
ECMP path.  That's still under discussion.

> for them to run their loop detection algorithm.

Exactly.  This is one of the reasons why BGP ECMP as practiced today
requires identical AS PATHs.  It is also one of the possible uses for
advertising multiple paths inter-domain.

-- 
Jeff Haas 
NextHop Technologies

---

From: Tom Sanders <[email-masked]>
Date: Fri, 26 Aug 2005 23:49:31 +0530

Jeff,

> ECMP path.  That's still under discussion.

Yes, and about time too.

> requires identical AS PATHs.  

This is a very uninteresting case, i.e., doing ECMP when with exactly
the same AS PATHs. The interesting and the more challenging one is
when the AS PATHs are similar (same length) but different.

> It is also one of the possible uses for

Yes.

Toms.