Subject: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-IS to Informational

From: Philip Christian <[email-masked]>
Date: Mon, 2 Jun 2003 15:39:02 +0100 (BST)

I probably shouldn't be opening an old wound, but I
just can't help it...

I still say that there is absolutely no point in
forming an adjacency between an IPv4-only router and
an IPv6-only router.  If you do then you cannot
forward any traffic over it, so what is the point ?

I also think that the MT draft is wrong in this
respect.  The fact that a sub-topology exists does not
reduce the validity of what I have said.  Personally I
think that the MT draft is over prescriptive on this
and consequently makes itself incompatible with
autoencap, when it isn't necessary to do so.

For autoencap to ever be useful, it would be much,
much simpler if the IPv6-only routers would just
refuse to connect to the IPv4-only routers.  Then
autoencap would be useable in a more or less idiot
proof fashion. Okay dual routers still would be able
to make black holes, but at least the single protocol
ones wouldn't.  It would be as good as I can get it,
though not perfect.

As it wouldn't do any harm, why not do it ?

What I am proposing is that if an IPv6 capable router
can detect no network layer protocols in common with a
neighbour then it should not form an adjacency with
it.  If it can detect one or more in common then it
should, on the basis that the adjacency is useful at
least for that network layer protocol.

Please could it go in the IPv6 RFC ?

By the way ITU-T G.7712 already calls for such a
clause.  By adding it to the RFC then the two would be
aligned, making it easier for folks to sell routers to
the telecom companies building SONET/SDH DCN networks.

Philip

__________________________________________________
Yahoo! Plus - For a better Internet experience
http://uk.promotions.yahoo.com/yplus/yoffer.html
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Mon, 02 Jun 2003 11:43:15 -0400

Beating an old drum ...

Failing to form adjacencies can cause the DR election to produce
different results for different routers, leading to an inoperative
network.  Therefore it's not a question of something that causes
no harm.

I used to believe that adjacencies should always be formed,
but it turns out the subject is more complicated that I'd thought,
and I can't say which is best.  I just wanted to point out that
refusing to form adjacencies can cause a severe problem.  True,
the problem can be fixed by careful tuning of DR priority -- but
can you write down the rules so that a competent network admin
can do it?

I'll admit that (at least, without MT) the problems caused by
creating an adjacency when there is no connectivity (e.g., when
there is no common subnet address) leads to bigger problems than
the DR election.  Nonetheless, I haven't ever seen anyone who
advocates refusing the adjacencies tackle this problem.  In the
case of no common subnet, the solution is simple: fix the addressing.
In the case of multiprotocol, the situation is more complex.

Regards,
Jeff

---

From: Philip Christian <[email-masked]>
Date: Mon, 2 Jun 2003 17:06:05 +0100 (BST)

--- Jeff Learman <[email-masked]> wrote: > 
> Nonetheless, I haven't ever seen
> anyone who
> advocates refusing the adjacencies tackle this
> problem.  

I though that I made a reasonable go at it in section
5.1 of draft-ietf-isis-auto-encap-03.txt

If you have a bunch of IPv6-only nodes on a LAN, all
ignoring the IPv4-only ones, then they will elect a
DIS from amongst themselves, because IOS 10589 states
that you elect only from up adjacencies.

The IPv4-only nodes will do the same as having been
ignored by the IPv6-only ones they don't have an up
adjacency with them.

You end up with two pseudonodes, one that describes
all of the IPv4-only nodes on the LAN, and the other
that describes all of the IPv6-only nodes on the LAN,
which is actually an accurate picture of the network.

I tried this in the lab and it does work very well.

I will admit that if you put a dual node on the LAN
then things start to go wierd, I have always admitted
that.

Just because problems A and B cannot both be solved is
not a reason to not solve problem A when you get a
chance.  The IPv6 RFC is such a chance.

I think that we should properly crunch some scenarios
rather than just dismissing the whole thing as a
"problem".  It isn't so complicated.  These decisions
have a way of haunting us for years, and it is worth a
few e-mails to get all of the issues out in the open.

Philip

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 2 Jun 2003 18:53:15 +0200

