Subject: [Isis-wg] draft-zinin-flood-opt-01.txt (was draft-ietf-zinin-flood-opt-01.txt)

From: Curtis Villamizar <[email-masked]>
Date: Tue, 31 Oct 2000 12:01:09 -0500

A while back Alex wrote:

  Folks,

  The new version of the flooding optimization draft
  has been submitted to the IETF directories today.

  So far, it is available at the following URL:

  http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-01.txt

This was followed by some thoughtful discussion (as opposed to recent
MPLS discusiions of VPN and Optical Bundling :( ).

The draft ended up as draft-zinin-flood-opt-01.txt.  Apparently the
internet-drafts editor could not find the zinin WG so dropped ietf
from the name. :)

My comments relate to (half joking about this):

  We could discuss this, actually, with the first question being "do
  we really need this" ? ;)

I don't want to give anyone the impression that I don't support this
work.  With the kompella-bundle style of link bundling in which the
component links run individual IGP adjacencies this is needed.  

[I'll also point out that for the layer-2 style bundling that Avici
(composite-link tm) and Pluris are doing, this is not needed since
there is only one interface for the bundle and one ISIS adjacency but
multiple instances of SONET and PPP which scales just fine.
Interoperability is good so we'll allow bundles to be made both ways.]

My question is if we do solve the bundle problem in a neater fashion,
whether we need the zinin-flood-opt changes to accommodate full mesh,
or if we can also solve that problem through some means that is neater
than using ISIS mesh group.

It doesn't seem like zinin-flood-opt addresses the mesh problem at
all.  In the mesh case there can be exactly one adjacency between any
two routers and zinin-flood-opt doesn't address this.

We need to look back at how we got into the full mesh problem in the
first place and avoid repeating the mistake.  We inherited this
problem when a certain ISP decided to build a full mesh over ATM and
we got mesh groups when it (as predicted) blew up in their face.  We
now have IGP adjacencies between adjacent routers, PXC, and other
fancy equipment.  We will soon have FA across the topology (ala
draft-ietf-mpls-lsp-hierarchy-01.txt), either for TE scaling or to
accommodate optical equipment that doesn't look at the payload.  We
want to avoid falling into the full mesh trap here.

I'm quite sure the assumption that some have made is that we simply
don't bring up IGP adjacencies over the FA.  Others, particularly our
friends in UUNET, have pointed out that if the underlying topology
changes it is nice if the LSP reroutes and we see a constant IGP cost
of EBGP destinations seen by edge routers that are not MPLS capable
(or not MPLS enabled).  This makes advertised MED constant and avoids
route flap damping headaches (another defensive kludge, this one to
isolate BGP brain damage elsewhere).

What we need to accommodate the need for less dynamic IGP cost seen
beyond the MPLS domain is an advertised IGP adjacency.  We could even
bring up an IGP adjacency just so we can use hellos (rather than the
BT proposed OAM MPLS packets) but we don't want to flood over that
adjacency.  The IGP adjacency over an FA would have the following
characteristics:

  1.  Participate in the hello protocol.  (Better yet do LQM :)

  2.  No flooding by default.  (Might be OK to override this if the
      flooding through the PXC or whatever is deemed to slow but
      proceed with extreme caution and this should be the rare
      exception).

  3a. Advertise IGP adjacency (if hello is up) but no TE parameters if
      we want constant MED only but don't want hierarchical LSP.

  3b. Advertise IGP adjacency and FA with TE parameters if we want
      both constant MED and hierarchical LSP.

  3c. Advertise FA with TE parameters but no IGP adjacency if we want
      hierarchical LSP but don't care about constant MED.

I think discussions so far are leaning toward 3c, but 3a and 3b seem
to me to be more useful for ISPs.

The above would be a good thing to have in a document somewhere
maybe draft-ietf-mpls-lsp-hierarchy-01, maybe elsewhere.

It would be nice to avoid the full mesh problem and fix the cause
rather than refine the mesh group bandaid previously put over the
problem.  Documenting this clearly might deter network designers from
falling into this trap (again).  [Not that it did the first time.]

It would also be nice to do bundles right rather than put the zinin
bandaid over that problem, if we're not too wed to doing one IGP
adjacency per component link for bundles.  If we are wed to doing
bundles "as is" in draft-ietf-mpls-lsp-hierarchy-01 then
draft-zinin-flood-opt-01 reduces the inefficiency that we introduce by
requiring one adjacency per component link.

Curtis

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Alex Zinin <[email-masked]>
Date: Tue, 31 Oct 2000 09:35:31 -0800

Curtis:

[That was a long one ;)]

Yeah ;) "-ietf-zinin" was "-ietf-ospf" first, than I had to change it to an
individual submission for some reasons, so I confess, I forgot to
remove "-ietf"...

So allow me not to comment each and every sentence in your message
and address the main points you bring.

1. You support this work.

   Thanks. ;)

2. Full/dense-mesh vs parallel links in draft-zinin-flood.

   draft-zinin-flood does not address the mesh problem and
   does not claim to.

   I hope you understand that the two problems do not have
   to be solved with a single approach. The fact that the draft
   solves the second does not mean we're not working on
   the first. However, the second problem is screaming louder,
   so it makes sense to address it now.

3. Do we need it of we do bundling in a cooler way.

   First, let me emphasize that the approach in this draft
   is not specific to optical networks, so you may have
   parallel links btw normal routers and still not want to
   do any type of bundling (just because you don't like that
   "right" bundling approach, or whatever ;)).

   Second, even if bundling is used in optical networks,
   you may have a number of bundles, each assigned to its
   control channel, and there maybe more than one control
   channel btw boxes, so you hit the same problem.

4. FAs, etc.

   The concept of FAs includes the possibility for it to
   be announced as native IGP adjacency, and even without
   Hellos being exchanged. I actually do not think we need
   to exchange Hellos. Just recall how VLs work in OSPF.

Alex.