Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 10 Nov 2003 08:49:40 -0800

Following up on this thread, I have the following concerns with this
document:

1. Tunnels are used both intra and inter domains. Thus tunnel
capabilities have to be propagated across domains as well. Hence IGP is
imho not appropriate for this application.

2. Tunnel capabilities are not used by core routeres.

3. There are existing documents that specify the use of BGP for this:
draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt
draft-nalawade-kapoor-tunnel-safi-01.txt

Hence imho OSPF WG should not take on this work.

Thanks,
rahul

On Tue, 28 Oct 2003, Robert Raszuk wrote:

> Acee,
>
> >      My biggest fear would be that if this draft is accepted it
> >      would only be the first of a torrent of auto-configuration
> >      drafts.
>
> Second one not first ;). Notice this one submitted a while back:
> draft-raszuk-ospf-bgp-peer-discovery-00.txt
>
>  >     1. Should OSPF be used for tunnel auto-configuration?
>
> I think in general this requires a study on a case by case basis. Most
> important factors which should be taken into consideration are:
>
> *A* How frequently the information advertised changed - is it static
> configuration or dynamic in nature which triggers reflooding ?
>
> *B* Is the application which the uses delivered information limited to
> IGP domain or crosses domains ?
>
> *C* What is the amount of information to be flooded (keeping in mind
> that majority of P routers - those in the core - will never use it.
>
> *D* What are the alternatives available & _deployed_ today to deliver
> the same information to it's users
>
> *E* How often area wide flooding will be sufficient versus domain wide.
>
> Coming back to draft-eng-nalawade-ospf-tunnel-cap-00.txt I see the
> following:
>
> Reg A: Info is essentially static except the L2TPv3 cookie rollover
> intervals which if implementation permits could be changing periodically
>
> Reg B: I think that in any application of tunnels we can't limit the
> scope of use to one IGP domain. There can be a lot of customers who may
> never need to go over a domain (which this draft is targeting though).
>
> Reg C: Minimal (comparing to TE at least :):).
>
> Reg D: It is worth noting that there is a few drafts in IDR describing
> the ideas for the same information distribution
>
> Reg E: Looking at the most common OSPF topologies I would say that most
> tunnels will be build between edge PEs and those in a lot of cases are
> located in it's own POP areas. Not to say that there are no customers
> who keep most of their PEs on the edges of area 0.
>
> Rgs,
> R.
>

---

From: Gargi Nalawade <[email-masked]>
Date: Mon, 10 Nov 2003 12:47:32 -0800

Hi Rahul,

Thanks for your comments.

> 1. Tunnels are used both intra and inter domains. Thus tunnel

Not always. There are tunnels which are purely intra-domain as well.

> draft-nalawade-kapoor-tunnel-safi-01.txt

The above BGP solutions can be used only in BGP networks. There are
BGP-free networks that require tunneling Capabilities as well and we
are receiving requests from those customers to provide a complementary
solution that does not rely on BGP being present.

Also - for the 2 specific drafts mentioned above, BGP uses the routes
learnt through an IGP to resolve the nexthop to BGP prefixes. But in
the presence of tunnels, this reachability is not sufficient and the
reachability via the tunnels has to be propagated as well. The BGP
solution has been created purely for the inter-Provider case where there
is no inter-AS mechanism other than BGP to propagate that. But within
a given network, when the tunnels are required only within an AS or domain,
the IGP provides the reachability to the Tunnel end-point and hence is the
right place to carry the tunnel reachability information as well.

> Hence imho OSPF WG should not take on this work.

Hence I believe that the IGP is the right place to carry the above and
IMHO, the OSPF WG should take on this work.

Thanks,
Gargi

---

From: Sandy Eng <[email-masked]>
Date: Mon, 10 Nov 2003 12:58:20 -0800

Rahul,

> 2. Tunnel capabilities are not used by core routeres.

As we are announcing specific router capabilities, it therefore infers
that only certain routers in the network are capable of some specific
capabilities. If all routers in a network have the same capability,
there is then no need for specific announcement.

Thanks,
Sandy

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 11 Nov 2003 21:13:47 -0800

Hi Gargi,

> Not always. There are tunnels which are purely intra-domain as well.

The point is that one *has* to solve the inter-domain case. IGP cannot
do that unlike BGP based solutions which do that. Given that why a
different solution for the intra domain case ? Note that in a domain this
information is needed only by the PEs. It doesn't need to be flooded on
all the P routers.

> solution that does not rely on BGP being present.

The core maybe BGP free, but the PE routers will run BGP. Can you explain
the scenario when the PEs don't run BGP ?

> reachability via the tunnels has to be propagated as well.

