Subject: [Isis-wg] Comments on draft-ietf-isis-wg-multi-topology-09

From: "Mike Bartlett" <[email-masked]>
Date: Wed, 13 Apr 2005 11:39:24 +0100

Hello all,

I have just read this draft for the first time and have some comments on it.  Firstly there are two specific areas where I'm unsure how a router should behave when supporting this draft.  Secondly I have raised some editorial-type issues including typos.

I'd be grateful for your feedback on the points I have raised.

Many thanks,

Mike Bartlett

-------------------------------------------
Mike Bartlett
Network Protocols Group
Data Connection Ltd
Tel:	+44 20 8366 1177                 
Fax:	+44 20 8363 1039
Email:	[email-masked]    
Web:	http://www.dataconnection.com

Specific issues
---------------

1. Suppose that two routers R1 and R2 are exchanging IIHs over a point-to-point interface.  R1 supports the MT extensions and only uses MT ID#1 on this interface.  R2 is not including the MT capability TLV at all on its IIHs.  Should R1 attempt to form an adjacency?  In section 5.1 the specification of what to do seems contradictory to me.  

There are two conflicting possibilities.  In one case R1 should form an adjacency and in one case it shouldn't, but it has no way of telling which case applies.

a) It is possible that R2 does not support the MT extensions.  In this case the first sentence "Adjacencies on point-to-point interfaces are formed as usual with ISIS routers not implementing MT extensions" should apply - i.e. R1 should form an adjacency.

b) It is possible that R2 does support the MT extensions, but only uses MT ID#0 on this interface (in which case it does not have to advertize this MT ID).  In this case the last sentence "The local router SHOULD NOT form adjacency if they don't have at least one common MT set over the interface" should apply - i.e. R1 should NOT form an adjacency. 

2. Is it legal for a router R1 to advertize reachability to one IPv6 prefix P1 using MT ID #0 and to another IPv6 prefix P2 using a non-zero MT ID (for example MT ID #1)?  If this is legal, the specification of how to do this seems contradictory to me (section 11.4 this time).

a) In the corresponding IPv4 case (section 11.3) it seems clear that R1 should include TLV 135 for P1 and TLV 235 for P2 (because TLV 235 cannot be used for MT ID #0).  Section 11.4 also allows for this possibility in the IPv6 case - for the new TLV 237 it says "The TLV MUST be ignored if the ID is zero", which implies that TLV 236 must be used for P1 (MT ID #0) and TLV 237 for P2 (MT ID #1).

b) However, section 11.4 also says "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."  This would imply that it is illegal for R1 to generate both TLV types 236 and 237.  

Editorial comments
------------------

General:
a) Reading the draft for the first time, I found the layout difficult to follow.  For example I struggled with the following sentence in section 5 because some of the terminology has not yet been introduced - "Through this exchange of MT capabilities, a router is able to advertise the IS TLVs in LSPs with common MT set over those adjacencies."  I think it would be easier to read this document if the introduction section introduced the new TLVs and briefly explained their purpose.  Then the discussion in sections 5.1 and 5.2 about advertizing neighbors in LSPs would also be more understandable.

b) The various new TLVs are referred to by various different names, which is confusing.
- TLV 229 is variously referred to as "Multi-Topology TLV", "MT TLV", "MT capability TLV"
- TLV 222 is variously referred to as "MT IS TLV", "MT IS Reachable TLV", "MT Reachable Intermediate Systems TLV", "MT Intermediate Systems TLV"

Section 5.1: 
a) "it's" should read "its" in 2 places
b) "form adjacency" should read "form an adjacency"
c) "common MT set" should read "common MT" (or "overlapping MT sets")

Section 5.2: 
a) "it's" should read "its"
b) "common MT set" should read "a common MT" (or "overlapping MT sets")
c) "according" should read "the corresponding" (corresponding seems a better word to me than according)
d) the text should clarify that the MT IS Reachable TLV on the LAN contains the pseudonode's DIS ID as the neighbor ID.  The rule about "at least one adjacency" could be incorrectly taken to mean that the TLV should instead refer to the actual neighbor on that adjacency.

Section 6:
a) "according" should read "corresponding" in 2 places

Section 9: 
a) "it's" should read "its"
b) "according" should read "corresponding"

Section 10:
a) "common MT set" should read "common MT" (or "common MT capability", as per the next sentence)
b) "an point-to-point" should read "a point-to-point"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Cisco - David Ward
Sent: 04 April 2005 23:25
To: [email-masked]; [email-masked]; Naiming Shen; [email-masked]
Cc: [email-masked]; Cisco - David Ward
Subject: [Isis-wg] Last Call announcement

All -

We are announcing Last Call for:

M-ISIS: Multi Topology (MT) Routing in IS-IS

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

Please submit final comments before April 25th, 2005.

Thanks

Dave and Chris

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

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

---

From: Naiming Shen <[email-masked]>
Date: Thu, 14 Apr 2005 00:35:55 -0700

Mike,

See some replies inline.

Mike Bartlett said the following on 04/13/2005 03:39 AM:
  ] Hello all,
  ]
  ] I have just read this draft for the first time and have some comments
  ] on it.  Firstly there are two specific areas where I'm unsure how a
  ] router should behave when supporting this draft.  Secondly I have
  ] raised some editorial-type issues including typos.
  ]
  ] I'd be grateful for your feedback on the points I have raised.
  ]
  ] Many thanks,
  ]
  ] Mike Bartlett
  ]
  ] ------------------------------------------- Mike Bartlett Network
  ] Protocols Group Data Connection Ltd Tel:     +44 20 8366 1177
  ]  Fax:        +44 20 8363 1039 Email: [email-masked] Web:
  ] http://www.dataconnection.com
  ]
  ]
  ] Specific issues ---------------
  ]
  ] 1. Suppose that two routers R1 and R2 are exchanging IIHs over a
  ] point-to-point interface.  R1 supports the MT extensions and only
  ] uses MT ID#1 on this interface.  R2 is not including the MT
  ] capability TLV at all on its IIHs.  Should R1 attempt to form an
  ] adjacency?