On Mon, Jun 02, 2003 at 03:39:02PM +0100, Philip Christian wrote:
| I probably shouldn't be opening an old wound, but I
| just can't help it...
| 
| I still say that there is absolutely no point in
| forming an adjacency between an IPv4-only router and
| an IPv6-only router.  If you do then you cannot
| forward any traffic over it, so what is the point ?

from a forwarding perpective you do not need to rely on
common subnets - you just need somehow resolve the
next-hops routers MAC adress [if its bcast] and then
forward the traffic to; - agreed - the common subnet
rule is a sanity check but from a forwarding perspective
not necessary;

| I also think that the MT draft is wrong in this
| respect.  The fact that a sub-topology exists does not
| reduce the validity of what I have said.

the root cause of the "common subnet rule" is that next-hop
resolution on bcast circuits in most OS kernels works via ARP;
i.e. if there is no common subnet then the ARP fails and
subsequently no next-hop information can be generated due
to the missing MAC addresses; 

common "protocol neutral IS-IS" sense would dictate to resolve
the next-hops via extracting SNPAs from IIHs; - however most kernels 
rely on a per AF L2 address resolution protocol read: ARP,
and most routing code does not feedback L2 information back to the kernel;

i fail to see why the MT draft is broken from a forwarding perspective ?

/hannes

---

From: Jeff Learman <[email-masked]>
Date: Mon, 02 Jun 2003 13:36:43 -0400

Hannes, what you say is correct, but Philip's point concerned
IPV4 vs IPV6, not common subnet addressing (a very closely related
issue).

If A supports only IPV4 and B supports only IPV6, then there's no
way one can forward traffic to the other.  So the question is, why
should they form an adjacency?  My answer is: so that either of them
can be elected DR and generate pseudonode LSPs.  However, this is
a fairly complex subject and I'm not at all certain that my proposition
is the best solution.  Rather, it's food for thought.

Jeff

---

From: Jeff Learman <[email-masked]>
Date: Mon, 02 Jun 2003 12:42:55 -0400

Right -- unless you have a multiprotocol node on the LAN, you don't
have problems.  But I haven't seen any text on how to deal
with the problems caused by multiprotocol nodes.  Way back when I
posted several problematic scenarios, to deaf ears.

So, to summarize (please correct me if I have it wrong):

  Because they require forming adjacencies between nodes that
  have no data protocols in common, MT and IPV6 draft are both
  non-interoperable with auto-encap.

  Forming adjacencies with all neighbors, as required by 10589,
  avoids DR election problems.

  Auto-encap requires rejecting adjacencies with neighbors they
  have no data protocols in common with.

  MT and IPV6 have no provisions for automatically plugging holes
  between protocol "islands" even though it may be possible to
  connect the islands using tunneling.  Any such tunneling must
  be manually configured.

Regards,
Jeff

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 2 Jun 2003 20:14:38 +0200

On Mon, Jun 02, 2003 at 01:36:43PM -0400, Jeff Learman wrote:
| 
| Hannes, what you say is correct, but Philip's point concerned
| IPV4 vs IPV6, not common subnet addressing (a very closely related
| issue).
| 
| If A supports only IPV4 and B supports only IPV6, then there's no
| way one can forward traffic to the other.  So the question is, why
| should they form an adjacency?  My answer is: so that either of them
| can be elected DR and generate pseudonode LSPs.  However, this is
| a fairly complex subject and I'm not at all certain that my proposition
| is the best solution.  Rather, it's food for thought.

i am not sure ....
when we are we talking about "supporting" IPv4 or IPv6 are we talking
about "node" properties or "link" properties ?

still i wonder about the unnumbered case ... i.e. can there be
situations where from a link perspective there are no protocols
in common, however from a node perspctive there is;

my confusion/curiosity is mainly derived from the unclear semantics
of TLV 129 and or presence/absence of 132/232;

/hannes

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 02 Jun 2003 22:26:04 +0200

