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

[Gargi Nalawade <[e-mail]>]

Acee,

Acee Lindem wrote:
> There has been some discussion of this draft off-list and I decided it
> time to bring to the list rather than continue with multiple off-list
> e-mail threads.
>
> Here are the issues as I see them.
>
>   1. Should OSPF be used for tunnel auto-configuration?
>
>      The arguments for this are that OSPF is used for TE and
>      this is yet another opaque application. Additionally, one
>      proposed TE application (mesh group) is related to
>      auto-configuration.
>
>      The arguments against is that we must be very careful what
>      we put in the IGP.
>
>      I don't feel that strongly one way or another here. The thing
>      about this application is that it doesn't really modify any
>      basic OSPF mechanisms so it only has impact on the OSPF routing
>      domain if it is used.
>
>      My biggest fear would be that if this draft is accepted it
>      would only be the first of a torrent of auto-configuration
>      drafts.

You mean second :) Let me point out though that this isnt a new application.
The basic application is a customer-driven requirement for advertising tunnel
capabilities and info. The config-reduction is a by-product of that. Also,
this is simply a generalized mechanism for advertising the tunnel capabilties.

>
>   2. If the answer to #1 is yes, do we want to use the OSPF capability
>      opaque LSA?
>
>      As an author of the capabilities draft, I'd say "no" since there
>      is a variable amount of information that may be advertised and we
>      don't want to make the capabilities LSA an all purpose container for
>      multitudes of TLVs. Rather it is meant to contain the router's
>      overall capabilities and possibily a sub-TLV or two describing
>      the a capability. While the techniques for concatenating LSAs

That is exactly what it is used for by this draft as well. To advertise the
Tunnels capability set to the peers.

>      are well-known, there really isn't any advantage here of stuffing
>      all the local tunnel endpoints into the capabilities LSA.
>
>      In short, if this application is worth doing it is worth allocating
>      an opaque LSA type (and OSPFv3 LSA type) for it.
>
>
>   3. Percisely how will the opaque LSA be used? When will the tunnel be
>      created, deleted, brought up/down? How does tunnel group ID come
>      into play? Must there be OSPF connectivity for the tunnel to be
>      considered up or will any type of route do?
>

Most of this is implementation-specific really. But to answer your last
question, there needs to be connectivity for the tunnel to be considered
up.

-Gargi


>
>      I believe the authors are in agreement that more specification is
>      needed for this to be a viable draft that would facilitate
>      interoperable implementations.
>
>
> Thanks,
> Acee