Subject: [Isis-wg] IPv6 question from last IETF

From: "Christian E. Hopps" <[email-masked]>
Date: Thu, 2 Nov 2000 12:02:14 -0500

Hi,

At the previous IETF IS-IS WG meeting someone questioned whether
the IPv6 draft was aligned with regard to metric size with the
TE draft.  I've double checked and it is aligned.

The question was regarding wether TE draft specified 24 bit metrics
whereas the IPv6 draft specified 32 bit metrics.  The confusion arose
becuase the TE draft specifies 24 bit metrics for _IS_ reachability
(i.e., link advertisements).  The IPv6 draft does not define any new
TLVs for IS reachability.  Both the TE draft and the IPv6 draft
specify 32 bit metrics for IP reachability.

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

---

From: Rajesh Saluja <[email-masked]>
Date: Thu, 02 Nov 2000 14:41:46 -0500

Hi,
I think that you are talking about my question in last IETF.  My
question was not about the metric size, it was about the type of metric.
TE draft eliminates any distinction between internal and external metric
type but IPv6 draft IP reachability TLV contains 1 bit to identify
external metric type. This is the inconsistency I was pointing.

Thanks,
Rajesh

--

-------------------------------------------------------------
Rajesh Saluja
Nortel Networks Inc 600 Technology Park Billerica, MA  01821
Ph: (978) 288-7791      Fax: (978) 670-8760
--------------------------------------------------------------

---

From: "Christian E. Hopps" <[email-masked]>
Date: Fri, 3 Nov 2000 10:59:20 -0500

> external metric type. This is the inconsistency I was pointing.

There were a couple questions.  I believe your question was "answered"
in the meeting (at least I didn't keep it as an open item to look into).
Perhaps you didn't feel the same way :)

To avoid confusion I'd like to point out that the IPv6 draft like the
TE draft has only one metric type (i.e., there is no external metric).
What the IPv6 draft did keep from the original RFC was some indication
that the reachability was from another routing protocol.  The reachability
type does not affect the SPF.  Its main use is to avoid redistribution
loops (e.g., bgp->isis->bgp).

My personal opinion is that the TE draft should have some way of
indicating the "externalness" of the reachability.  I believe the
answer to this opinion in the past was "use a sub-tlv" to color
the reachbility.  This is a fine solution but seems overly complex
for most scenerios.  I'm not sure why 2 TLV types weren't used
to carry forward the old RFC semantics (I used a bit because I had one
available which isn't the case with the TE TLVs).

In any case because the IPv6 draft implements sub-tlvs the TE solution
of using a color sub-tlv is available, if people decide this is
the better route to take.

Thanks,
Chris.

---

From: Henk Smit <[email-masked]>
Date: Sat, 4 Nov 2000 17:54:31 +0100 (MET)

> loops (e.g., bgp->isis->bgp).

  And it does a bad job of that.
 When I used to work in support, I saw that most cases of redistribution
 were in a scenario where a network operator tried to redistribute
 multiple islands of routing protocol X into/from a central backbone
 running protocol Y.

  Example: an ISIS backbone with multiple RIP worlds around it.
 Note that there might be more than one redistributing router between
 the ISIS backbone and a specific RIP domain. In fact,common sense
 would encourage you to design a network with redundancy.

                 ---rtr1---   central   ---rtr3---
 RIPv2 world A                 IS-IS                RIPv2 world B
                 ---rtr2---   backbone  ---rtr4---

  If you use only the route type to decide whether to redistribute
 or not, you will find out that routes from RIP world A will be
 marked as external in the IS-IS world, and thus these routes
 will not be redistributed into RIP world B. The IS-IS backbone
 needs a way to distinguish between routes originated in world A
 and in world B. Internal/external route-type is not enough.

  IMHO if you wanna build something new, better build it good.
 So lets forget about a half-baked solution like internal/external
 route-types, and fix this right.

> the reachbility.

  Yes, that is what we have suggested before.

>  This is a fine solution but seems overly complex
> for most scenerios.

  That depends how more complex you think a bit is versus a byte. :-)
 All implementation have to deal with sub-TLVs anyway. Even if they
 don't support any sub-TLVs, they still have to be able to parse them,
 just so they can ignore them. Adding a sub-TLV should not be too much
 work.

>  I'm not sure why 2 TLV types weren't used
> to carry forward the old RFC semantics

  Why waste another TLV for a solution that doesn't solve the problem ?
 We have only 255 TLVs to spare.

> (I used a bit because I had one

  Using sub-TLVs would be compatible with the traffic-eng extensions draft.
 Using bits would be more like RFC1195.
 I would suggest using sub-TLVs, and reserving your bits for more useful
 use in the future. I am sure people will come up with suggestions later ...

  Hope this helps,

      Henk.

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 4 Nov 2000 22:52:06 +0100 (MET)

>  and in world B. Internal/external route-type is not enough.

We could tackle that problem of course,
but is anyone willing to put in the cycles ? As well, how realistic is the 
scenario for ISIS ? Customers I know didn't try to do that with ISIS 
(ISP comments welcome here of course). Complicated IGP mechanisms have
been devised (OSPF tags) and ignored and there is a danger that same 
would happen here.  On the other hand, one vendor has route coloring and 
I heard that people are playing with it ;-))