>is the best solution.  Rather, it's food for thought.
yepp, as far I remember the problem was that you have to form adjacencies
on Ether to everyone (if you're DR) since otherwise you'll end up with a
partionened
ether and old-style devices not understanding what possibly went wrong

    thanks

    - tony

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 02 Jun 2003 22:32:26 +0200

>  non-interoperable with auto-encap.
hmm, how so ? Been a while I read the auto-encap draft. Care for a short
summary
so we're on same page.

>  avoids DR election problems.
yes, as far my mind carries, we couldn't find asolution once you had nodes
in multiple topologies (incl. #0) and nodes not understanding MT on the
same
LAN. And this is a real deployment scenario that will need support. It
won't help
to make our lives easier if we introduce restrictions (you can't run
dual-mode on
same ether) that are infeasible in the real world.

>  connect the islands using tunneling.  Any such tunneling must
this is a routing protocol, not a network configurator ...

    -- tony

---

From: Jeff Learman <[email-masked]>
Date: Mon, 02 Jun 2003 17:10:20 -0400

>summary so we're on same page.

My understanding is that in auto-encap, neighbors that don't have a data
protocol in common must refuse to form adjacencies, whereas in MT and IPV6,
they must form them regardless.  But I'm not really "up" on any of these
documents, so I'd like the experts to correct me if I'm wrong!

Regards,
Jeff

---

From: Philip Christian <[email-masked]>
Date: Mon, 2 Jun 2003 22:32:25 +0100 (BST)

MT has a clause in it that you always form an
adjacency on a LAN whatever.  It says so in section
5.2

"Two Routers on a LAN SHALL always establish adjacency
regardless whether they have common MT set or not.
This is to ensure all the routers on the LAN can
correctly elect the same DIS. "

However this does not make MT incompatible with
autoencap.  However I believe that the MT draft
doesn't really have the right to make that statement
anyway.  It is nothing to do with MT, it's rather a
general IS-IS issue, and it isn't necessary to make MT
work, which is why I said that it is overprescriptive.

Having a correctly elected DIS is a general IS-IS
issue, not particularly an MT issue.  I don't see why
the MT draft has to address it.

Other than that issue MT is perfectly compatible with
autoencap, especially if any LANs used are kept simple
(like don't use an MT node, a dual node and a
uniprotocol node on the same LAN).  A simple MT to
autoencap link (LAN or otherwise) will work fine.

Also to say that the IPv6 draft is not compatible with
autoencap is flat out wrong.

Autoencap does rely on an IPv6-only and an IPv4-only
node not having an adjacency.  This can be acheived by

a: A rule such as the that I am proposing, as per
G.7712.

b: Just don't put an IPv4-only and IPv6-only node on
the same LAN.

or

c: Manually disable any such adjacency.  As long as
there are no non-autoencap dual nodes on the LAN then
you won't get into problems with DIS.

Use any of these three and autoencap will interwork
with IS-IS routed IPv6 perfectly, even as the draft
stands.

Also manual tunnels don't work that well either.  You
can't tell IS-IS to use the tunnel for IPv6 but not
for IPv4.  You end up sending all traffic down the
tunnel whether it could go natively or not.  You end
up with (IPv4+IPv6+ISIS)/GRE/IPv4 for example.

Philip

 --- Tony Przygienda <[email-masked]> wrote: > Jeff

---

From: Philip Christian <[email-masked]>
Date: Mon, 2 Jun 2003 23:30:15 +0100 (BST)

I think that this is the specific scenario that
becomes broken if IPv4 and IPv6 nodes don't have an
adjacency.

The number above the node is the priority.

  3       1        2
+----+  +----+  +-----+
| v4 |  | v6 |  | 4/6 |
+--+-+  +--+-+  +-+---+
   |       |      |
  -+-------+------+-
         LAN

In this case the v6 node sees the higher priority of
the 4/6 node and so doesn't make a pseudonode.

The 4/6 node sees the v4 node and so doesn't make a
pseudonode.

The v4 node sees only the 4/6 node and so makes a
pseudonode, but only includes the 4/6 node as
connected to the pseudonode.

Thus, another IS viewing the LAN from afar will think
that the v6 node is not connected and so will not plot
a route through it, as it isn't included in the
pseudonode LSP.

Without autoencap you could use this topology, but
only very carefully.

You would have to make sure that no IPv6 destinations
lie beyond the v4 node, and that no IPv4 destinations
lie beyond the v6 node.  In this way you can guarantee
that SPF will never send an IPv4 packet through the v6
node and vice versa, as all v4 destinations are
through the 4/6 node.

On this particular point, an adjacency rule such as
G.7712s does stop a usable route being formed where
otherwise it would be formed.  The topology is however
illegal under RFC 1195 and one would be ill advised to
use it.  Many vendors won't implementations won't work
in this scenario anyway.

If you set the dual node higher than the others then
it works because you get a single pseudonode declaring
adjacencies to all others.

If you set the dual node lower than the others then it
works because you get two pseudonodes both declaring
an adjacency to the dual.

It only breaks if the dual node is higher than all v4
nodes, but lower than a v6 node, or the other way
around.

Philip

---

From: Jeff Learman <[email-masked]>
Date: Mon, 02 Jun 2003 18:20:23 -0400

OK, I thought the auto-encap doc specifically said to NOT
form adjacencies when you have no data protocols in common,
in which case it would contradict MT.  In general, if one
protocol says you MUST do A, and another says you MUST NOT
do A, they're incompatible and non-interoperable.  In this
case, though, it's not that cut-and-dried, as you pointed out.

More below.

At 05:32 PM 6/2/2003, Philip Christian wrote:
>autoencap.  

Glad to hear it!

>However I believe that the MT draft

If it's necessary anyway, then why not say it?  10589 isn't the
best source because it's not multiprotocol.  I don't remember
whether RFC 1195 is explicit or not, nonetheless the question
used to come up all the time.  In MT, the deployment requirements
of 1195 are relaxed, and this might or might not mean a change in
this kind of policy.  MT gives the requirement and the reason
for it.

>autoencap is flat out wrong.

Once again, I thought that IPv6 requires forming 
adjacencies that auto-encap requires to be refused.

>with IS-IS routed IPv6 perfectly, even as the draft

So it appears that auto-encap can be used with MT and
IPv6, as long as certain deployment rules are followed.
Are these rules documented?  Probably not, since auto-encap
preceded the others.  It would be worthwhile to document
them officially.

>up with (IPv4+IPv6+ISIS)/GRE/IPv4 for example.

Before MT, manual tunnels don't work at all.  I would have
thought that manual tunnels plus MT would work just fine,
because you CAN tell IS-IS to use the tunnel (link) just for
specific protocols.  I'll have to reread MT -- like I said,
I'm not an expert on that; I'm just going on my recollection.
Sorry if I've muddied the water.

Jeff

---

From: Jeff Learman <[email-masked]>
Date: Mon, 02 Jun 2003 18:54:21 -0400

This is one bad case.  It gets a little more complicated when
there are 3 or more protocols involved, and the solutions aren't
quite as simple.  There might be another bad case for 2 protocols,
but I'll have to think about it.

The topology is illegal for 1195, but is it illegal for MT?

Regards,
Jeff

---

From: Naiming Shen <[email-masked]>
Date: Mon, 02 Jun 2003 18:35:13 -0700

yes, this(MT requires to form adj with neighbors) is only meaningful
with point-to-multipoint interfaces. over p2p, we are saying no need
to setup adj if not matching.

but on a LAN, we need to have a DR. we can have some choices:

 - don't allow any protocol family to mix, any topology to mix

 - to have a seperate DR for each level/address-family/topology

 - to share the same DR within the level, always setup adjacency
   with everyone on the LAN to elect a stable DR, but label the
   adjacency useable or unusable base on the address-family and/or
   topology sets. announce or don't announce the adjacency in LSP
   accordingly. as long as a system performs backlink checks in
   spf computation, this scheme should work just fine.

in MT draft/implementation, we thought the first solution is not
acceptable, the second one is too messy, the last one works and
rather easy to do. we realized that this is not a MT only property,
but MT is the first one to advocate this within ISIS, and i don't
see anything wrong with that.

thanks.

 ] Jeff Learman wrote:
 ] 
 ] >Hannes, what you say is correct, but Philip's point concerned
 ] >IPV4 vs IPV6, not common subnet addressing (a very closely related
 ] >issue).
 ] >
 ] >If A supports only IPV4 and B supports only IPV6, then there's no
 ] >way one can forward traffic to the other.  So the question is, why
 ] >should they form an adjacency?  My answer is: so that either of them
 ] >can be elected DR and generate pseudonode LSPs.  However, this is
 ] >a fairly complex subject and I'm not at all certain that my proposition
 ] >is the best solution.  Rather, it's food for thought.
 ] >  
 ] >
 ] yepp, as far I remember the problem was that you have to form adjacencies
 ] on Ether to everyone (if you're DR) since otherwise you'll end up with a
 ] partionened
 ] ether and old-style devices not understanding what possibly went wrong
 ] 
 ]     thanks
 ] 
 ]     - tony
 ] 
 ] >  
 ] >
 ] 
 ] 
 ] _______________________________________________
 ] Isis-wg mailing list
 ] [email-masked]
 ] https://www1.ietf.org/mailman/listinfo/isis-wg

