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

From: Pekka Savola <[email-masked]>
Date: Fri, 3 Sep 2004 09:48:04 +0300 (EEST)

On Tue, 31 Aug 2004, Mike McBride wrote:
> In San Diego, Ice presented draft-wijnands-pim-proxy-00 and requested that
> the PIM WG adopt it as a working group document. At the time, we felt that
> we needed to modify our WG charter before considering such documents. Upon
> further review we will proceed and let your voice (hands) be heard. Please
> review the following document and provide opinions on whether we should
> adopt it:
> 
> http://www.ietf.org/internet-drafts/draft-wijnands-pim-proxy-00.txt

Because there is IPR on it, my default answer would be "no, unless 
proven otherwise".

In this case the proof would probably consist one or more of the
following:

 1. multiple other vendors indicating that they'd intend to implement 
the the option, and would desire it to be put on Standards Track.

 2. there being strong usage case for it.  I don't see it.  BGP-free
cores or L3VPN's were given as examples, but that doesn't give any
hint why anyone would like to do a BGP-free core in the first place.  
If they want to do it, that's fine, but that doesn't necessarily mean
we'll have to support it.  And the L3VPN case being still open was
already mentioned.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Yiqun Cai <[email-masked]>
Date: Sun, 5 Sep 2004 21:52:41 -0700 (PDT)

> Because there is IPR on it, my default answer would be "no, unless 

Pekka,

Is your objection against making it a WG document, or making it a WG
document that is on a standard track?

I know IETF has a process (I'm sorry I haven't read the relevant RFCs)
and there is precedence that document containing intellectual property
claim was accepted as WG document.  So if IPR is the primary concern,
I'm sure there is a way to work it out.

Besides IPR, are there any other reasons that you think the draft
should not be a WG document?  As far as I know, BGP-free core exists
today in service providers networks.  So the draft does propose a 
viable solution.

Thanks.

-- 
Yiqun

---

From: Pekka Savola <[email-masked]>
Date: Mon, 6 Sep 2004 14:46:25 +0300 (EEST)

> I'm sure there is a way to work it out.

The procedures are described in RFC 3668 and RFC 3667.  Yes, there is
no procedural problem in taking an IPR-encumbered document as WG item
provided that so-called Reasonable and Non-discriminatory licensing
has been offered (the word "Reasonable" can be oxymoronic, as there is
no actual definition or requirement on what is deemed "reasonable").

However, the Cisco IPR statement only promises "RAND" license if the
target is Standards Track, so I don't think the IETF process allows
going further with another category level (however, publication as
Informational/Experimental through RFC editor is a possibility).

Hence, from this WG's point of view, the options seem to be either
taking it as Standards Track or doing nothing at all.

Since the question wrt. Standards Track or not affects the other
vendors which may or may not want to license, and the terms could be
different if it is Stds Track or not, therefore, the primary input
should come from the other vendors.

> today in service providers networks.  So the draft does propose a 

And it needs to be suitably justified why BGP-free core is something
we want to invest time and effort in our specifications.  A possible
answer, instead, could be, "enable BGP".  I.e., what were the reasons
or requirements of those networks which didn't want BGP in their core
networks?  Were those MPLS or also non-MPLS networks? Etc.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 6 Sep 2004 10:25:20 -0700

> no actual definition or requirement on what is deemed "reasonable").

Meaning ?  You don't like (to be) reasonable ? ;-))

> Informational/Experimental through RFC editor is a possibility).

What "other category level" do you mean ? There is nothing else than
standards track or RFC editor contributions (although rfc3668
fails to mention "Historic" in 1.f).

> taking it as Standards Track or doing nothing at all.

First: I would certainly like to see this work to be on the standards
track. The core of the submission constitutes a framework for more flexible
RPF in PIM, and for whatever applications this is being used, i think
it is key to improve on the applicability and such the sucess of the
IETFs PIM technology.

Second: The working group can take a document as a work item 
nonwithstanding the targeted status. Quite frankly i don't think that
a working groups should spend time on non-standards track efforts, but
as seen with MSDP, there are cases when one needs to conclude to such
compromise. I just don't think there would be any need to do this for
subject technology.