So what I'm trying to say here I guess is that it would make sense 
to come up with a proposal for a full solution (route tags, tag sets, colors, 
whatever else) and in absence of such
having external tag on the route is well understood and solves some of 
the problem so it's better than nothing. 

	-- tony

---

From: "Christian E. Hopps" <[email-masked]>
Date: Sat, 4 Nov 2000 12:28:45 -0500

>   And it does a bad job of that.

[... example scenario when a single bit of information is not enough ...]

Indeed coloring with a byte is more powerful than with a bit.  I'm not
sure thats a strong argument against supporting both methods though.

The IPv6 draft, while supporting the TE sub-tlv and thus being compatible
with that direction of extension of the protocol, is not a TE extension.
When I designed it I wished to support the possiblity of a router
vendor implementing IPv4 and IPv6 regardless of whether the TE extensions
were also implemented.  One way I achieved this was by not requiring
the sub-tlv be understood (beyond parsing) for proper functioning.

This also carries over to deployment, a user familiar with the standard
behavoir may not yet be familiar with the proposed sub-tlv coloring scheme,
and may have no need to learn it.

Given this goal it seemed obvious to me that I should support the full
set of features from RFC1195 that were in current use today (i.e., basically
everything but external metrics because of "the bug" :), and that this
should not require supporting or understanding the new TE extensions.

I do think that the sub-tlv for coloring redistributed routes is a good
idea, but I am not sure I like the idea of requiring it to support even
the non-TE RFC1195 behavoir with IPv6.

If indeed this goal is unimportant then we can remove the bit; however,
I am not convinced I see the problem in supporting both the old and the new,
as yet to be defined, methods.

Chris.

---

From: Henk Smit <[email-masked]>
Date: Sun, 5 Nov 2000 18:29:17 +0100 (MET)

> We could tackle that problem of course,

  Either you solve the problem (using sub-TLVs to indicate the origine
 of a prefix) or you don't solve it. Using the binary mechanism
 from rfc1195 will not solve the problem. So I see no reason to
 copy that mechanism.

> but is anyone willing to put in the cycles ?

  Route redistribution is not rocket science.

  Besides that, IMHO most RFC talk about routing inside one IGP domain.
 There are no standards on how to deal with redistributing between IGPs.
 And IMHO there is no need for that. Redistrubution is something that
 is done inside a router, and thus is vendor specific. There must be
 some regions where vendors can show that they can solve problems without
 just imlementing what is in the RFCs. :-) The IGP must give a means
 to carry a tag, that is all. How to deal with it is up to each router
 vendor.
 
> As well, how realistic is the scenario for ISIS ? Customers I know
> didn't try to do that with ISIS  (ISP comments welcome here of course).

  I suspect that those customers you are talking about don't do any
 redistribution of other IGPs into IS-IS. :-)

> to come up with a proposal for a full solution (route tags, tag sets,
> colors, whatever else) and in absence of such

  I disagree here. I rather see a bad solution not implemented at all,
 in the hope that a good solution will be implemented later.

      Henk.