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

[Acee Lindem <[e-mail]>]

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.

   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
      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?


      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