Subject: [Isis-wg] Last Call: 'M-ISIS: Multi Topology (MT) Routing in IS-IS' to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 07 Sep 2005 11:26:00 -0400

The IESG has received a request from the IS-IS for IP Internets WG to consider 
the following document:

- 'M-ISIS: Multi Topology (MT) Routing in IS-IS '
   <draft-ietf-isis-wg-multi-topology-10.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-09-21.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-10.txt

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Pekka Savola <[email-masked]>
Date: Mon, 12 Sep 2005 12:55:08 +0300 (EEST)

> http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-10.txt

The spec is needed, but needs polishing.  There are numerous ID-nits 
(don't number status of the memo, abstract sections; too long lines; 
etc.) -- see below *).

Section 11.4 states:

     No attempt is made in this draft to let the M-ISIS IPv6 topology to
     understand the "normal" IPv6 prefix with TLV type 236. A network
     SHOULD only run IS-IS either with IPv6 using type 236 or with M-ISIS
     IPv6 using type 237.

==> I'd like to see why this approach was adopted.  How does an 
operator transition from "regular" IS-IS to multi-topology IS-IS?  Is 
this approach reasonable (enough)?  Isn't the same issue also present 
for v4 MT-ISIS TLVs?

*) nits at:
  http://tools.ietf.org/wg/isis/draft-ietf-isis-wg-multi-topology/draft-ietf-isis-wg-multi-topology-10.nits.txt

The most significant one, which may require WG discussion is the lack 
of IANA considerations section.  Specifically, the assignment policies 
for MT ID values described in section 11.5 require to be spelled out 
especially for the upper-most block of numbers.  You will also need to 
give pointer to IANA to update the references to this draft for the 
TLVs that this draft has taken in 
http://www.iana.org/assignments/isis-tlv-codepoints when this gets 
published as an RFC.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Naiming Shen <[email-masked]>
Date: Wed, 14 Sep 2005 14:13:17 -0700

Hi Pekka,

thanks for the review, and see comments inline.

Pekka Savola said the following on 09/12/2005 02:55 AM:
> ==> I'd like to see why this approach was adopted.  How does an operator 
> transition from "regular" IS-IS to multi-topology IS-IS?  Is this 
> approach reasonable (enough)?  Isn't the same issue also present for v4 
> MT-ISIS TLVs?

It's the same issue. The IPv6 prefix with TLV type 236 is part of the
'standard' topology, just like the IPv4 prefix TLV. We don't try to
"merge" the IS-IS routing among different topologies.

For transition into MT ISIS, there are probably many ways to do
it depend on the network requirement. Usually MT is to add some
new service on top of the existing infrastructure. E.g. you want
to add a QoS topology using some high bandwidth links, when the
topology is ready, switch over VoIP traffic onto it gradually
from the edge boxes.

If one wants to replace the existing "normal" TLVs with the MT TLVs
completely without a flag day, then probably taking the approach
similar to IS-IS TE metric transition, announce both of them first
in both topologies, then switch traffic onto the new topology
one by one, then stop announcing in the old topology. I think
one router vendor already has such an implementation for
exactly this regarding IPv6 topology transition.

> The most significant one, which may require WG discussion is the lack of 
> IANA considerations section.  Specifically, the assignment policies for 
> MT ID values described in section 11.5 require to be spelled out 
> give pointer to IANA to update the references to this draft for the TLVs 
> that this draft has taken in 

I'll take care of the nits above. for the IANA, we received this message:

   IESG:

   The IANA has reviewed the following Internet-Draft which is in Last
   Call:  draft-ietf-isis-wg-multi-topology-10.txt,  and has the following
   with regards to the publication of this document:

   NO IANA Considerations section
   We understand this document to have NO IANA Actions.

   Thank you.

   Michelle Cotton
   (on behalf of IANA)

and yes, good point, we'll need to give them the pointers for updating
the content of http://www.iana.org/assignments/isis-tlv-codepoints
as you described.

thanks.
- Naiming

---

From: Pekka Savola <[email-masked]>
Date: Fri, 16 Sep 2005 09:37:23 +0300 (EEST)

On Wed, 14 Sep 2005, Naiming Shen wrote:
>> transition from "regular" IS-IS to multi-topology IS-IS?  Is this approach 
>> reasonable (enough)?  Isn't the same issue also present for v4 MT-ISIS 
>> TLVs?
>

How come the issue is only mentioned under IPv6 and not consistently 
with both or in a more generic place, like in introduction (smells 
like an applicability statement which should be clearly stated up 
front).

>> IANA considerations section.  Specifically, the assignment policies for MT 
>> ID values described in section 11.5 require to be spelled out especially 
>> for the upper-most block of numbers.  You will also need to give pointer to 
>> IANA to update the references to this draft for the TLVs that this draft 
>> has taken in http://www.iana.org/assignments/isis-tlv-codepoints when this 
>> gets published as an RFC.
>> 
>