> should come from the other vendors.

First of all, there are no vendors, there are just individual contributors
to the IETF process. Secondly: would you claim the same inference to 
competing vendors opinions for any technology that you yourself have an
interest in as a user (let's say embedded RP) ? I rather think not. You
would instead look for support from other potential users to make the case
- to persuade vendors to implement it. 

> networks?  Were those MPLS or also non-MPLS networks? Etc.

Glad you asked:

First of all, there is a big problem to get honest evaluations of the
benefits of "BGP free core" In IP unicast BGP free core only works with
MPLS forwarding (*). In result, you have MPLS haters say BGP free core is
stupid and MPLS bigots say it's wonderful, but both of them actually mean
MPLS and not BGP when they say that. On its own, a BGP free core is just
a simplification of the routing requirements and thus i think unambiguously
beneficial - opinions are just split as to whether or not the downsides that
come with making it work (like MPLS forwarding) are worth it. Obviously
there are several hundred large service provider networks using MPLS and
also many that do not, so there is room for both.

In IP multicast, the situation is now quite different. BGP free core can
be done for native IP multicast traffic with our WITHOUT MPLS forwarding
of that traffic, as explained in the subject draft. It is thus much more
attractive an argument than in IP unicast. I think this approach should
be especially attractive to anyone interested to make IP multicast simpler
or for anyone who does not like MPLS ;-)) 

Cheers
	Toerless

(*) let's ignore options like redistributing BGP routes into the IGP,
    or protocols that do the same as BGP but are called differently ;-)

---

From: Pekka Savola <[email-masked]>
Date: Tue, 7 Sep 2004 07:57:30 +0300 (EEST)

> fails to mention "Historic" in 1.f).

Informational or Experimental.

[snip]
> to the IETF process. 

By the letter, yes.

> Secondly: would you claim the same inference to 
> interest in as a user (let's say embedded RP)? I rather think not. You

Yes, but if the vendors have been persuaded by the potential users to 
implement X, the vendors could then say that they want X.

IMHO, either the people from the vendor community (outside of Cisco :)
need to step up and say "we want this", or a significant number of 
operators need to do that.

> or for anyone who does not like MPLS ;-)) 

If you need to have BGP for IP unicast, it doesn't really matter if
you also have it for multicast -- there's no operational
simplification, and that was my point -- if you don't do MPLS,
BGP-free core [for multicast] doesn't seem provide real benefits only
complexity because you have two different topologies.

On the other hand, if you do have BGP-free core with (unicast) MPLS,
then you'll have to ask how one would perform multicast in an MPLS
network.  And as far as I understand, that's still an open issue.  It
just might be that multicast would work even in BGP-free core without
any modifications to PIM, depending on the approach taken.  So, as was
stated before, it seems premature to look at this yet.

---

From: Yiqun Cai <[email-masked]>
Date: Mon, 6 Sep 2004 23:25:23 -0700 (PDT)

Pekka,

But aren't we supposed to be individuals evaluating the drafts based
on its technical merits first?

Multiple implementations would be needed for a draft to advance along
the statndard track.  But I have never heard that a multi-vendor
commitment for implementation is required for a draft to be accepted
as a WG document.

Having said that, one certainly should consider operators' input to
evaluate the usefulness of the solution in this particular area.

> stated before, it seems premature to look at this yet.

First of all, it doesn't matter how useful (or beneficial) we perceive
about BGP-free core.  It exists today in a number of service provider
networks offering a variety of edge services and these SPs would like
to transport multicast packets.  This is simple fact that we can't or
shouldn't deny.

In such a network, there are two problems to solve with respect to
multicast.  The first is how to propagate Join/Prunes.  The second is
how to forward multicast packets.  One can use IP tunneling or MPLS.
Using MPLS remains an open issue.

This draft describes a method to propagate Join/Prunes.  It doesn't
require a specific forwarding encapsulation.  So I dont see the open
issue you mentioned related to this draft.

Thanks.

-- 
Yiqun

P.S. I think some of the points that you raised were discussed in the
presentation that I gave at MBONED.