Subject: Re: [rrg] Last call: Design goals

From: [email-masked]
Date: Thu, 21 Oct 2010 14:33:41 EDT

In einer eMail vom 21.10.2010 18:38:38 Westeuropäische Sommerzeit schreibt  
[email-masked]:

Hi  Heiner,

> Nevertheless the issues should be mentioned and specified:  The current 
enormous size of the Internet ( number of DFZ-routers =x, number  of 
RIB-entries = y, number of FIB-entries=z). The continuing growth wrt size  and 
tighter meshing(FIB-growth-factor=350,000 / 310,000=1,13).The expiration  of IPv4 
addresses (number of unused addresses= n)

This really seems  like material for the problem statement, more than the 
design  goals.

This is true. But a such compressed repetition wouldn't be bad,  
particularly as the design goals should respond to these problems. Very easily  this 
or that problem can slip out of focus ( e.g. the RIB size, e.g.  the  tighter 
meshing), accordingly this or that design goal.

>  >  3.2. Scalable support for traffic engineering
> 
> But  for multihoming there is agreement. And multihoming is just a 
special case of  alternate routing, i.e.FRR (if seen logically; I know   according 
to  IETF terminology these are completely different animals). My guess is: 
FRR is  enabled intra-domain, hence there is a demand for it, 
intra-domain-wide. FRR  is not enabled inter-domain, hence there is no demand for it, 
inter-domain  wide.

For multi-homing, there's already a separate section.   I'm not 
understanding what changes you're recommending.
1.I can give you an example from my TARA-draft: If you fill the forwarding  
table t1 with the alternative next hop, temporarily, you will enable  
fastest alternate routing too.
2.Today I received draft-ietf-rtgwg-ipfrr-notvia-addresses-06.txt. If my  
BeyondSPF proposal were very poor, then this draft is poorest. Comparably  my 
BeyondSPF-algorithms are lightyears ahead. My thinking is this:
Why not apply them inter-domain ?!!

> >  3.3.  Scalable support for multi-homing
> > It wouldn’t be bad to mention  that multi-homing is just a particular 
aspect of multipath.
> 
>  
> Sorry, I'm not seeing your point.  Does multi-path support affect  our 
design goals?  
> See above

I'm still not  seeing your point.

Of course. Eliminating the scalability problem is one thing. Enabling  
better routing is equally important.

> > 3.6. Decoupling location and  identification
> > I have strong doubts that this community has fully  understood what 
loc/id-split may mean.
> 
> 
> This doesn't  seem like a document where we should be educating them.
>  Agreed:-)
> 
> 
> > 3.7. First-class elements
> I  did read 3.7 a few more times. I assume it is much more general 
i.e.not just  about tunnels. Myself, I cannot even find another example for what 
may be  meant. Also, if I were asked to come up with a first example, I would 
never  have pointed to tunnels

Well, as I've commented to a few others,  the text here clearly doesn't 
communicate my intent, but it's the best that I  can do at expressing the 
intent while remaining professional.  I welcome  alternate text.

> > 3.8. Routing quality
> I cannot  propose text immediately because it needs more discussion up 
front. Quality  routing may
> address a) the applied algorithms, or b) the selection of  first-class 
paths and links (QoS-paths/links).
> Ad a)  (only) : It  is up to the provisioned information and up to the 
algorithm itself how good  or bad is 
> the resulting routing technology.
> 1. Imho, it is  NOT quality routing if the second best route is  –
eventually- completely  out of scope.
> 2. My suspicion: “Stretch” was introduced by Dima while  judging  his 
own hyperbolic concept in 
> comparison with the  status quo. Shortest path means shortest path, and 
any longer path should be  
> as short as possible and as long as necessary. Going from A to B via  C, 
rather than directly from A to B,
> means stretch 2 (which wouldn’t  be such disastrous:-).Thinking about 
concepts with some conceptually 
>  built-in stretch factor >1: 
> (1)FEDERAL EXPRESS: All parcels are  sent to Memphis,TE, then forwarded 
> (2)PNNI with its logical group  nodes’ topologies.
> We may say: The concept itself should not enforce  longer routes. 
Comments?  
> 3.We are far off from better routing  which e.g. might enable state-less 
p2mp /mp2mp, or scoped broadcast.4.We are  far off proper dealing with 
loops: crankback means loop. Eventually crankback  provides the only available 
route ! Quality routing may mean “better  routing”

A couple of comments:

- AFAIK, the reference is the  first usage of the term 'stretch' in the 
literature (2006), and unless someone  has an earlier reference, I'm inclined 
to attribute this to the  authors.

- Some people make their living on minimizing the bit*miles  that their 
employers have to pay for.  For them stretch 2 is  fatal.
Right. I am totally in favor of stretch 1. And to make that clear to any  
metric or geometry:
The shortest path must be shortest (no diffuse metrics !  )
Heiner

Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 21 Oct 2010 11:46:36 -0700

Hi Heiner,

> [... Discussion on scalability]
> This really seems like material for the problem statement, more than the design goals.
> 
> This is true. But a such compressed repetition wouldn't be bad, particularly as the design goals should respond to these problems. Very easily this or that problem can slip out of focus ( e.g. the RIB size, e.g. the  tighter meshing), accordingly this or that design goal.

Do other folks feel this way?  I have a hard time believing that we need another restatement here.

> For multi-homing, there's already a separate section.  I'm not understanding what changes you're recommending.
> 1.I can give you an example from my TARA-draft: If you fill the forwarding table t1 with the alternative next hop, temporarily, you will enable fastest alternate routing too.
> 2.Today I received draft-ietf-rtgwg-ipfrr-notvia-addresses-06.txt. If my BeyondSPF proposal were very poor, then this draft is poorest. Comparably my BeyondSPF-algorithms are lightyears ahead. My thinking is this:

Ok, I'm getting your point.  I propose the following text at the end of Section 3.1:

	If a solution includes support for alternative routes to support faster
	convergence, the alternative routes should also factor into control plane 
	scalability.

Does that work for you?

Tony

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 21 Oct 2010 15:08:00 -0400

No, I do not think we need to try again to rephrase the problems.  I 
actually think a compressed repetition might well be harmful, and if not 
harmful is unlikely to be helfpul.

Yours,
Joel M. Halpern

On 10/21/2010 2:46 PM, Tony Li wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 Oct 2010 21:31:57 +0200

On 10/21/10 9:08 PM, Joel M. Halpern wrote:
> actually think a compressed repetition might well be harmful, and if
> not harmful is unlikely to be helfpul.
>
+1

---

From: [email-masked]
Date: Thu, 21 Oct 2010 17:55:44 -0400

>   convergence, the alternative routes should also factor into control plane 
ok.Heiner

-----Ursprüngliche Mitteilung----- 
Von: Joel M. Halpern <[email-masked]>
An: Tony Li <[email-masked]>
Cc: [email-masked]; [email-masked]
Verschickt: Do., 21. Okt. 2010, 21:08
Thema: Re: [rrg] Last call: Design goals

No, I do not think we need to try again to rephrase the problems.  I actually think a compressed repetition might well be harmful, and if not harmful is unlikely to be helfpul. 
 
Yours, 
Joel M. Halpern