Subject: Re: [Idr] IETF 73

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 3 Nov 2008 19:08:50 +0100

On 13 okt 2008, at 20:21, Yakov Rekhter wrote:

> Its about time to start thinking about agenda items for the next
> IETF. Please forward any IDR agenda items you might have to Sue and
> myself (unless you've done this already). The deadline is Nov 7, 2008.

I updated my inter-AS cost draft:

http://www.ietf.org/internet-drafts/draft-van-beijnum-idr-iac-01.txt

Changes: some text for clarification, removed some less important  
calculations for simplicity. Nothing fundamental.

I would welcome the opportunity to present this and then ask whether  
the wg wants to take on this topic, and if so, this draft, as a wg  
item. Or would it be better to pursue this as an individual  
submission, or not pursue it at all?

Iljitsch
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Paul Jakma <[email-masked]>
Date: Mon, 3 Nov 2008 19:54:41 +0000 (GMT)

On Mon, 3 Nov 2008, Iljitsch van Beijnum wrote:

> I would welcome the opportunity to present this and then ask 
> whether the wg wants to take on this topic, and if so, this draft, 
> as a wg item. Or would it be better to pursue this as an individual 

Devil's advocate: Given the root-cause of the problem is the flatness 
of the internet, what reason is there to think that a fine-grained 
IAC won't have the same "big flip" problem as as-path prepending?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Many people write memos to tell you they have nothing to say.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 3 Nov 2008 21:06:33 +0100

On 3 nov 2008, at 20:54, Paul Jakma wrote:

> Devil's advocate: Given the root-cause of the problem is the  
> flatness of the internet, what reason is there to think that a fine- 
> grained IAC won't have the same "big flip" problem as as-path  
> prepending?

Well, the start situation would be that nobody configures increasing  
or decreasing the IAC. In that case, the IAC is identical to the AS  
path length times 16. If someone then makes a +1 or -1 adjustment,  
this will theoretically have the same effect as prepending the AS path  
with one AS. But in practice there will be two reasons why that  
doesn't happen: not every router/AS will become IAC-aware at the same  
time, so the adjustment only affects the ASes that understand the IAC  
and not the others, and it only takes a few people making use of the  
IAC to make the "big flip" problem reduce in significance.

If vendors apply the random factor this will work even better.

The only situation where there is no improvement over the current  
situation is if everyone applies a -7 update on ingress and egress so  
the increase in IAClocal is the minimum at every AS hop, this is the  
same as the situation we currently have with the AS path length.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Paul Jakma <[email-masked]>
Date: Mon, 3 Nov 2008 20:36:37 +0000 (GMT)

> If vendors apply the random factor this will work even better.

So why not just formalise a solution based on that?

Then the originator can directly advertise "I want 30% on this, and 
that 70% on that, please" and hosts can try accomodate.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Just because you like my stuff doesn't mean I owe you anything.
 		-- Bob Dylan
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 3 Nov 2008 21:42:58 +0100

> that 70% on that, please" and hosts can try accomodate.

Sure. When you download a file from me I'll send you 30% over Cogent  
and 70% over Sprint... (Actually, I am working on multipath TCP.)

The problem is that if A connects to B and C and the rest of the  
alphabet connects to B and C, nobody but A knows that there's more  
than 30% coming in through B and less than 70% through C. A could of  
course continuously send updates to attract more/less traffic as  
desired but even if we can avoid stability issues that doesn't seem  
very scalable.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Paul Francis <[email-masked]>
Date: Wed, 12 Nov 2008 07:16:14 -0500

It's worth pointing out that if you convey inter-AS tunnel endponts in BGP
along the lines of http://tools.ietf.org/id/draft-xu-idr-tunnel-00.txt, then
different ASes (or even individual routers) can select different paths, and
so an IAC scheme can become more fine-grained.  Personally I think if we are
going to look at something like IAC, we should consider tunneling at the same
time.

PF

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Nov 2008 10:40:39 +0100

On 12 nov 2008, at 13:16, Paul Francis wrote:

> It's worth pointing out that if you convey inter-AS tunnel endponts  
> in BGP along the lines of http://tools.ietf.org/id/draft-xu-idr-tunnel-00.txt 
> , then different ASes (or even individual routers) can select  
> different paths, and so an IAC scheme can become more fine-grained.   
> Personally I think if we are going to look at something like IAC, we  
> should consider tunneling at the same time.
>

Both the problems that these drafts address and the solutions that  
they propose look completely orthogonal to me, so I don't see how that  
would be helpful.

About the tunnel draft: isn't this something that could easily be part  
of the RRG efforts? Standardizing this now while overlapping working  
is going on in RRG may be premature.

Iljitsch

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Nov 2008 10:23:24 -0500

Yakov and Sue,

> myself (unless you've done this already). The deadline is Nov 7, 2008.

I would like 10-15 minutes for the MIB update.  I expect the power point
portion of the presentation to take 5 minutes and, presuming I've
finished my code, a few minutes of demo.  The reamining portion would go
to questions.

-- Jeff

---

From: Paul Francis <[email-masked]>
Date: Sat, 15 Nov 2008 09:07:59 -0500

The sense in which they are not orthogonal is this.  IACs are only useful
insofar that upstream ASes have a choice of path.  Of course, with BGP it
often so happens that upstream ASes have choices, but once any AS makes a
choice, it limits the number of choices it presents to its upstream.  If you
have tunnels, then more choices are presented upstream, and there should
therefore me more opportunities to make selections.  The mapped-bgp spec
offers even more choices than the tunnel-endpoints draft.

So basically my point is that if you are prepared to modify BGP to improve
load balancing, you ought to consider the additional improvements the tunnels
can afford you. 

As for the tunnel-endpoint draft being more appropriate for RRG, this is
feedback I'd like to get.  Narrowly viewed, the tunnel-endpoint draft is
something that improves the performance of (intra-domain) VA, which is
already work that is being done in IDR (and was explicitly turned away by
RRG).  Broadly viewed, the tunnel-endpoint draft has wider scope, which
Raszuk pointed out, and this needs to be discussed in IDR.

PF

> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Thursday, November 13, 2008 4:41 AM
> To: Paul Francis
> > It's worth pointing out that if you convey inter-AS tunnel 
> endponts in 
> > BGP along the lines of 
> > http://tools.ietf.org/id/draft-xu-idr-tunnel-00.txt
> Both the problems that these drafts address and the solutions 
> that they propose look completely orthogonal to me, so I 
> don't see how that would be helpful.
> 
> About the tunnel draft: isn't this something that could 
> easily be part of the RRG efforts? Standardizing this now 
> while overlapping working is going on in RRG may be premature.
> 
> Iljitsch
>

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 17 Nov 2008 15:20:27 -0800

On Nov 15, 2008, at 6:07 AM, Paul Francis wrote:
> RRG).

Just my own 2 cents (with all hats off): before Dublin, the VA looked  
to me as something that, if adopted, could be deployed *right away*,  
so IDR seemed to me a better venue to push it--this is not so much of  
turning VA away per se.  As I mentioned to you privately, I always  
viewed VA as "poor man's map" in map-n-encap, which can serve as step  
stone towards incremental deployment (of solutions falling under map-n- 
encap).

>  Broadly viewed, the tunnel-endpoint draft has wider scope, which

---

From: Paul Francis <[email-masked]>
Date: Mon, 17 Nov 2008 20:40:35 -0500

Understood!

PF

> From: Lixia Zhang [mailto:[email-masked]] 
> Sent: Monday, November 17, 2008 6:20 PM
> To: Paul Francis
> Cc: Iljitsch van Beijnum; Inter-Domain Routing List
> > The sense in which they are not orthogonal is this.  IACs are only 
> > useful insofar that upstream ASes have a choice of path.  
> Of course, 
> > with BGP it often so happens that upstream ASes have 
> choices, but once 
> > any AS makes a choice, it limits the number of choices it 
> presents to 
> > its upstream.  If you have tunnels, then more choices are presented 
> > upstream, and there should therefore me more opportunities to make 
> > selections.  The mapped-bgp spec offers even more choices than the 
> > tunnel-endpoints draft.
> >
> > So basically my point is that if you are prepared to modify BGP to 
> > improve load balancing, you ought to consider the additional 
> > improvements the tunnels can afford you.
> >
> > As for the tunnel-endpoint draft being more appropriate for 
> RRG, this 
> > is feedback I'd like to get.  Narrowly viewed, the tunnel-endpoint 
> > draft is something that improves the performance of 
> (intra-domain) VA, 
> > which is already work that is being done in IDR (and was explicitly 
> > turned away by RRG).
> 
> Just my own 2 cents (with all hats off): before Dublin, the 
> VA looked to me as something that, if adopted, could be 
> deployed *right away*, so IDR seemed to me a better venue to 
> push it--this is not so much of turning VA away per se.  As I 
> mentioned to you privately, I always viewed VA as "poor man's 
> map" in map-n-encap, which can serve as step stone towards 
> incremental deployment (of solutions falling under map-n- encap).
> 
> >> they propose look completely orthogonal to me, so I don't see how 
> >> that would be helpful.
> >>
> >> About the tunnel draft: isn't this something that could easily be 
> >> part of the RRG efforts? Standardizing this now while overlapping 
> >> working is going on in RRG may be premature.
> >>
> >> Iljitsch
> >>