Subject: [Isis-wg] draft-ietf-isis-mi-07 draft

From: Uma Chunduri <[email-masked]>
Date: Fri, 12 Oct 2012 20:52:55 -0400

I have few questions/clarification on this draft (I discussed few with Les already and got the context of this technology, thanks).

1. Section 1
    " The   specification of uses of MI-IS-IS is outside the scope of this  document."

  Still 1 or 2 use cases of how this can be used as alternative to MT and with GENINFO will greatly improve the readability of the draft (in appendix) else it's definitely bit elusive.

 For E.g. as there is no significance of ITID value same V4 topology which is being used in ITID=0 can be used in ITID=1 but purely for transporting GENINFO TLV. Can this be a valid use case?

2. Section 2.1
        "IS-IS PDUs associated with the legacy instance MUST NOT include an IID-TLV except where noted in this document."
    It's not clear when  IID-TLV is expected from legacy system and how even this is possible  (as you are already saying legacy system/instance).
        "When the IID = 0, the list of supported ITIDs MUST NOT be present"
    This suggests IID=0 can only be used by routers if and only if all the nodes in the network have this feature on.  Can you confirm on this.

3.  Section 2.1
        "Multiple IID-TLVs MAY appear in IIHs. If multiple IID-TLVs are present and the IID value in all IID-TLVs is not the same then the PDU MUST BE ignored. "
    Why would one use multiple IIDs with same IID value? If multiple ITID are supported any ways in one IID - not clear what authors are seeing here.

4. Section 2.3
    "When multiple ITIDs are supported, ITID specific authentication MAY be used in SNPs and LSPs."

This is is not possible for IIH as multiple ITID can be encoded in the same PDU.  So, essentially all topologies will share the same AUTH config for SN
dependent if provisioned or  it takes instance AUTH parameters which are not topology (from instance) specific today. Now imagine, with multiple topologies,
topology specific AUTH keys are configured and no SN specific keys are provisioned (which is legit today ), then which topo specific AUTH key will be used by IIH messages?
I see allowing topology specific AUTH keys  for SNP and LSPs would be completely new (and need more discussion) and I find it hard to visualize the use case
why one would do this (I can think only from MT point of view now - say if MI is used instead of MT and this may not be needed but what authors see from GENINFO point of view).
If this is not understood clearly, it can lead to potential mis-configurations and confusions for folks who is deploying this technology.

5.  Section 4
     "There is no relationship between the Multi-topology IDs defined in [RFC5120] and the ITIDs defined in this document."
     "An MI-RTR MAY use the extensions defined in this document to support multiple topologies in the context of an instance with a non-zero IID.
       Each MI topology is associated with a unique LSDB identified by an ITID. An ITID specific IS-IS Update Process operates on each topology.
       This differs from [RFC5120] where a single LSDB/single IS-IS Update Process is used in support of all topologies."

a)If there is no relationship between MTID in 5120 and ITID here how computation actually happens say an instance supporting  V4 and V6 topologies as some TLVs are significant to particular topology as defined in 5120 today?

b) In MT, with multiple topologies all the TLVs corresponding to all the topologies are encoded and only  relevant TLVs are used for computing the routes. As only
one IID/ITID combination is allowed in LSP, and as it is not mandated any thing like witch TLVs should go in with particular ITID, it's possible one can still encode all
TLVs of all topologies but changing the IID/ITID field. I think this seemed to be left to implementations but as this is positioned as potential alternative to MT too, and any ways
multiple updates have to be sent with different ITIDs I feel restricting TLVs corresponding to the ITID will be more efficient.

6. Section 7

    It's already agreed, some stale sentences need to be cleaned-up there but if this draft is introducing topology specific AUTH keys it needs more description here on why and where this should be considered.

--
Uma C.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 13 Oct 2012 18:59:30 +0000

Uma -

