Subject: [Idr] Worth putting in an RFC ? Use IP / GRE tunnels between EBGP peers

From: Mark Smith <[email-masked]>
Date: Fri, 13 Aug 2004 12:19:41 +0930

Hi,

The idea is to create IP in IP or GRE tunnels between the EBGP
routers within the AS, run IBGP over the tunnels, and then also use those
tunnels for transit traffic.

If this idea has been thought of before, and dismissed, please disregard the
rest of this email.

I think this idea is similar to the way MPLS can be used to transport traffic
across a transit AS, where the MPLS LSPs target the NEXT_HOP attribute. At
least that's how I understand how MPLS can be used to optimise BGP within an
AS.

I originally worked out this idea when I was learning BGP a few years ago,
although I haven't had a chance to test it. I was surprised when I started
learning MPLS how similar the MPLS solution is.

I do think the MPLS solution is better. This solution could be used as a
transitional step towards MPLS, or maybe as a contingency if there are issues
with the transit routers for some reason (eg. running out of memory for the
Internet route table).

Here are some advantages. As this solution is similar to the MPLS one, there
is quite a lot of overlap.

(a) obviously, not having to run BGP to the transit routers within the AS.

(b) therefore, internal transit routers don't have to maintain full Internet
route tables

(c) simpler to deploy than the MPLS solution. MPLS deployment is likely to
require software / firmware upgrades in the transit routers. If I understand
the MPLS itself, and the MPLS solution correctly, it also requires that all
routers between the AS edge routers are MPLS enabled before MPLS can be used.

I'd suspect the majority of current AS border routers already contain IP in IP
/ GRE functionality that just needs to be configured. Transit routers
within the AS need no additional configuration at all.

(d) If the BGP keep alive timer is set large enough, the tunnel will hide
transients in the underlying transit network.

Of course, there are some drawbacks.

(a) The tunnel header overhead added to the transiting IP packets. This may
cause PMTUD to have to discover a new PMTU.

(b) A full mesh of tunnels needs to be set up between all the EBGP routers in
the AS. While this is simpler than a full IBGP mesh between all AS transit
routers, it doesn't scale upwards. At a certain point, other "mesh mitigation"
techniques will become more effective.

(b) can't really think of any others now, that certainly doesn't mean there
aren't any :-)

I'm willing to have a go at writing something up if there is enough value in
this idea. 

Thanks,
Mark.

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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 12 Aug 2004 23:30:32 -0400

> tunnels for transit traffic.

That which was once old is made again new. :-)

[RFC 1772, A.2.3]
A.2.3 Encapsulation

   Encapsulation provides the simplest (in terms of the interaction
   between the IGP and BGP) mechanism for carrying transit traffic
   across the AS. In this approach, transit traffic is encapsulated
   within an IP datagram addressed to the exit gateway. The only
   requirement imposed on the IGP by this approach is that it should be
   capable of supporting routing between border gateways within the same
   AS.

It is well worth the time for relative newcomers to read the 177x
series of documents.  They encapsulate a lot of old wisdom. :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: Mark Smith <[email-masked]>
Date: Fri, 13 Aug 2004 14:14:46 +0930

Hi Jeff,

Thanks for getting back to me.

On Thu, 12 Aug 2004 23:30:32 -0400

> series of documents.  They encapsulate a lot of old wisdom. :-)

I agree. I have glossed through 1771, I haven't got to reading the others :-)

It would seem that the authors of the few books I've got on BGP
have either read them and forgotten about this, or possibly never read them
thoroughly enough either, as I've never come across any mention of this
technique. That is why I thought it might be new, at least when it came to
using IP/IP or GRE tunnels for this purpose vs. MPLS.

Thanks,
Mark.

---

From: Vivek Menezes <[email-masked]>
Date: Fri, 13 Aug 2004 15:10:06 -0700

Mark,

> using IP/IP or GRE tunnels for this purpose vs. MPLS.

RFCs should to be written only for protocol compliance between
vendors. Having an RFC
describe a particular implementation doesn't add much value. You can also use
ATM to do what you are suggesting  :-)

Vivek.

---

From: Mark Smith <[email-masked]>
Date: Sat, 14 Aug 2004 11:52:15 +0930

Hi Vivek,

On Fri, 13 Aug 2004 15:10:06 -0700
Vivek Menezes <[email-masked]> wrote:

> > have either read them and forgotten about this, or possibly never read
> > them thoroughly enough either, as I've never come across any mention of
> > this technique. That is why I thought it might be new, at least when it
> > came to using IP/IP or GRE tunnels for this purpose vs. MPLS.
> 
> describe a particular implementation doesn't add much value.

I was thinking along the lines of an Informational RFC describing this method.

I though that the scope of the IDR working group might also cover
Informational RFCs regarding the use of BGP. I've realised that might not be
the case. Appologies to everyone if I was wrong.

Thanks,
Mark.

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 14 Aug 2004 14:05:03 -0400

Mark,

1.  This is something already known.

2.  It is a trivial observation.

3.  It is already documented.

4.  This would be a rather pointless exercise.

It seems like you want to have your name on an informational RFC and
you are fishing for something to write about.  This is clearly not
something worthy of its own informational RFC.

btw- Anyone can submit an individual internet-draft and ask that the
IESG consider it directly.  If it is deemed by the IESG to fall within
or close to the general scope of an existing WG it will be forwarded
to that WG.  That means that if it is related to BGP it will most
likely end up right back here.  So far all of the responses are
telling you it is not material for an RFC.

If you actually knew the pros and cons of a full mesh of BGP over a
tunnelled infrastructure then *maybe* it would be worth an RFC.  But
then it wouldn't be about BGP over GRE.  It would be about the early
UUNET brief experience with IP over ATM, about the former
InterneetMCI's brief experience with full mesh ATM and the IGP
problems, and C&W's experience with FR over CCC over MPLS (and anyone
else that tried something like this).  It would explain why RFC1577
was a non-starter as far as ISPs were concerned in its time and why
the "BGP free core" with tunneling can in some cases share the same
characteristics that made RFC1577 a non-starter.  This would be best
writen by someone who was either directly involved or very familiar
with the issues in each of these and/or well connected enough to
contact people who were directly involved.  Even these are somewhat
documented if you count such things Dave Katz presentation on IGP
scaling at NANOG for which he didn't submit slides and numerous
discussion about the motivations for IGP mesh groups and discussions
on the now defunct IP over ATM WG, ION, and others.  It would also
explain the "pros" of running a BGP mesh over some sort of tunneling
and how MPLS/RSVP solved these without the cons that came with IP over
ATM.  Other tunneling with no TE capability just accomplishes a subset
of the perceived "pros" which is the trivial observation you've made.

Even if someone wrote such a document there would be considerable
discussion over exactly how significant each of the pros and cons are.
The actual experiences are at least difficult to dispute but provide
only a limited set of data points.  The extrapolation to today's
topologies and technology would be the area of disagreement.

You haven't demonstrated in your few brief messages that you have the
slightest clue about the existing known issues or what has been
written about them in the past and which somewhat significant points
have not been clearly documented.  If you think you can enlighten us,
go for it.  If you are just going to point out that it is possible to
run BGP over GRE you don't have material for an RFC.

Curtis