For route resolution, the BGP next-hop needs to be reachable. The BGP
next-hop will be the tunnel endpoint address. This in turn will be an IGP
route. Why is this not sufficient ?

The BGP
> right place to carry the tunnel reachability information as well.

Then maybe IGPs should carry labelled VPN routes too in a domain ?

Thanks,
rahul

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 11 Nov 2003 21:16:41 -0800

Hi Sandy,

> there is then no need for specific announcement.

The tunnel encapsulations are needed by the PE routers and are advertised
by the PE routers. Different PE routers can advertise different tunnel
capabailities. However P routers do not require this information.

rahul

---

From: Gargi Nalawade <[email-masked]>
Date: Tue, 11 Nov 2003 21:49:17 -0800

Hi Rahul,

Inline...

> do that unlike BGP based solutions which do that. Given that why a

By that argument why have anything that is in both BGP & IGP? Why have
redistribution between protocols at all? :)

The inter-AS - more expensive solution would be used when inter-AS tunnels
are needed, whereas the intra-AS solution can be used in case of intra-AS
tunnels and also if a Provider wants to propagate tunnel information within
its domain using an IGP and redistribute only the inter-AS information on
the border PEs. This completes the solution. These are not competing solutions.
One complements and completes the other and caters to those customers who do
not want to run BGP to signal these tunnel end-points and want to treat them
(correctly) as part of IGP reachability.

> information is needed only by the PEs. It doesn't need to be flooded on

Not necessarily. Depends on the application. You are narrowing down the scope
to a particular application - which is why you think PE. I agree that common
scenarios would be PE-to-PE. But that does not mean that there won't be scenarios
that have P routers as endpoints. TE-tunnels is one example.

Also note that this draft is a framework for tunnel endpoint signalling and
how and where it is deployed/used and whether the tunnel endpoints are PEs
or Ps depends on the specific application a Provider or an Enterprise has
in mind.

> the scenario when the PEs don't run BGP ?

You are only thinking Provider VPNs. In that case yes - the PEs will run
BGP. But like I said this is not limited to Provider VPNs and hence the
tunnel endpoints could be just vanilla IGP routers.

> route. Why is this not sufficient ?

Because the reachability would be through the tunnel. Unless the tunnel
comes up - traffic cannot begin to flow through it and hence the destination
is still unreachable as long as the Tunnel endpoint encapsulation is not
received. That really belongs in the IGP which is what provides the reachability
to the endpoint.

> Then maybe IGPs should carry labelled VPN routes too in a domain ?

Well, thats upto you, if you want to define that. ;-) I'm not the one saying that.

Thanks,
Gargi

---

From: Sandy Eng <[email-masked]>
Date: Tue, 11 Nov 2003 21:56:56 -0800

Rahul,

> capabailities. However P routers do not require this information.

When a capability is announced, one does not expect all routers in a
network to react to such capability. One example is
draft-vasseur-mpls-ospf-te-cap-00.

Do we then require that the RI LSA carries capability information only
if all routers in a network need it? If so, I don't see this requirement
mandated in draft-lindem-ospf-cap-01.

I agree we should not simply stuff any type of information in OSPF. But
this should be looked at from application to application. Most of the
times, a router announcing as a tunnel endpoint does not change its
status. Tunnel application can be mostly viewed as a single shot.

Furthermore, there are enterprise networks that are only running IGP
(OSPF in this case), which wish to establish tunnels to divert special
class of traffic. In such cases, OSPF needs to provision this dynamic
discovery.

In a VPN enviroment, OSPF converges in sub-seconds while BGP in minutes,
OSPF can deliver the tunnel endpoint information much faster than BGP,
enabling faster traffic reachibility.

Thanks,
Sandy

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Nov 2003 07:09:09 +0100

Sandy,

> enabling faster traffic reachibility.

I can't agree with this statement.

BGP convergence intra domain - note within _single_ domain can be in
fact almost as fast for tunnel AFI/SAFI then for OSPF. In fact with
default timers in OSPF and with prioritizing tunnel AFI/SAFI first (as
it should be the case) I could argue that even today with most BGP
implementations it will converge faster then OSPF when the number of
your P routers is decent.

I think we could debate more - and yes this draft itself solves some
practical cases with not too big overhead for IGPs - but let's at least
keep the facts right.

Thx,
R.

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 11 Nov 2003 22:20:46 -0800

Hi Gargi,

> the border PEs.

This is another flaw with doing this in IGP. A BGP only solution doesn't
require redistribution between IGP and BGP.

> that have P routers as endpoints. TE-tunnels is one example.

Please explain how/why tunnel capabilities will be used by TE tunnels.