R1 should attempt, and should fail to form adjacency in this case.

  ]  In section 5.1 the specification of what to do seems
  ] contradictory to me.
  ]
  ] There are two conflicting possibilities.  In one case R1 should form
  ] an adjacency and in one case it shouldn't, but it has no way of
  ] telling which case applies.
  ]
  ] a) It is possible that R2 does not support the MT extensions.  In
  ] this case the first sentence "Adjacencies on point-to-point
  ] interfaces are formed as usual with ISIS routers not implementing MT
  ] extensions" should apply - i.e. R1 should form an adjacency.
  ]

The first sentense just means there is no special procedure to form
an adjacency with a non-MT neighbor. But it does not mean they MUST
form adjacency. The later sentenses add more condition on what cases
they SHOULD NOT form adjacency over a p2p link.

  ] b) It is possible that R2 does support the MT extensions, but only
  ] uses MT ID#0 on this interface (in which case it does not have to
  ] advertize this MT ID).  In this case the last sentence "The local
  ] router SHOULD NOT form adjacency if they don't have at least one
  ] common MT set over the interface" should apply - i.e. R1 should NOT
  ] form an adjacency.

Correct. This is the condition they should not form adjacency.

  ]
  ] 2. Is it legal for a router R1 to advertize reachability to one IPv6
  ] prefix P1 using MT ID #0 and to another IPv6 prefix P2 using a
  ] non-zero MT ID (for example MT ID #1)?

Well, the MT ID #1 is defined as ipv4 mgmt topology, so you should
not put ipv6 routes there usually. But if you insist that MT ID#1
in your netowrk is for IPv6 usage, I think it's fine too;-)

Lets assume you meant putting in non-zero MT ID #x for example here.
Yes, it should be legal.

  ]  If this is legal, the
  ] specification of how to do this seems contradictory to me (section
  ] 11.4 this time).
  ]
  ] a) In the corresponding IPv4 case (section 11.3) it seems clear that
  ] R1 should include TLV 135 for P1 and TLV 235 for P2 (because TLV 235
  ] cannot be used for MT ID #0).  Section 11.4 also allows for this
  ] possibility in the IPv6 case - for the new TLV 237 it says "The TLV
  ] MUST be ignored if the ID is zero", which implies that TLV 236 must
  ] be used for P1 (MT ID #0) and TLV 237 for P2 (MT ID #1).

Ok.

  ]
  ] b) However, section 11.4 also says "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."  This would imply
  ] that it is illegal for R1 to generate both TLV types 236 and 237.

Hmm? does this imply it illegal?
This sentense is meant for an operator of a network
should not try to mix those two topologies in one network, since
they don't understand each other. Operators can obviously do that, it's
just that the result is not well defined or understood. that's all.
This does not imply router R1 can NOT advertise both TLV types. If they
are used properly for different purpose, for example during topology
transition, they actually may want to advertise both.

  ]
  ] Editorial comments ------------------
  ]
  ] General: a) Reading the draft for the first time, I found the layout
  ] difficult to follow.  For example I struggled with the following
  ] sentence in section 5 because some of the terminology has not yet
  ] been introduced - "Through this exchange of MT capabilities, a router
  ] is able to advertise the IS TLVs in LSPs with common MT set over
  ] those adjacencies."  I think it would be easier to read this document
  ] if the introduction section introduced the new TLVs and briefly
  ] explained their purpose.  Then the discussion in sections 5.1 and 5.2
  ] about advertizing neighbors in LSPs would also be more
  ] understandable.
  ]

It helps reading it multiple times;-) or try the PIM spec instead...
But seriously, at this stage, we are not going to change the structure
or layout of this document. sorry about that.

I'll fix the rest of the syntax related comments. many thanks
for spending time on this draft.

Cheers.
- Naiming

  ] b) The various new TLVs are referred to by various different names,
  ] which is confusing. - TLV 229 is variously referred to as
  ] "Multi-Topology TLV", "MT TLV", "MT capability TLV" - TLV 222 is
  ] variously referred to as "MT IS TLV", "MT IS Reachable TLV", "MT
  ] Reachable Intermediate Systems TLV", "MT Intermediate Systems TLV"
  ]
  ] Section 5.1: a) "it's" should read "its" in 2 places b) "form
  ] adjacency" should read "form an adjacency" c) "common MT set" should
  ] read "common MT" (or "overlapping MT sets")
  ]
  ] Section 5.2: a) "it's" should read "its" b) "common MT set" should
  ] read "a common MT" (or "overlapping MT sets") c) "according" should
  ] read "the corresponding" (corresponding seems a better word to me
  ] than according) d) the text should clarify that the MT IS Reachable
  ] TLV on the LAN contains the pseudonode's DIS ID as the neighbor ID.
  ] The rule about "at least one adjacency" could be incorrectly taken to
  ] mean that the TLV should instead refer to the actual neighbor on that
  ] adjacency.
  ]
  ] Section 6: a) "according" should read "corresponding" in 2 places
  ]
  ] Section 9: a) "it's" should read "its" b) "according" should read
  ] "corresponding"
  ]
  ] Section 10: a) "common MT set" should read "common MT" (or "common MT
  ] capability", as per the next sentence) b) "an point-to-point" should
  ] read "a point-to-point"
  ]