From: [email-masked] [mailto:[email-masked]] On Behalf Of Uma Chunduri
Sent: Friday, October 12, 2012 5:53 PM
To: [email-masked]
Subject: [Isis-wg] draft-ietf-isis-mi-07 draft

1. Section 1

LES: The purpose of the draft is to provide a normative specification for the MI extensions to the protocol. Historically IS-IS RFCs and base spec have confined themselves to normative statements and do not provide detailed use case examples. We prefer to continue that approach in this document. Further information on GENAPP can be found in the reference to that draft. Although using MI as an alternative to RFC 5120 is a possible use case we are not promoting that idea - simply stating that MI can be used in that way.

LES: It is valid to run a legacy instance and a non-zero instance over the same topology.

2. Section 2.1

LES: What is being discussed here is the correct behavior when an MI capable router supports the legacy instance. In that case all PDUs associated w the legacy instance MUST NOT include an IID-TLV (with one exceptuion noted in Section 2.6.2).

3.  Section 2.1

LES: It is possible to include up to 126 ITIDs in a single IID-TLV. If an implementation supported more that 126 ITIDs on a given circuit it would require multiple IID-TLVs to advertise all of the supported ITIDs. The text in this section defines the correct behavior when multiple IID-TLVs are sent/received in an IIH i.e. the IID value MUST be the same in all of the TLVs and the set of supported ITIDs is the union of all ITIDs in all IID-TLVs.

4. Section 2.3

LES: The base specification (ISO 10589) and RFC 4304/5310 define three authentication contexts:

Circuit scoped authentication - used in IIHs
Area scoped authentication - Used in Level 1 SNPs and LSPs
Domain scoped authentication - used in Level2 SNPs and LSPs

In MI, the scope of SNPs/LSPs is further defined by an IID/ITID pair. It is then possible to have different authentication types/keys for each Level/IID/ITID scope. Whether an implementation would choose to support different authentication type/key for each IID/ITID pair is up to the implementation to determine.

5.  Section 4

LES: Different instances run as "ships in the night". A legacy instance shares no adjacencies or PDUs with a non-zero instance. There is no relationship between topology specific information advertised by a legacy instance using RFC 5120 extensions and a non-zero instance sending ITID specific information. SPFs run by a legacy instance would be based solely on the information advertised in PDUs associated w the legacy instance. Similarly, IID/ITID specific SPFs (if executed) would be based solely on the PDUs associated with that non-zero IID/ITID.

LES: All TLVs in a given LSP are associated with the IID/ITID which is encoded in that LSP.

6. Section 7

LES: Yes - the second paragraph in Section 7 is left over from earlier versions of the draft where the inclusion of IID-TLV in legacy instance PDUs was allowed. However we now prohibit the inclusion of IID-TLV in legacy instance PDUs so this paragraph is no longer relevant and will be deleted from the final text. Thanx for your help in identifying this oversight.
   Les

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 15 Oct 2012 11:50:13 -0400

Les,

Please see in-line [Uma]:

1. Section 1

LES: "Although using MI as an alternative to RFC 5120 is a possible use case we are not promoting that idea - simply stating that MI can be used in that way.

[Uma]: This statement directly contradicts one of the potential uses of of the document as mentioned in Introduction and all along.

             Section-1 Says:   "MI-IS-IS might be used to support topology specific routing.  When  used for this purpose it is an alternative to [RFC5120]."
                      "An MI-RTR MAY use the extensions defined in this document to support  multiple topologies in the context of an instance with a non-zero  IID.  "
     Section-4 Says:  "Although  it is possible for an MI-RTR to use [RFC5120] multi-topology support   within a non-zero instance such usage is seen as unnecessary and is discouraged"

Per Section-4 above, usage of MT in non-zero MI instance is discouraged and now you are saying completely different thing  i.e., usage of MI as an alternative to 5120 is not at all being promoted.

First of all the question is - can MI be used as alternative to 5120? If yes, this document should be more clear how ?
If indeed MI is an alternative to MT as per 07 version, then I saw multiple problems as discussed in item 5 below.