> or Ps depends on the specific application a Provider or an Enterprise has

Can you articulate the applications where this information is needed on
the P routers ?

> Because the reachability would be through the tunnel. Unless the tunnel

The control traffic reachability is through the hop by hop path to the
tunnel endpoint. Data traffic takes the tunnel.

Thanks,
rahul

---

From: Gargi Nalawade <[email-masked]>
Date: Tue, 11 Nov 2003 23:05:20 -0800

Rahul,

> This is another flaw with doing this in IGP. A BGP only solution doesn't

A BGP-only solution *requires* BGP. That is the only flaw with just doing
this via BGP.

> Please explain how/why tunnel capabilities will be used by TE tunnels.

There are numerous examples out there. Look at draft-vasseur-mpls-ospf-te-cap-00.txt

> Can you articulate the applications where this information is needed on

I just named one. This is not limited/targeted at P routers though. There
could be enterprise routers that do not run BGP that need tunneling mechanisms.
Sandy's email mentioned an example for that as well.

> tunnel endpoint. Data traffic takes the tunnel.

Data traffic cannot take the tunnel path until -

1) the control-plane IGP route-reachability has converged
2) the Tunnel reachability has converged

Today - IGPs can give us 1). What is missing is 2) - which is what this draft
proposes to add.

Thanks,
Gargi

---

From: Gargi Nalawade <[email-masked]>
Date: Tue, 11 Nov 2003 23:15:56 -0800

Robert,

> it should be the case) I could argue that even today with most BGP

I dont quite agree with - 'prioritizing... as should be the case'. We
have debated this in the past and you know my stance. The stance of
multiple providers I have talked to, also seems to be the same. They
want a simple, scalable BGP which does not affect/compromise on their
core ipv4 routing. So let's not talk about BGP here.

Reality is, in most generic implementations today, there is an order of
magnitude difference between OSPF and BGP.

> your P routers is decent.

Let's forget about the 'if's and 'when's for now. Plus convergence is
not the only major driving factor. There is a need for a non-BGP solution
expressed by the enterprise and provider space alike.

> practical cases with not too big overhead for IGPs - but let's at least

Ok. So you agree that this draft solves practical cases. Hear Ya!

-Gargi

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 12 Nov 2003 06:04:09 -0800

Gargi,

> core ipv4 routing. So let's not talk about BGP here.

Don't they also want a simple scalable IGP which does not affect/compromise
on their core ipv4 routing. So, let's talk *here* about why BGP overload
is bad, while IGP overload is ok.

And wrt "BGP which does not affect/compromise on their core ipv4 routing",
isn't it *you* who wrote several internet drafts that describe mechanisms
to handle this with BGP ?

> magnitude difference between OSPF and BGP.

Vendors who have this problem should fix the IBGP part of their "generic
implementation".

Yakov.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Nov 2003 15:16:48 +0100

Gargi,

 > Reality is, in most generic implementations today, there is an order
 > of magnitude difference between OSPF and BGP.

Of course there is. And that's why we should not only talk about BGP
here comparing both solutions as about some massive and huge monster but
we do need to realize that Tunnel AFI/SAFI's properties and the number
of few NLRIs it needs to carry in comparison with thousands of ipv4 or
vpnv4 BGP carries is a very significant factor to keep in mind.

Cheers,
R.

 > Gargi Nalawade wrote:

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 12 Nov 2003 06:17:43 -0800

> practical cases with not too big overhead for IGPs - but let's at least

Could you please enumerate these cases.

Yakov.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Nov 2003 15:33:18 +0100

Hi Yakov,

Practical cases I have in mind is the pragmatic approach to reuse
existing and deployed machinery for flooding information versus
designing new one from scratch.

That applies to BGP, IGPs, LDP, PIM etc ....

I essentially see nothing wrong with providing some one the ability to
use OSPF for distributing session IDs and cookies in this example if
they wish to do so for some reason.

As example for provider who wish to use 2547bis over L2TPv3 for whatever
reason and happens to have quite a few confederations with a common IGP
it seems simpler to use IGP then a sequence of IBGP/EBGP cycles to get
the information distributed.

So to make myself clear I would like to see if there is an agreement in
general for "protocol reuse". I also think that at some time it may turn
better to just define a user configurable container (ala community
field) in IGPs where users could put their data and flood without the
need to go via new code / new draft each time a need to flood something
arises.

Cheers,
R.

 > Yakov Rekhter wrote:

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 12 Nov 2003 11:54:20 -0800

Robert,

> vpnv4 BGP carries is a very significant factor to keep in mind.

And moreover, we need to keep in mind that there is no need to carry
all of them over the same BGP session.

Yakov.