- Naiming

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 03 Jun 2003 11:45:53 +0200

Naiming Shen wrote:

>b

from my memory when we wrote/discussed this thing I agree with Naiming ...

    -- tony

---

From: Philip Christian <[email-masked]>
Date: Tue, 3 Jun 2003 11:25:36 +0100 (BST)

Actually there is a simple solution.

A DIS election per protocol.

This is what we did for the autoencap and it works
really well.

I thought that maybe it would be too radical for the
IPv6 RFC, but given that it works, maybe I should be
pushing for it.

Basically it is no change for single protocol routers
(except that they reject an adjacency with a neighbour
that doesn't support their protocol).

However a dual router has a DIS election process per
protocol.

It makes a pseudonode if it is the highest priority
either for IPv4 capable routers, or if it is the
highest priority for IPv6 capable routers.

Sometimes you get two DISs on the LAN, but that
doesn't cause any problems.  It does guarantee that
everyone gets advertised by the LSPs either from one
DIS or the other.

It also works for three or more protocols.

Maybe this would be better for the MT folks as well.

Philip

---

From: Daniel Gryniewicz <[email-masked]>
Date: 03 Jun 2003 10:59:08 -0400

I may be missing something, but if you have *any* v6 nodes only
reachable via the v4 node, then they are cut off, because the v4 node
cannot forward v6 packets to them.  That's why it's a v4 node, right? 
Nothing you do in terms of DIS election will fix the fact that they are
not reachable. However, if you fix the DIS election, then they will
*look* reachable to the rest of the domain, resulting in black holed
packets, rather than in unreachable destinations.  Mixing address
families in the domain is extremely problematic unless you have a base
that everyone speaks.

Daniel

---

From: Jeff Learman <[email-masked]>
Date: Tue, 03 Jun 2003 11:36:47 -0400

At 10:59 AM 6/3/2003, Daniel Gryniewicz wrote:
>cannot forward v6 packets to them. 

Right.  So, either (a) don't do that, or (b) use Auto-encap.

> That's why it's a v4 node, right? 
>packets, rather than in unreachable destinations.  

>Mixing address families in the domain is extremely problematic unless
>you have a base that everyone speaks.

This is a much more general statement that your example supports.

It's true that it's problematic, but mostly because 1195 chose not
to go there.  It could have been solved very simply with different
deployment rules and a requirement to check protocols-supported and
run multiple SPFs.  But 1195 didn't, and so any attempt to deal with
topologies that violate 1195 deployment rules will require new standards
and will involve backwards compatibility issues, and will be problematic
as you say.

However, I believe that the requirement that all routers support a
common data protocol isn't sufficient to deal with existing and upcoming
challenges, and isn't necessary to solve the problems either.  It does
simplify things a lot, but doesn't cover existing cases like SONET
management networks, and it doesn't facilitate migrating from one
protocol as the "lingua franca" to a different one (because all nodes
must support the new protocol before switching over, instead of
a gradual and natural transition.)

Just my $0.02.

Jeff