Subject: Re: [pim] draft-wijnands-pim-proxy

From: Yakov Rekhter <[email-masked]>
Date: Wed, 13 Oct 2004 08:00:12 -0700

Folks,

So far the discussion about draft-wijnands-pim-proxy seems to be
focused on one particular problem that this draft is intended to solve
- BGP-free core or Internet routes free core.

However, I'd like to point out that the solution proposed in
draft-wijnands-pim-proxy is *not* limited to that particular problem,
but is also claimed to support traffic engineering with PIM (see
section 2.4.2 of the draft).

I think that prior to extending PIM with traffic engineering
capabilities, the authors of draft-wijnands-pim-proxy need to answer
the question whether adding vector stack to PIM would be adequate
to match the requirements for p2mp traffic engineering.

Yakov.

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Mike McBride <[email-masked]>
Date: Wed, 20 Oct 2004 15:15:55 -0700 (PDT)

It doesn't appear we've reached consensus on the acceptance of this draft
within the PIM WG. There are a majority of individuals, however, who have
expressed support for the adoption of the draft. But majority doesn't
rule here. We need better WG agreement if we are going to proceed.

If the authors of this draft were to remove references to traffic
engineering, would those who have voiced opposition, then be supportive of
adopting this draft within the PIM WG? Would the authors of the draft be
open to removing TE?

Let's try to get this resolved before D.C.

thanks,
mike

---

From: IJsbrand Wijnands <[email-masked]>
Date: Thu, 21 Oct 2004 09:30:03 +0200

Mike, Yakov,

> adopting this draft within the PIM WG? Would the authors of the draft be

Maybe the reference to Traffic Engineering in section 2.4.2 is a bit to 
optimistic. I've no problem removing that. What about if we name it 'explicit 
routed path' using a stack with multiple vectors.

Thx,

Ice.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 21 Oct 2004 12:32:39 -0700

Ice,

> routed path' using a stack with multiple vectors.

If the stack of vectors is not intended for traffic engineering,
then what are the applications for the stack of vectors ?

Yakov.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Oct 2004 13:42:14 -0700

> then what are the applications for the stack of vectors ?

Let's try to understand what is in dispute here. Traffic Engineering
is a highly overloaded word that can imply functions like fast reroute, 
bandwidth reservation or explicit path selection and where people seem
to have fery fixed expectations about the framework on how or whether
this is delivered.

The RPF-vector-stack allows only to influence path selection in a form
which has also been common even in the most basic IP (or SNA ?) architectures
via loose and strict source routes. 

The RPF-vector transports this idea into the path selection of the control
plane message. Whether or not you want to consider this to be part of
some future traffic engineering architecture or not is a matter of
interpretation and future profile of applicability specification and
not really something the draft needs to cover. I think for this reason
others proposed to remove references to the word traffic engineering
and any implications of how this path selection might fit any type of
future traffic engineering solutions or not.

The RPF-vector-stack can be called a loose source-route mechanism in
the draft, which can be used for example to better control the SPF selection
during re-convergence, to have ASBR path selection or the like, and of
course also the potential for explicit path selection for P router paths.
It's really kinda like the loose source route in IP, only that because it
is in the control plane, it does not suffer from the IP loose source routes
HW dependencies but causes the selection per flow of course (not per packet).

Cheers
	Toerless

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 24 Oct 2004 12:06:56 -0700

Toerless,

> future traffic engineering solutions or not.

Adding a new mechanism to a protocol for the sake of some nebulous
"future traffic engineering architecture" is clearly broken. First
you need to finalize this future traffic engineering architecture,
and *then* add the appropriate mechanism(s) to the protocol.

> HW dependencies but causes the selection per flow of course (not per packet).

All this looks like a plenty of hand-waiving, and little/no specifics
on how the RPF-vector-stack is intended to be used. As I said before,
if there are any specific problem(s) that you think would require
the use the RPF-vector-stack, then document how the
RPF-vector-stack would be used to solve these problems, and whether
such solutions would meet the requirements.
 
Cheers

Yakov.

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 24 Oct 2004 14:30:52 -0700

On Sun, Oct 24, 2004 at 12:06:56PM -0700, Yakov Rekhter wrote:
> > which has also been common even in the most basic IP (or SNA ?)
> > architectures via loose and strict source routes. 
> > 

You choose to ignore what i ways saying. I said that "Traffic Engineering"
may be a nebulous term, but there is no need to rathole a very specific and
well defined functionality by asking for a whole universe to be built
around it in before. Explicit path selection via a hop-by-hop specification is
an easily understood clear functionality and can be taken advantage of without
necessarily having defined what "Traffic Engineering" means.

> All this looks like a plenty of hand-waiving,

I am not familiar with that expression. Did you not understand the
explanations that i tried to provide in the paragraph or are you trying to
avoid a start of a technical discussion by dismissing it with fancy terms ?

> and little/no specifics on how the RPF-vector-stack is intended to be used.

True. I was assuming that the possible applications are pretty obvious
to you as an author of USP#6,078,590. Are you telling me you can not
think of how it is to be used and i need to explain that to you ?

> As I said before,
> the use the RPF-vector-stack, then document how the  RPF-vector-stack
> would be used to solve these problems, and whether such solutions would
> meet the requirements.

I am not quite sure what you are asking here:
First of all, i do not speak for the authors of the draft, i am
just relaying my personal opinions here. Are you asking the authors to
encumber a protocol specification submission with the inclusion of
additional requirements or solution architecture text in the actual
protocol spec document ?

Cheers
	Toerless

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 27 Oct 2004 06:33:22 -0700

Toerless,

> think of how it is to be used and i need to explain that to you ?

If you would read the patent, you would realize that this patent 
does *not* use the RPF-vector-stack, but just a single address. 

Yakov.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 27 Oct 2004 08:40:37 -0700

> does *not* use the RPF-vector-stack, but just a single address. 

Yes, so what ?

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 27 Oct 2004 09:06:54 -0700

> > does *not* use the RPF-vector-stack, but just a single address. 

So, the application you mentioned *does not* need the RPF-vector-stack.

Yakov.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 27 Oct 2004 10:35:49 -0700

> So, the application you mentioned *does not* need the RPF-vector-stack.

Yes, did i ever dispute that ? I was purely stating about my expectations
against your insight into the problem space as a SME, not about the actual
details of the patented application.

Cheers
	Toerless