Subject: RE: IESG soliciting comments on use of BGP for VPN

From: Jeff Parker <[email-masked]>
Date: Fri, 30 May 2003 10:22:56 -0400

> >> .. anything which was related to the computation of routing
> >> information (i.e. that is used to influence the FIB) is fair 
> >> game, BUT (and note the shouting), it MUST be subject to 
> >> analysis to show that the volume and frequency of the 
> >> information will stay within reasonable bounds.  
> 
> > The document draft-kompella-ppvpn-vpls-02.txt seems to
> > meet both clauses: it affects forwarding, and given 
> > some assumptions about the rate of joining and leaving,
> > the refresh rate could be kept in check.  
> 
> Hmmm... I got the impression that the mechanism described there
> carried exactly zero bit of routing information. It affects
> data plane, but not the IP routing data plane...

Let's go back to the proposed text.  The issue may 
boil down to forwarding vs. routing.  The question
becomes:

	Is it proper to use BGP (or some other P) to 
	exchange forwarding, rather than routing, info?

I'm struggling with this, as there aren't good guidelines
or examples on this.  TE information in IGPs allows someone
to make MPLS tunnels.  Is this an outrage, or appropriate
re-use of proven technology?  If we look at the refresh
rate, I think Mike's next point would raise a flag on this
use, but we aren't laying on the tracks to stop MPLS.

This is like refereering a basketball game.  We have some
rules, and we could blow the whistle often and call
each infraction.  But when that happens, we slow the
game down so much that the athletes and the fans pick 
a different venue and continue the fast-paced game 
that they both enjoy.  

So we are trying to figure out realistic guidelines 
that allow innovation while protecting the stability 
and integrity of the current technology.  Clearly
A and B below are fouls.  
 
> The WG should be reusing tunnels defined in PWE3.

But late binding on the choice of tunnels is 
a savvy political move.  
 
> > Clearly, if a new use of an old protocol would
> 
> >    A) Confuse other speakers of the protocol
> >    B) Require new behaviors of old speakers
> 
> > then the change would be harmful.  I don't see
> > evidence of either, and
> 
> Hmmm... what do you mean in B above? To explain a bit more, supporting
> new AFI/SAFI and/or BGP attributes always means modifying the BGP
> code.

Well, it is simpler than it may look.   
A protocol that allows old implementations to 
co-exist, without understanding the new info, 
is less harmful that a protocol which requires 
new behavior of old implementations.   

- jeff parker