2. Section 2.1

[Uma]:  Section 2:     "Instance identifier #0 is reserved for the standard instance   supported by legacy systems."
      Section 2.6.1- "these PDUs being   processed by legacy routers and therefore no disruption is caused.."..
                     "legacy systems  will interpret these PDUs as being associated with IID #0

IID=0 is being represented as standard instance and the word legacy is used in different context in rest of the document and here legacy word is being used differently and doesn't resonate well  (MI capable router in IID=0). Though it's not a big deal it confuses the reader. Probably you need to clear the intent better there.

[Uma]: Yes, as per base standard only area or domain level AUTH scope is defined. Now this is further fragmented with topology granularity with in the L1 area or L2 domain.
               Les,  I don't think this is about implementation choice rather this is a deployment question. When you are providing this level of granularity (further to base spec), I presume
              authors foresee some issue with same key with much bigger (?) scope especially when MI is used in conjunction with APP info transport?
              It's ok to have IID/ITID specific AUTH but one should know consequences of not using if it is indeed needed in Section 7.

5.  Section 4

[Uma]: Ok, here is a simple example .  Say, to get all the advantages of Paragraph 3 and 4 in Section 1 - and I am still with the statement below:
"MI-IS-IS might be used to support topology specific routing.  When  used for this purpose it is an alternative to [RFC5120]."
say one chooses to deploy MI instead of MT and standard instance (IID=0) is used for IPV4 and IID=x and ITID=y is used for IPv6 topology . Let's make it simple and further assume all
links are shared across standard IID and IID=x. Now:
a. as there is no significance of ITID how other vendor nodes in the network know this is V6 topology and you are supposed to expand TLVs corresponding to V6 in SPF? (no MT here)
b. even the node which is doing packing know how ITID=y corresponds to IPv6 and tend to put only V6 related TLVs (now http://tools.ietf.org/html/rfc5308 is the only choice here).
or
you see -  keeping  all topology information in both standard IID and IID=x and ITID=y (no MT) and advertise is an option (use 5308 and only one SPF yields all)? Then why one would bother to put IID/ITID? Do you still the advantage?
The more I see... ok, will wait for your response first.

--
Uma C.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 16 Oct 2012 03:14:21 +0000

Uma -

From: Uma Chunduri [mailto:[email-masked]]
Sent: Monday, October 15, 2012 8:50 AM
To: Les Ginsberg (ginsberg); [email-masked]
Subject: RE: draft-ietf-isis-mi-07 draft

Les,

1. Section 1

LES2: You are confusing two different use cases.

Use Case 1:  Use MI as an alternative to RFC 5120. In this case a non-zero instance supports multiple ITIDs. The differences between this and use of RFC 5120 in Instance #0 (the standard instance) are discussed in Section 4.

Use Case 2: In the context of a non-zero instance and a single ITID - support multiple MTIDs as defined in RFC 5120. In this case the MTIDs would define topologies which are subsets of the topology defined by a given IID/ITID pair. This can be done by advertising MT TLVs (222, 235, 237) in LSPs which are themselves scoped by a given IID/ITID.

It is use case #2 which we are discouraging.

When I say "we are not promoting [use case 1]"  I simply mean that the draft is agnostic on this issue. We define the protocol extensions - what the most common use cases turn out to be is for the marketplace to determine.

2. Section 2.1

LES2: It is common practice to refer to routers which do not support the protocol extensions being defined in a new standard as "legacy routers". We are very careful to state (Section 1):

" Legacy routers support the standard  or zero instance of the protocol.  The behavior of the standard  instance is not changed in any way by the extensions defined in this  document."

I do not see how the text in the document contributes to your confusion.

 LES2: There are three (not two) defined authentication scopes (as I specified above). Try searching ISO 10589 for the strings:
   circuitTransmitPassword
   areaTransmitPassword
   domainTransmitPassword

There is no requirement that each of these passwords be unique. It is possible to successfully deploy authentication using the same key for all scopes. The restriction that the base spec (and RFC 5304/5310) define is that there are at most three scopes.
With MI, an additional scope is defined (IID/ITID) for LSPs/SNPs. As I have stated multiple times, the draft is agnostic on whether it is desirable to use different keys for each IID/ITID - we are simply saying that it is possible to do so.

Please do not abuse my very clear statements on this point by saying "authors foresee some issue with same key...". We do not foresee an issue - if we did we would clearly state this.

As always, within the available scopes, how many different keys are used is a decision made by those who deploy authentication in their networks.

5.  Section 4

LES2: What a given topology is used for is not enforced by the protocol. This is true for RFC 5120 as well as MI.

There are "conventions(sic)" defined in RFC 5120 for a few reserved MTIDs - but this covers only 6 of the possible 4K MTIDs. If other MTIDs are used there clearly must be agreement on what purpose that topology serves - whether it be to support routing of a given address family or some other purpose. However the protocol has no way of advertising or enforcing such usage. It depends on consistent configuration network wide.

You are quite correct that inconsistent usage of a topology by nodes in the network will be problematical - but this is not an issue which is being addressed by the standards - either 5120 or MI.

   Les

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 16 Oct 2012 12:24:43 -0400

Les,

Section-1: "MI-IS-IS might be used to support topology specific routing. When used for this purpose it is an alternative to [RFC5120]."
How?

You still didn't answer my question - how one might use MI as an alternative to current RFC 5120? (neither the draft).

Few quick clarifications below [Uma2]:

--
Uma C.

2. Section 2.1

[Uma2]: I was talking about legacy instance statement as referred in sec 2.1 -- I got this with difficulty -  you mean to say standard instance there .. (MI capable router in IID=0 etc..)

 ---

[Uma2]:
First of all let me be clear on what I feel about on this draft overall:
        - this is just not a simple TLV addition or minor extension to the protocol, rather this draft gives immense potential to use IS-IS differently (I see this as a "technology" in itself)
        - have immense respect for you, your wisdom and rest of the authors of the draft
        - I clearly saw the ALTO/genapp use case this is addressing except the main question on MT case.

Now coming to the abuse claim in the context of AUTH you made- not sure why even feel that way.
I am simply asking - if it is required to define a new topology-level  authentication for the first time for IS-IS, at minimum it warrants few statements to clarify on why and how this is more useful.
Absolutely, at the end of the day it's the decision made by the folks who deploy this technology.
But, more description around this  will facilitate the right deployment decisions and will not cause over/under usage.

5.  Section 4

LES2: What a given topology is used for is not enforced by the protocol. This is true for RFC 5120 as well as MI.
[Uma2]: Your statement above is not correct completely.  5120 indeed enforces what is MTID 1 or 2 to 6, and that's absolutely useful. When, I say MTID 2 everybody in the network  knows what I am talking and what has to be done precisely (and I see no issue for my use case above).

   Les

--
Uma C.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 17 Oct 2012 05:39:02 +0000

From: Uma Chunduri [mailto:[email-masked]]
Sent: Tuesday, October 16, 2012 9:25 AM
To: Les Ginsberg (ginsberg); [email-masked]
Subject: RE: draft-ietf-isis-mi-07 draft

Les,

LES3: Section 2 defines how the set of topologies (ITIDs) supported on a given circuit are advertised in IIHs and how topology specific neighbor/reachability information is advertised in topology (ITID) specific LSPs. Section 4 - especially the last paragraph - specifically addresses the differences between RFC 5120 and MI multi-topology support.  The necessary information is in the draft.

--
Uma C.

2. Section 2.1

LES3: I agree the use of "legacy" in the sentence you have quoted above should be replaced by "standard". We will make that change.  Thanx for pointing this out.

I have nothing to add to the comments I have previously made on the threads below.

   Les

 ---

[Uma2]:

5.  Section 4

   Les

--
Uma C.