Note that IANA *thinks* there is nothing to do (because the doc had no 
IANA considerations section), but they are wrong and you should give 
them a heads-up.  You probably need to create an IANA registry for the 
ID values and specify the assignment policy, as well as do minor 
updates on the existing registries.

---

From: Naiming Shen <[email-masked]>
Date: Mon, 19 Sep 2005 12:00:12 -0700

Pekka,

Pekka Savola said the following on 09/15/2005 11:37 PM:
>>>  this approach reasonable (enough)?  Isn't the same issue also
>>> present for v4 MT-ISIS TLVs?
>> 
>> 
> How come the issue is only mentioned under IPv6 and not consistently with
> both or in a more generic place, like in introduction (smells like an
> applicability statement which should be clearly stated up front).
> 

This draft has been dragged so long, from I recall, in the earlier versions,
when this IPv6 MT TLV was introduced, there were sentenses mentioning
to let the new topology to understand the "normal" topology IPv6 TLVs,
it had some one directional "merging" of routing intention at the time.
That was a mistake on author's side and was scrached in ver04 of the draft.
The above paragraph was added later due to someone want us to explicitly
mention that there was no relation between the two IPv6 topologies.
I think we should remove this paragraph now if there is no objection
from the working group.

>>>  of IANA considerations section.  Specifically, the assignment 
>>> policies for MT ID values described in section 11.5 require to be 
>>> spelled out especially for the upper-most block of numbers.  You will
>>>  also need to give pointer to IANA to update the references to this 
>>> draft for the TLVs that this draft has taken in 
>> NO IANA Considerations section We understand this document to have NO
>> IANA Actions.
>> 
>> Thank you.
>> 
>> Michelle Cotton (on behalf of IANA)
>> 
>> the content of http://www.iana.org/assignments/isis-tlv-codepoints as
>> you described.
> 
> 
> IANA considerations section), but they are wrong and you should give them
> a heads-up.  You probably need to create an IANA registry for the ID
> values and specify the assignment policy, as well as do minor updates on
> the existing registries.
> 

Ok, will do that. You may need to educate me on how to create an IANA
registry for this.

thanks.
- Naiming

---

From: Pekka Savola <[email-masked]>
Date: Tue, 20 Sep 2005 09:31:29 +0300 (EEST)

> I think we should remove this paragraph now if there is no objection

In principle, I think a generalized rewording of the applicability 
statement (for both v4 and v6) would be useful and should be included 
but it should be placed in the Introduction or some other relevant 
part of the spec so it's more prominent.

>> Note that IANA *thinks* there is nothing to do (because the doc had no IANA 
>> considerations section), but they are wrong and you should give them

Ok, maybe the example IANA considerations section below gives an idea 
how to instruct IANA to create a new registry.  Note: the text may 
need some tweaking, and there are issues which need to be ironed out, 
for example,
  - the assignment policies may need discussion in the WG -- i.e., is 
"IETF Consensus" (basically requires an IETF-published RFC and a bit 
more) appropriate for new assignments?
  - Should there be a FCFS or expert review mechanism to reserve a part 
of the experimental ID space so that the folks using those spaces 
could request them from IANA (instead of just grabbing a number at 
random)?
  - should the number 2^12-1 be reserved for special purposes if it'd 
ever be needed?

===========
IANA Considerations

   IANA is requested to create a new registry, "IS-IS multi-topology ID
   values" with the following assignments made in this document and
   registration policies for future assignments:

      -  MT ID #0:          Equivalent to the ``standard'' topology.
      -  MT ID #1:          Reserved for IPv4 in-band management purposes.
      -  MT ID #2:          Reserved for IPv6 routing topology.
      -  MT ID #3:          Reserved for IPv4 multicast routing topology.
      -  MT ID #4:          Reserved for IPv6 multicast routing topology.
      -  MT ID #5-#3995:    Assigned by IETF Consensus [RFC2434].
      -  MT ID #3996-#4095: Reserved for development, experimental and
                            proprietary features [RFC3692].

   IANA is also requested to update the IS-IS codepoint registry
   (http://www.iana.org/assignments/isis-tlv-codepoints) so that codes
   222, 229, 235 and 237 refer to this document's RFC number.

   [[ note to the RFC-editor: the above paragraph may be removed or
   reworded prior to RFC publication ]]

---

From: Naiming Shen <[email-masked]>
Date: Tue, 20 Sep 2005 14:05:00 -0700

Pekka Savola said the following on 09/19/2005 11:31 PM:
>>> with
> but it should be placed in the Introduction or some other relevant part 
> of the spec so it's more prominent.
> 

Sure, I'll update it somewhere in Introduction area.

>>> Note that IANA *thinks* there is nothing to do (because the doc had 
>>> no IANA considerations section), but they are wrong and you should 
>>> give them
> how to instruct IANA to create a new registry.  Note: the text may need 
> some tweaking, and there are issues which need to be ironed out, for 
> example,
> of the experimental ID space so that the folks using those spaces could 
> request them from IANA (instead of just grabbing a number at random)?

Cool. thanks for the suggested text. will update the draft.

thanks.
- Naiming