From adrian@olddog.co.uk Sat Oct 6 03:02:09 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DD821F853A for ; Sat, 6 Oct 2012 03:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTW4pqtRzbWl for ; Sat, 6 Oct 2012 03:02:09 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 18C2A21F860E for ; Sat, 6 Oct 2012 03:02:02 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q96A21DK010349 for ; Sat, 6 Oct 2012 11:02:01 +0100
Received: from 950129200 ([31.99.74.235]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q96A1xik010322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 6 Oct 2012 11:02:00 +0100
From: "Adrian Farrel"
To:
References: <20121005180149.3032.42028.idtracker@ietfa.amsl.com>
In-Reply-To: <20121005180149.3032.42028.idtracker@ietfa.amsl.com>
Date: Sat, 6 Oct 2012 11:01:59 +0100
Message-ID: <125001cda3a9$a0e69940$e2b3cbc0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH0YYvFe90q5LpjwaYD4fWye8XnA5dej//Q
Content-Language: en-gb
Subject: [Isis-wg] FW: I-D Action: draft-chunduri-karp-is-is-gap-analysis-02.txt
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 06 Oct 2012 10:02:10 -0000
Heads up
> -----Original Message-----
> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]
> On Behalf Of internet-drafts@ietf.org
> Sent: 05 October 2012 19:02
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-chunduri-karp-is-is-gap-analysis-02.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : KARP IS-IS security gap analysis
> Author(s) : Uma Chunduri
> Albert Tian
> Wenhu Lu
> Filename : draft-chunduri-karp-is-is-gap-analysis-02.txt
> Pages : 12
> Date : 2012-10-05
>
> Abstract:
> This document analyzes the threats applicable for Intermediate system
> to Intermediate system (IS-IS) routing protocol and security gaps
> according to the KARP Design Guide. This document also provides
> specific requirements to address the gaps with both manual and auto
> key management protocols.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-chunduri-karp-is-is-gap-analysis
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-chunduri-karp-is-is-gap-analysis-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-chunduri-karp-is-is-gap-analysis-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
From ginsberg@cisco.com Sun Oct 7 13:46:10 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059C621F870E; Sun, 7 Oct 2012 13:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.449
X-Spam-Level:
X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzhEpg+HIDpf; Sun, 7 Oct 2012 13:46:09 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 076D121F86E5; Sun, 7 Oct 2012 13:46:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2830; q=dns/txt; s=iport; t=1349642769; x=1350852369; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PyGDe4a8SP1H3t+brvo5hDQVj245b3P0+oaSTIgJQWk=; b=fGBcJ6Q6cFhyYfXL6bP/oLQ6ZuNvgig3rpVK69GOtSfOOrRJsl6PXv/j IGTnLk+o9/8Io3Mk1VsxyMbkMb/vpzF55Nl3HUYbuTzKVReT7YbOEBw8k m3h0IWmV9m/yDPM+gmPTV6AfSJ52TGf/0JUMtojAJbhwUocv3j/DZajZ0 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAJTpcVCtJXG+/2dsb2JhbABFvyGBCIIgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCAEIAgQBEggBGYdjC5kDnneLTxqFFmADlwCKEYMfgWmCbYFjNA
X-IronPort-AV: E=Sophos;i="4.80,548,1344211200"; d="scan'208";a="129191458"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 07 Oct 2012 20:46:08 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q97Kk8ZB002967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Oct 2012 20:46:08 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Sun, 7 Oct 2012 15:46:08 -0500
From: "Les Ginsberg (ginsberg)"
To: "isis-wg@ietf.org" , "karp@ietf.org"
Thread-Topic: [Isis-wg] FW: I-D Action: draft-chunduri-karp-is-is-gap-analysis-02.txt
Thread-Index: AQH0YYvFe90q5LpjwaYD4fWye8XnA5dej//QgAJEdcA=
Date: Sun, 7 Oct 2012 20:46:08 +0000
Message-ID:
References: <20121005180149.3032.42028.idtracker@ietfa.amsl.com> <125001cda3a9$a0e69940$e2b3cbc0$@olddog.co.uk>
In-Reply-To: <125001cda3a9$a0e69940$e2b3cbc0$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.144.60]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19250.001
x-tm-as-result: No--42.426500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Isis-wg] FW: I-D Action: draft-chunduri-karp-is-is-gap-analysis-02.txt
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 07 Oct 2012 20:46:10 -0000
The draft fails to mention (Section 2.3.1(2)) that the mechanisms defined i=
n the IS-IS base specification (ISO 10589) provide for efficient recovery f=
rom all LSP replay attacks - including inter-session replay.=20
This is particularly disappointing in that this point has been discussed at=
some length in the context of draft-chunduri-isis-extended-sequence-no-tl=
v. Please see:
http://www.ietf.org/mail-archive/web/isis-wg/current/msg03023.html
Les
> -----Original Message-----
> From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behal=
f Of
> Adrian Farrel
> Sent: Saturday, October 06, 2012 3:02 AM
> To: isis-wg@ietf.org
> Subject: [Isis-wg] FW: I-D Action: draft-chunduri-karp-is-is-gap-analysis=
-
> 02.txt
>=20
> Heads up
>=20
> > -----Original Message-----
> > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.o=
rg]
> > On Behalf Of internet-drafts@ietf.org
> > Sent: 05 October 2012 19:02
> > To: i-d-announce@ietf.org
> > Subject: I-D Action: draft-chunduri-karp-is-is-gap-analysis-02.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> >
> > Title : KARP IS-IS security gap analysis
> > Author(s) : Uma Chunduri
> > Albert Tian
> > Wenhu Lu
> > Filename : draft-chunduri-karp-is-is-gap-analysis-02.txt
> > Pages : 12
> > Date : 2012-10-05
> >
> > Abstract:
> > This document analyzes the threats applicable for Intermediate syste=
m
> > to Intermediate system (IS-IS) routing protocol and security gaps
> > according to the KARP Design Guide. This document also provides
> > specific requirements to address the gaps with both manual and auto
> > key management protocols.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-chunduri-karp-is-is-gap-analysis
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-chunduri-karp-is-is-gap-analysis-02
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-chunduri-karp-is-is-gap-analys=
is-02
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-Announce@ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
From uma.chunduri@ericsson.com Mon Oct 8 13:12:44 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C0321F87FC; Mon, 8 Oct 2012 13:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkgCm1AVaN1M; Mon, 8 Oct 2012 13:12:44 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC4421F8702; Mon, 8 Oct 2012 13:12:44 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q98KBZWQ013534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 15:12:43 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.44]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 8 Oct 2012 16:12:23 -0400
From: Uma Chunduri
To: "Les Ginsberg (ginsberg)" , "isis-wg@ietf.org" , "karp@ietf.org"
Date: Mon, 8 Oct 2012 16:12:22 -0400
Thread-Topic: [karp] [Isis-wg] FW: I-D Action: draft-chunduri-karp-is-is-gap-analysis-02.txt
Thread-Index: AQH0YYvFe90q5LpjwaYD4fWye8XnA5dej//QgAJEdcCAAYOT4A==
Message-ID:
References: <20121005180149.3032.42028.idtracker@ietfa.amsl.com> <125001cda3a9$a0e69940$e2b3cbc0$@olddog.co.uk>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Isis-wg] [karp] FW: I-D Action: draft-chunduri-karp-is-is-gap-analysis-02.txt
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 08 Oct 2012 20:12:45 -0000
Les,
Your point is valid and it is relevant to mention the what ever current rec=
overy mechanism we have in the face of the attack.=20
This is precisely one of the goals of the document and we will take this c=
omment.
--=20
Uma C.=20
PS: The link you mentioned below is regarding the partial deployment issue =
you pointed out (with ESN TLV draft) and you know=20
we are working with you on that as we speak.
-----Original Message-----
From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of Les=
Ginsberg (ginsberg)
Sent: Sunday, October 07, 2012 1:46 PM
To: isis-wg@ietf.org; karp@ietf.org
Subject: Re: [karp] [Isis-wg] FW: I-D Action: draft-chunduri-karp-is-is-gap=
-analysis-02.txt
The draft fails to mention (Section 2.3.1(2)) that the mechanisms defined i=
n the IS-IS base specification (ISO 10589) provide for efficient recovery f=
rom all LSP replay attacks - including inter-session replay.=20
This is particularly disappointing in that this point has been discussed at=
some length in the context of draft-chunduri-isis-extended-sequence-no-tl=
v. Please see:
http://www.ietf.org/mail-archive/web/isis-wg/current/msg03023.html
Les
> -----Original Message-----
> From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On=20
> Behalf Of Adrian Farrel
> Sent: Saturday, October 06, 2012 3:02 AM
> To: isis-wg@ietf.org
> Subject: [Isis-wg] FW: I-D Action:=20
> draft-chunduri-karp-is-is-gap-analysis-
> 02.txt
>=20
> Heads up
>=20
> > -----Original Message-----
> > From: i-d-announce-bounces@ietf.org=20
> > [mailto:i-d-announce-bounces@ietf.org]
> > On Behalf Of internet-drafts@ietf.org
> > Sent: 05 October 2012 19:02
> > To: i-d-announce@ietf.org
> > Subject: I-D Action: draft-chunduri-karp-is-is-gap-analysis-02.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> >
> > Title : KARP IS-IS security gap analysis
> > Author(s) : Uma Chunduri
> > Albert Tian
> > Wenhu Lu
> > Filename : draft-chunduri-karp-is-is-gap-analysis-02.txt
> > Pages : 12
> > Date : 2012-10-05
> >
> > Abstract:
> > This document analyzes the threats applicable for Intermediate syste=
m
> > to Intermediate system (IS-IS) routing protocol and security gaps
> > according to the KARP Design Guide. This document also provides
> > specific requirements to address the gaps with both manual and auto
> > key management protocols.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-chunduri-karp-is-is-gap-analy
> > sis
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-chunduri-karp-is-is-gap-analysis-02
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-chunduri-karp-is-is-gap-analy
> > sis-02
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-Announce@ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html or=20
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp
From uma.chunduri@ericsson.com Tue Oct 9 16:35:50 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE7611E80E2; Tue, 9 Oct 2012 16:35:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2BbClS75-To; Tue, 9 Oct 2012 16:35:50 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3B911E80D5; Tue, 9 Oct 2012 16:35:50 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q99NaUvp018410; Tue, 9 Oct 2012 18:36:32 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.44]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 9 Oct 2012 19:35:43 -0400
From: Uma Chunduri
To: "Les Ginsberg (ginsberg)" , "Bhatia, Manav (Manav)" , "Naiming Shen (naiming)"
Date: Tue, 9 Oct 2012 19:35:42 -0400
Thread-Topic: draft-chunduri-isis-extended-sequence-no-tlv - other comments
Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQAAJooMAAEcn4IAAkpaZwAAF6EGAARrMx8AAHbW2QABsjBQAleEa6QA==
Message-ID:
References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.com> <7C 362EEF9C7896 468B36C9B79200D8350D02E41D5D@INBANSXCHMBSA1.in.alcatel-lucent.com>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D1D8138DDF34B34B8BC68A11262D10792B6128E36AEUSAACMS0701e_"
MIME-Version: 1.0
Cc: Mike Shand , "isis-wg@ietf.org" , "karp@ietf.org"
Subject: Re: [Isis-wg] draft-chunduri-isis-extended-sequence-no-tlv - other comments
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 09 Oct 2012 23:35:50 -0000
--_000_D1D8138DDF34B34B8BC68A11262D10792B6128E36AEUSAACMS0701e_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Les,
Replies in-line [Uma]:
Here are the remainder of my comments on the draft:
In regards to SNPs, the presence of replayed SNPs will cause unnecessary re=
flooding of LSPs but will not actually cause any change in the LSPDB of any=
router. The unnecessary flooding would be limited to the link on which the=
replayed SNPs appear. Because no actual LSPDB changes would occur as a res=
ult of replayed SNPs, this is the one usage which could be enabled in the p=
resence of partial deployment.
In regards to IIHs, replayed IIHs could cause adjacency flapping which coul=
d be very disruptive. The danger lies when not all systems on a link suppor=
t the extension - which on multi-access links can lead to multiple DISs bei=
ng elected and violations of the assumption of transitivity. For this reaso=
n, enablement cannot be safely done in the presence of legacy systems.
[Uma]: draft-chunduri-isis-extended-sequence-no-tlv-02.txt has been update=
d (section 5) to cover the partial deployment cases. This addressees not on=
ly IIH but all PDUs. There is no flag day requirement here.
Given the discussion in the draft about enhancements to provide routing pro=
tocols with a group key management protocol in the future, it is prudent to=
look at the value add of extended sequence #s in the presence of a group k=
ey management protocol. The cost of having router vendors and their custome=
rs implement, deploy, and support extended sequence #s must be weighed agai=
nst the benefits.
[Uma]: You talked about the cost above. When an operator deploys any key m=
anagement protocol in general, the advantages it brings in are far more big=
ger than the mitigation of replay attacks. But, the cost could be prohibi=
tive if any key management protocol including group key management is deplo=
yed only for the purpose of replay protection. Just for this reason a manu=
al key mechanism to effectively eliminate the issue with replay attack is a=
lways useful. This is clearly discussed in Section 1 of the document. It's =
also worth mentioning here, neither such a group keying RFC which can deri=
ve keys for a group IGPs look for exist yet nor a smooth mechanism for int=
egration yet defined.
As discussed in an earlier thread, IS-IS already has a reliable mechanism t=
o recover from replayed LSPs.
[Uma]: We discussed in length on this and reliable recovery comes only afte=
r the replay is successful and the certain damage it brings in all over.
We take this opportunity acknowledge for providing early feedback on the so=
lution for partial deployment issue.
--
Uma C.
--_000_D1D8138DDF34B34B8BC68A11262D10792B6128E36AEUSAACMS0701e_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Les,
Replies in-line [Uma]:
Here are the remainder of my comments on the draft:
=
In=20
regards to SNPs, the presence of replayed SNPs will cause unnecessary reflo=
oding=20
of LSPs but will not actually cause any change in the LSPDB of any router. =
The=20
unnecessary flooding would be limited to the link on which the replayed SNP=
s=20
appear. Because no actual LSPDB changes would occur as a result of replayed=
=20
SNPs, this is the one usage which could be enabled in the presence of parti=
al=20
deployment.
In regards to IIHs, replayed IIHs could cause adjacency=
=20
flapping which could be very disruptive. The danger lies when not all syste=
ms on=20
a link support the extension - which on multi-access links can lead to mult=
iple=20
DISs being elected and violations of the assumption of transitivity. For th=
is=20
reason, enablement cannot be safely done in the presence of legacy=20
systems.
[Uma]: =20
draft-chunduri-isis-extended-sequence-no-tlv-02.txt has been updated (secti=
on 5)=20
to cover the partial deployment cases. This addressees not only IIH but all=
=20
PDUs. There is no flag day requirement here.
Given the discus=
sion=20
in the draft about enhancements to provide routing protocols with a group k=
ey=20
management protocol in the future, it is prudent to look at the value add o=
f=20
extended sequence #s in the presence of a group key management protocol. Th=
e=20
cost of having router vendors and their customers implement, deploy, and su=
pport=20
extended sequence #s must be weighed against the benefits.
[Uma]: You talked about the cost ab=
ove. When=20
an operator deploys any key management protocol in general, the advan=
tages=20
it brings in are far more bigger than the mitigation of replay=20
attacks. But, the cost could be prohibitive if any key management pro=
tocol=20
including group key management is deployed only  =
;for=20
the purpose of replay protection. Just for this reason a manual key mechani=
sm to=20
effectively eliminate the issue with replay attack is always useful. This i=
s=20
clearly discussed in Section 1 of the document. It's also worth mentio=
ning=20
here, neither such a group keying RFC which can derive keys for =
a=20
group IGPs look for exist yet nor a smooth mechanism for integration =
yet=20
defined.
As discussed in an earlier thread, IS-IS already has a reliable mechanis=
m to=20
recover from replayed LSPs.
[Uma]: We discussed in length on this and reliable=
=20
recovery comes only after the replay is successful and the certain dam=
age=20
it brings in all over.
We take this opportunity acknowledge for provi=
ding=20
early feedback on the solution for partial deployment issue.
--
Uma C.
--_000_D1D8138DDF34B34B8BC68A11262D10792B6128E36AEUSAACMS0701e_--
From ginsberg@cisco.com Wed Oct 10 21:16:43 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9F521F8608; Wed, 10 Oct 2012 21:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.478
X-Spam-Level:
X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvplKEt57ggF; Wed, 10 Oct 2012 21:16:40 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E377521F860B; Wed, 10 Oct 2012 21:16:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15597; q=dns/txt; s=iport; t=1349929000; x=1351138600; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L/+W5s7NMa41LnhutboGXtanTC/yzJvASrSaqX3v9hU=; b=fDVTNtog4nzuB+rDSjo7P4JFBZOprzL5O6Ky0ahdkWHkOEgtyZvQ4gI5 mcgCr8sCDQdI3LdrimC2j34N0AED0FxNY3KvC28ZNv8h/4tEMPHlL/Jv1 XyZtgCHADj6djgPlgz4t6XTgwvecu0tjyQOrjVyRjxQc7jZ7ml5vsUPEb 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAK1HdlCtJV2Y/2dsb2JhbABEgku8cIEIgiABAQEEEgEaTBACAQgRBAEBCx0HMhQJCAIEAQ0FCBMHh2KYU6Abi0cUhSxgA4s9kH+HdYFrgm2BWj0
X-IronPort-AV: E=Sophos;i="4.80,569,1344211200"; d="scan'208,217";a="127415918"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 11 Oct 2012 04:16:39 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9B4GdCZ004028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Oct 2012 04:16:39 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Wed, 10 Oct 2012 23:16:38 -0500
From: "Les Ginsberg (ginsberg)"
To: Uma Chunduri , "Bhatia, Manav (Manav)" , "Naiming Shen (naiming)"
Thread-Topic: draft-chunduri-isis-extended-sequence-no-tlv - other comments
Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQAAJooMAAEcn4IAAkpaZwAAF6EGAARrMx8AAHbW2QABsjBQAleEa6QAA8ENiA
Date: Thu, 11 Oct 2012 04:16:37 +0000
Message-ID:
References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.com> <7C 362EEF9C7896 468B36C9B79200D8350D02E41D5D@INBANSXCHMBSA1.in.alcatel-lucent.com>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.127.197]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19258.000
x-tm-as-result: No--36.989500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F11840654xmbalnx02ciscoc_"
MIME-Version: 1.0
Cc: Mike Shand , "isis-wg@ietf.org" , "karp@ietf.org"
Subject: Re: [Isis-wg] draft-chunduri-isis-extended-sequence-no-tlv - other comments
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 11 Oct 2012 04:16:43 -0000
--_000_F3ADE4747C9E124B89F0ED2180CC814F11840654xmbalnx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Uma -
In regards to the new Section 5 on deployment considerations, I think your =
presentation is a bit misleading. It suggests that if you follow the steps =
outlined (enable send only, then enable verify) that you are guaranteed a h=
itless transition. But this is only the case if there is no replay attack o=
ccurring during the transition. I think you need to emphasize that for the =
appropriate scope (link for IIHs, SNPs - area/domain for LSPs) that the tra=
nsition to "verify" needs to be made as close to atomically as possible so =
as to avoid inconsistencies which can occur if a replay attack occurs durin=
g the transition window.
In regards to the usefulness of the extension in LSPs I think your presenta=
tion is less than candid. You say in Section 2 that LSPs are vulnerable to =
inter-session replay attack - but, as we have previously discussed at lengt=
h, the inter-session LSP replay attack scenarios are highly unlikely and th=
e same base protocol mechanisms which protect LSPs against intra-session re=
plays also allow the protocol to quickly recover from inter-session attacks=
. This differs markedly from the case for IIHs and SNPs where no replay pro=
tection is available at present.
The value add of Extended Sequence # in LSPs is about as close to nil as on=
e can get. I would much prefer if the use of Extended Sequence #s in LSPs w=
as removed from the draft (with explanation as to why). If you are unwillin=
g to do that at least be fair in your presentation. You have a good use cas=
e argument for IIHs and SNPs - but the case for LSPs is quite weak and it w=
ould be good to be candid about that so vendors/customers can understand th=
e value proposition .
Les
From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]
Sent: Tuesday, October 09, 2012 4:36 PM
To: Les Ginsberg (ginsberg); Bhatia, Manav (Manav); Naiming Shen (naiming)
Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org
Subject: RE: draft-chunduri-isis-extended-sequence-no-tlv - other comments
Les,
Replies in-line [Uma]:
Here are the remainder of my comments on the draft:
In regards to SNPs, the presence of replayed SNPs will cause unnecessary re=
flooding of LSPs but will not actually cause any change in the LSPDB of any=
router. The unnecessary flooding would be limited to the link on which the=
replayed SNPs appear. Because no actual LSPDB changes would occur as a res=
ult of replayed SNPs, this is the one usage which could be enabled in the p=
resence of partial deployment.
In regards to IIHs, replayed IIHs could cause adjacency flapping which coul=
d be very disruptive. The danger lies when not all systems on a link suppor=
t the extension - which on multi-access links can lead to multiple DISs bei=
ng elected and violations of the assumption of transitivity. For this reaso=
n, enablement cannot be safely done in the presence of legacy systems.
[Uma]: draft-chunduri-isis-extended-sequence-no-tlv-02.txt has been update=
d (section 5) to cover the partial deployment cases. This addressees not on=
ly IIH but all PDUs. There is no flag day requirement here.
Given the discussion in the draft about enhancements to provide routing pro=
tocols with a group key management protocol in the future, it is prudent to=
look at the value add of extended sequence #s in the presence of a group k=
ey management protocol. The cost of having router vendors and their custome=
rs implement, deploy, and support extended sequence #s must be weighed agai=
nst the benefits.
[Uma]: You talked about the cost above. When an operator deploys any key m=
anagement protocol in general, the advantages it brings in are far more big=
ger than the mitigation of replay attacks. But, the cost could be prohibi=
tive if any key management protocol including group key management is deplo=
yed only for the purpose of replay protection. Just for this reason a manu=
al key mechanism to effectively eliminate the issue with replay attack is a=
lways useful. This is clearly discussed in Section 1 of the document. It's =
also worth mentioning here, neither such a group keying RFC which can deri=
ve keys for a group IGPs look for exist yet nor a smooth mechanism for int=
egration yet defined.
As discussed in an earlier thread, IS-IS already has a reliable mechanism t=
o recover from replayed LSPs.
[Uma]: We discussed in length on this and reliable recovery comes only afte=
r the replay is successful and the certain damage it brings in all over.
We take this opportunity acknowledge for providing early feedback on the so=
lution for partial deployment issue.
--
Uma C.
--_000_F3ADE4747C9E124B89F0ED2180CC814F11840654xmbalnx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Uma –
<=
/p>
In regards to the new Sec=
tion 5 on deployment considerations, I think your presentation is a bit mis=
leading. It suggests that if you follow the steps outlined
(enable send only, then enable verify) that you are guaranteed a hitless t=
ransition. But this is only the case if there is no replay attack occurring=
during the transition. I think you need to emphasize that for the appropri=
ate scope (link for IIHs, SNPs –
area/domain for LSPs) that the transition to “verify” needs to=
be made as close to atomically as possible so as to avoid inconsistencies =
which can occur if a replay attack occurs during the transition window.
<=
/p>
In regards to the usefuln=
ess of the extension in LSPs I think your presentation is less than candid.=
You say in Section 2 that LSPs are vulnerable to inter-session
replay attack – but, as we have previously discussed at length,
the inter-session LSP replay attack scenarios are highly unlikely and the s=
ame base protocol mechanisms which protect LSPs against intra-session repla=
ys also allow the protocol to quickly recover from inter-session attacks. T=
his differs markedly from the case
for IIHs and SNPs where no replay protection is available at present.=
<=
/p>
The value add of Extended=
Sequence # in LSPs is about as close to nil as one can get. I would much p=
refer if the use of Extended Sequence #s in LSPs was removed
from the draft (with explanation as to why). If you are unwilling to do th=
at at least be fair in your presentation. You have a good use case argument=
for IIHs and SNPs – but the case for LSPs is quite weak and it would=
be good to be candid about that so vendors/customers
can understand the value proposition .
<=
/p>
Les
<=
/p>
<=
/p>
From: Uma Chun=
duri [mailto:uma.chunduri@ericsson.com]
Sent: Tuesday, October 09, 2012 4:36 PM
To: Les Ginsberg (ginsberg); Bhatia, Manav (Manav); Naiming Shen (na=
iming)
Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org
Subject: RE: draft-chunduri-isis-extended-sequence-no-tlv - other co=
mments
Replies in-line [Uma]:<=
o:p>
Here are the remain=
der of my comments on the draft:
In regards to SNPs, the presence of replayed SNPs will cause unnecessary re=
flooding of LSPs but will not actually cause any change in the LSPDB of any=
router. The unnecessary flooding would be limited to the link on which the=
replayed SNPs appear. Because no
actual LSPDB changes would occur as a result of replayed SNPs, this is the=
one usage which could be enabled in the presence of partial deployment.
In regards to IIHs, replayed IIHs could cause adjacency flapping which coul=
d be very disruptive. The danger lies when not all systems on a link suppor=
t the extension - which on multi-access links can lead to multiple DISs bei=
ng elected and violations of the
assumption of transitivity. For this reason, enablement cannot be safely d=
one in the presence of legacy systems.
[Uma]: draft-chunduri-isis-extended-sequen=
ce-no-tlv-02.txt has been updated (section 5) to cover the partial deployme=
nt cases. This addressees not only IIH but all PDUs. There is no flag day r=
equirement here.
Given the discussion in the draft about enhancements to provide routing pro=
tocols with a group key management protocol in the future, it is prudent to=
look at the value add of extended sequence #s in the presence of a group k=
ey management protocol. The cost
of having router vendors and their customers implement, deploy, and suppor=
t extended sequence #s must be weighed against the benefits.
[Uma]: You talked about the =
cost above. When an operator deploys any key management protocol in g=
eneral, the advantages it brings in are far more bigger than the mitigation=
of replay attacks. But, the cost could
be prohibitive if any key management protocol including group key manageme=
nt is deployed only for the purpose of replay p=
rotection. Just for this reason a manual key mechanism to effectively elimi=
nate the issue with replay attack is always
useful. This is clearly discussed in Section 1 of the document. It's =
also worth mentioning here, neither such a group keying RFC whic=
h can derive keys for a group IGPs look for exist yet nor a smooth me=
chanism for integration yet defined.
As discussed in an earlier thread, IS-I=
S already has a reliable mechanism to recover from replayed LSPs.
[Uma]: We discussed in lengt=
h on this and reliable recovery comes only after the replay is successful a=
nd the certain damage it brings in all over.
We take this opportunity acknowledge for providi=
ng early feedback on the solution for partial deployment issue.=
--
Uma C.
--_000_F3ADE4747C9E124B89F0ED2180CC814F11840654xmbalnx02ciscoc_--
From uma.chunduri@ericsson.com Fri Oct 12 17:53:02 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E0121F867A for ; Fri, 12 Oct 2012 17:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2QZUqZl2+bQ for ; Fri, 12 Oct 2012 17:53:01 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 83B2F21F8682 for ; Fri, 12 Oct 2012 17:53:01 -0700 (PDT)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q9D0sF62028138 for ; Fri, 12 Oct 2012 19:54:16 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.44]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 12 Oct 2012 20:52:56 -0400
From: Uma Chunduri
To: "isis-wg@ietf.org"
Date: Fri, 12 Oct 2012 20:52:55 -0400
Thread-Topic: draft-ietf-isis-mi-07 draft
Thread-Index: Ac2o3RTV6hPrVcf2T1OAoJqgYSBFMQ==
Message-ID:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D1D8138DDF34B34B8BC68A11262D10792B615E1C15EUSAACMS0701e_"
MIME-Version: 1.0
Subject: [Isis-wg] draft-ietf-isis-mi-07 draft
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 13 Oct 2012 00:53:02 -0000
--_000_D1D8138DDF34B34B8BC68A11262D10792B615E1C15EUSAACMS0701e_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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 w=
ith 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=3D0 can be used in ITID=3D1 but purely for transporti=
ng 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 eve=
n this is possible (as you are already saying legacy system/instance).
"When the IID =3D 0, the list of supported ITIDs MUST NOT be presen=
t"
This suggests IID=3D0 can only be used by routers if and only if all th=
e 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 pre=
sent 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 a=
re 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 S=
N
dependent if provisioned or it takes instance AUTH parameters which are no=
t topology (from instance) specific today. Now imagine, with multiple topol=
ogies,
topology specific AUTH keys are configured and no SN specific keys are prov=
isioned (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 compl=
etely new (and need more discussion) and I find it hard to visualize the us=
e 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 fr=
om GENINFO point of view).
If this is not understood clearly, it can lead to potential mis-configurati=
ons and confusions for folks who is deploying this technology.
5. Section 4
"There is no relationship between the Multi-topology IDs defined in [R=
FC5120] 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 I=
TID. 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 comput=
ation 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 to=
pologies are encoded and only relevant TLVs are used for computing the rou=
tes. As only
one IID/ITID combination is allowed in LSP, and as it is not mandated any t=
hing like witch TLVs should go in with particular ITID, it's possible one c=
an 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 alter=
native to MT too, and any ways
multiple updates have to be sent with different ITIDs I feel restricting TL=
Vs corresponding to the ITID will be more efficient.
6. Section 7
It's already agreed, some stale sentences need to be cleaned-up there b=
ut if this draft is introducing topology specific AUTH keys it needs more d=
escription here on why and where this should be considered.
--
Uma C.
--_000_D1D8138DDF34B34B8BC68A11262D10792B615E1C15EUSAACMS0701e_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
=
I have=20
few questions/clarification on this draft (I discussed few with Les already=
and=20
got the context of this technology, thanks).
1. Section 1
&nb=
sp; " The specification of uses of MI-IS-IS is outside the =
scope=20
of this document."
Still 1 or 2&n=
bsp;use=20
cases of how this can be used as alternative to MT and with GENINFO wi=
ll=20
greatly improve the readability of the draft (in appendix) else it's=20
definitely bit elusive.
For E.g. as there is=
no=20
significance of ITID value same V4 topology which is being used in ITID=3D0=
can be=20
used in ITID=3D1 but purely for transporting GENINFO TLV. Can this be a val=
id use=20
case?
2. Section=20
2.1
"IS-IS PDUs associated wi=
th=20
the legacy instance MUST NOT include an IID-TLV except where noted in this=
=20
document."
It's not clear when IID-TLV is expec=
ted=20
from legacy system and how even this is possible (as you are already=
=20
saying legacy=20
system/instance).
"When=
the=20
IID =3D 0, the list of supported ITIDs MUST NOT be present"
=
=20
This suggests IID=3D0 can only be used by routers if and only if all the no=
des in=20
the network have this feature on. Can you confirm on this.
=
3. Section=20
2.1
"Multiple IID-TLVs MAY ap=
pear=20
in IIHs. If multiple IID-TLVs are present and the IID value in all IID-TLVs=
is=20
not the same then the PDU MUST BE ignored. "
Why woul=
d one=20
use multiple IIDs with same IID value? If multiple ITID are supported any w=
ays=20
in one IID - not clear what authors are seeing here.
4. Section=20
2.3
"When multiple ITIDs are supported, ITID specific=
=20
authentication MAY be used in SNPs and LSPs."
This is is not possible for IIH as multipl=
e ITID=20
can be encoded in the same PDU. So, essentially all topologies will s=
hare=20
the same AUTH config for SN
dependent if provisioned or it takes=
instance=20
AUTH parameters which are not topology (from instance) specific today. Now=
=20
imagine, with multiple topologies,
topology specific AUTH keys are configured=
and no=20
SN specific keys are provisioned (which is legit today ), then which topo=20
specific AUTH key will be used by IIH messages?
I see allowing topology specific AUTH keys=
=20
for SNP and LSPs would be completely new (and need more discussion) and I f=
ind=20
it hard to visualize the use case
why one would do this (I can think only fr=
om MT=20
point of view now - say if MI is used instead of MT and this may not b=
e=20
needed but what authors see from GENINFO point of view).
If this is not understood clearly, it can =
lead to=20
potential mis-configurations and confusions for folks who is deploying this=
=20
technology.
5. Section=20
4
"There is no relationship between the=20
Multi-topology IDs defined in [RFC5120] and the ITIDs defined in this=20
document."
"An MI-RTR MAY use the extensi=
ons=20
defined in this document to support multiple topologies in the context of a=
n=20
instance with a non-zero IID.
Each =
MI=20
topology is associated with a unique LSDB identified by an ITID. An ITID=20
specific IS-IS Update Process operates on each=20
topology.
This differs from [RFC512=
0]=20
where a single LSDB/single IS-IS Update Process is used in support of all=20
topologies."
a)If there is no relationship b=
etween MTID=20
in 5120 and ITID here how computation actually happens say an instance=
=20
supporting V4 and V6 topologies as some=20
TLVs are significant to particular topology as defined in 5120 today?
b) In MT, with multiple t=
opologies=20
all the TLVs corresponding to all the topologies are encoded and only =
=20
relevant TLVs are used for computing the routes. As only
one IID/ITID=20
combination is allowed in LSP, and as it is not mandated any thing like wit=
ch=20
TLVs should go in with particular ITID, it's possible one can still encode =
all=20
TLVs of all topologies but changing the IID/ITID field. I think this se=
emed=20
to be left to implementations but as this is positioned as potential altern=
ative=20
to MT too, and any ways
multiple updates have to be sent with different=
=20
ITIDs I feel restricting TLVs corresponding to the ITID will be more effici=
ent.=20
6. Section 7
It's already agreed, so=
me stale=20
sentences need to be cleaned-up there but if this draft is introducing topo=
logy=20
specific AUTH keys it needs more description here on why and where this sho=
uld=20
be considered.
--<=
BR>Uma=20
C.
--_000_D1D8138DDF34B34B8BC68A11262D10792B615E1C15EUSAACMS0701e_--
From ginsberg@cisco.com Sat Oct 13 11:59:37 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8000B21F8493 for ; Sat, 13 Oct 2012 11:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.498
X-Spam-Level:
X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYt28YzmHNQK for ; Sat, 13 Oct 2012 11:59:33 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A7B8521F848B for ; Sat, 13 Oct 2012 11:59:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23900; q=dns/txt; s=iport; t=1350154772; x=1351364372; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=8t/5ge0hWKDKwat8XDsCjgZZ6iXSrrgXx67MjtLQnYI=; b=agucvIleXVi9E6fY/wRn9sfDOWUvsA/y7rwC2Y/yT4uY+FNyn9a0QCHZ i6rLFSpQxHfLmR488o7h30JtfpF8HUr1+ZuQX6N+gYki5pMCZu4jtARZ2 c7buHWVfGQy4ijweCGu+FCb+t0+trUMy/lhlbs9BAExQqFMBZhqIUOyoJ Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAEa5eVCtJXG+/2dsb2JhbABFgku9I4EIgiABAQEEEgEaRRcCAQgRBAEBCxYHBzIUCQgBAQQBEggahXiBapw/n0aLWYVdYAOkMYFrgm2BWj0
X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208,217";a="131285115"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 13 Oct 2012 18:59:31 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9DIxVep030347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Oct 2012 18:59:31 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Sat, 13 Oct 2012 13:59:31 -0500
From: "Les Ginsberg (ginsberg)"
To: Uma Chunduri , "isis-wg@ietf.org"
Thread-Topic: draft-ietf-isis-mi-07 draft
Thread-Index: Ac2o3RTV6hPrVcf2T1OAoJqgYSBFMQAksk0Q
Date: Sat, 13 Oct 2012 18:59:30 +0000
Message-ID:
References:
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.145.216]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19268.004
x-tm-as-result: No--40.740700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F11844314xmbalnx02ciscoc_"
MIME-Version: 1.0
Subject: Re: [Isis-wg] draft-ietf-isis-mi-07 draft
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 13 Oct 2012 18:59:37 -0000
--_000_F3ADE4747C9E124B89F0ED2180CC814F11844314xmbalnx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Uma -
From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf =
Of Uma Chunduri
Sent: Friday, October 12, 2012 5:53 PM
To: isis-wg@ietf.org
Subject: [Isis-wg] draft-ietf-isis-mi-07 draft
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 w=
ith GENINFO will greatly improve the readability of the draft (in appendix)=
else it's definitely bit elusive.
LES: The purpose of the draft is to provide a normative specification for t=
he MI extensions to the protocol. Historically IS-IS RFCs and base spec hav=
e confined themselves to normative statements and do not provide detailed u=
se case examples. We prefer to continue that approach in this document. Fur=
ther information on GENAPP can be found in the reference to that draft. Alt=
hough 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.
For E.g. as there is no significance of ITID value same V4 topology which =
is being used in ITID=3D0 can be used in ITID=3D1 but purely for transporti=
ng GENINFO TLV. Can this be a valid use case?
LES: It is valid to run a legacy instance and a non-zero instance over the =
same topology.
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 eve=
n this is possible (as you are already saying legacy system/instance).
"When the IID =3D 0, the list of supported ITIDs MUST NOT be presen=
t"
This suggests IID=3D0 can only be used by routers if and only if all th=
e nodes in the network have this feature on. Can you confirm on this.
LES: What is being discussed here is the correct behavior when an MI capabl=
e router supports the legacy instance. In that case all PDUs associated w t=
he legacy instance MUST NOT include an IID-TLV (with one exceptuion noted i=
n Section 2.6.2).
3. Section 2.1
"Multiple IID-TLVs MAY appear in IIHs. If multiple IID-TLVs are pre=
sent 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 a=
re supported any ways in one IID - not clear what authors are seeing here.
LES: It is possible to include up to 126 ITIDs in a single IID-TLV. If an i=
mplementation supported more that 126 ITIDs on a given circuit it would req=
uire 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 a=
nd the set of supported ITIDs is the union of all ITIDs in all IID-TLVs.
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 S=
N
dependent if provisioned or it takes instance AUTH parameters which are no=
t topology (from instance) specific today. Now imagine, with multiple topol=
ogies,
topology specific AUTH keys are configured and no SN specific keys are prov=
isioned (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 compl=
etely new (and need more discussion) and I find it hard to visualize the us=
e 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 fr=
om GENINFO point of view).
If this is not understood clearly, it can lead to potential mis-configurati=
ons and confusions for folks who is deploying this technology.
LES: The base specification (ISO 10589) and RFC 4304/5310 define three auth=
entication 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/I=
ID/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
"There is no relationship between the Multi-topology IDs defined in [R=
FC5120] 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 I=
TID. 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 comput=
ation actually happens say an instance supporting V4 and V6 topologies as =
some TLVs are significant to particular topology as defined in 5120 today?
LES: Different instances run as "ships in the night". A legacy instance sha=
res no adjacencies or PDUs with a non-zero instance. There is no relationsh=
ip between topology specific information advertised by a legacy instance us=
ing RFC 5120 extensions and a non-zero instance sending ITID specific infor=
mation. SPFs run by a legacy instance would be based solely on the informat=
ion advertised in PDUs associated w the legacy instance. Similarly, IID/ITI=
D specific SPFs (if executed) would be based solely on the PDUs associated =
with that non-zero IID/ITID.
b) In MT, with multiple topologies all the TLVs corresponding to all the to=
pologies are encoded and only relevant TLVs are used for computing the rou=
tes. As only
one IID/ITID combination is allowed in LSP, and as it is not mandated any t=
hing like witch TLVs should go in with particular ITID, it's possible one c=
an 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 alter=
native to MT too, and any ways
multiple updates have to be sent with different ITIDs I feel restricting TL=
Vs corresponding to the ITID will be more efficient.
LES: All TLVs in a given LSP are associated with the IID/ITID which is enco=
ded in that LSP.
6. Section 7
It's already agreed, some stale sentences need to be cleaned-up there b=
ut if this draft is introducing topology specific AUTH keys it needs more d=
escription here on why and where this should be considered.
LES: Yes - the second paragraph in Section 7 is left over from earlier vers=
ions of the draft where the inclusion of IID-TLV in legacy instance PDUs wa=
s allowed. However we now prohibit the inclusion of IID-TLV in legacy insta=
nce PDUs so this paragraph is no longer relevant and will be deleted from t=
he final text. Thanx for your help in identifying this oversight.
Les
--
Uma C.
--_000_F3ADE4747C9E124B89F0ED2180CC814F11844314xmbalnx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Uma -=
p>
<=
/p>
From: isis-wg-=
bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]
On Behalf Of Uma Chunduri
Sent: Friday, October 12, 2012 5:53 PM
To: isis-wg@ietf.org
Subject: [Isis-wg] draft-ietf-isis-mi-07 draft
I have few questions/clarification on thi=
s draft (I discussed few with Les already and got the context of this techn=
ology, thanks).
1. Section 1
" The specification of uses of MI-IS-I=
S 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 elusi=
ve.
LES: The purpose of the draft is to provide a=
normative specification for the MI extensions to the protocol. Historicall=
y IS-IS RFCs and base spec have confined themselves to
normative statements and do not provide detailed use case examples. We pre=
fer to continue that approach in this document. Further information on GENA=
PP can be found in the reference to that draft. Although using MI as an alt=
ernative to RFC 5120 is a possible
use case we are not promoting that idea – simply stating that MI can=
be used in that way.
For E.g. as there is no significance of ITID value=
same V4 topology which is being used in ITID=3D0 can be used in ITID=3D1 b=
ut purely for transporting GENINFO TLV. Can this be a valid use case?<=
/o:p>
LES: It is valid to run a legacy instance and=
a non-zero instance over the same topology.
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 legac=
y system and how even this is possible (as you are already saying leg=
acy system/instance).
"When the IID =3D 0, the li=
st of supported ITIDs MUST NOT be present"
This suggests IID=3D0 can only be used by routers if and=
only if all the nodes in the network have this feature on. Can you c=
onfirm on this.
LES: What is being discussed here is the correc=
t 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
"Multiple IID-TLVs MAY appe=
ar in IIHs. If multiple IID-TLVs are present and the IID value in all IID-T=
LVs 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 ar=
e seeing here.
LES: It is possible to include up to 126 ITID=
s in a single IID-TLV. If an implementation supported more that 126 ITIDs o=
n 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. t=
he IID value MUST be the same in all of the TLVs and the set of supported I=
TIDs is the union of all ITIDs in
all IID-TLVs.
4. Section 2.3
"When multiple ITIDs are supported, ITID specific a=
uthentication MAY be used in SNPs and LSPs."
This is is not possible for IIH as multip=
le ITID can be encoded in the same PDU. So, essentially all topologie=
s will share the same AUTH config for SN
dependent if provisioned or it take=
s instance AUTH parameters which are not topology (from instance) specific =
today. Now imagine, with multiple topologies,
topology specific AUTH keys are configure=
d and no SN specific keys are provisioned (which is legit today ), then whi=
ch topo specific AUTH key will be used by IIH messages?=
p>
I see allowing topology specific AUTH key=
s 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 f=
rom MT point of view now - say if MI is used instead of MT and this ma=
y 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 deplo=
ying this technology.
<=
/p>
LES: The base specificati=
on (ISO 10589) and RFC 4304/5310 define three authentication contexts:=
<=
/p>
Circuit scoped authentica=
tion – used in IIHs
Area scoped authenticatio=
n – Used in Level 1 SNPs and LSPs
Domain scoped authenticat=
ion – used in Level2 SNPs and LSPs
<=
/p>
In MI, the scope of SNPs/=
LSPs is further defined by an IID/ITID pair. It is then possible to have di=
fferent authentication types/keys for each Level/IID/ITID
scope. Whether an implementation would choose to support different authent=
ication type/key for each IID/ITID pair is up to the implementation to dete=
rmine.
5. Section 4
"There is no relationship between the Multi-t=
opology IDs defined in [RFC5120] and the ITIDs defined in this document.&qu=
ot;
"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 op=
erates on each topology.
This differs from [RFC5120] where a si=
ngle 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 h=
ere 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?
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 assoc=
iated w the legacy instance. Similarly,
IID/ITID specific SPFs (if executed) would be based solely on the PDUs ass=
ociated with that non-zero IID/ITID.
b) In MT, with multiple topologies all the TLVs corresponding=
to all the topologies are encoded and only relevant TLVs are used fo=
r computing the routes. As only
one IID/ITID combination is allowed in LSP, and as it is not mandated any t=
hing like witch TLVs should go in with particular ITID, it's possible one c=
an 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 alter=
native to MT too, and any ways
multiple updates have to be sent with different ITIDs I feel restricting TL=
Vs corresponding to the ITID will be more efficient.
LES: All TLVs in a given LSP are associated w=
ith the IID/ITID which is encoded in that LSP.
6. Section 7
&nbs=
p; It's already agreed, some stale sentences need to be cleaned-up th=
ere but if this draft is introducing topology specific AUTH keys it needs
more description here on why and where this should be considered.
LES: Yes – the second paragraph in =
Section 7 is left over from earlier versions of the draft where the inclusi=
on of IID-TLV in legacy instance PDUs was allowed. However we
now prohibit the inclusion of IID-TLV in legacy instance PDUs so this para=
graph is no longer relevant and will be deleted from the final text. Thanx =
for your help in identifying this oversight.
Les
--
Uma C.
--_000_F3ADE4747C9E124B89F0ED2180CC814F11844314xmbalnx02ciscoc_--
From uma.chunduri@ericsson.com Mon Oct 15 08:50:21 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141B321F858F for ; Mon, 15 Oct 2012 08:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level:
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51CqWvijoPpX for ; Mon, 15 Oct 2012 08:50:16 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 424BF21F8607 for ; Mon, 15 Oct 2012 08:50:16 -0700 (PDT)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q9FFpqeM023616; Mon, 15 Oct 2012 10:51:54 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.44]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 15 Oct 2012 11:50:14 -0400
From: Uma Chunduri
To: "Les Ginsberg (ginsberg)" , "isis-wg@ietf.org"
Date: Mon, 15 Oct 2012 11:50:13 -0400
Thread-Topic: draft-ietf-isis-mi-07 draft
Thread-Index: Ac2o3RTV6hPrVcf2T1OAoJqgYSBFMQAksk0QAEM6r5A=
Message-ID:
References:
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D1D8138DDF34B34B8BC68A11262D10792B615E1F4CEUSAACMS0701e_"
MIME-Version: 1.0
Subject: Re: [Isis-wg] draft-ietf-isis-mi-07 draft
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 15 Oct 2012 15:50:21 -0000
--_000_D1D8138DDF34B34B8BC68A11262D10792B615E1F4CEUSAACMS0701e_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Les,
Please see in-line [Uma]:
1. Section 1
" The specification of uses of MI-IS-IS is outside the scope of this docume=
nt."
--
LES: "Although using MI as an alternative to RFC 5120 is a possible use cas=
e we are not promoting that idea - simply stating that MI can be used in th=
at 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 [RFC=
5120]."
"An MI-RTR MAY use the extensions defined in this doc=
ument 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 [RFC51=
20] 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 alt=
ernative to 5120 is not at all being promoted.
First of all the question is - can MI be used as alternative to 5120? If ye=
s, 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
"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 eve=
n this is possible (as you are already saying legacy system/instance).
"When the IID =3D 0, the list of supported ITIDs MUST NOT be presen=
t"
This suggests IID=3D0 can only be used by routers if and only if all th=
e nodes in the network have this feature on. Can you confirm on this.
LES: What is being discussed here is the correct behavior when an MI capabl=
e router supports the legacy instance. In that case all PDUs associated w t=
he legacy instance MUST NOT include an IID-TLV (with one exceptuion noted i=
n Section 2.6.2).
[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 th=
erefore no disruption is caused.."..
"legacy systems will interpret these PDUs as being as=
sociated with IID #0
IID=3D0 is being represented as standard instance and the word legacy is us=
ed in different context in rest of the document and here legacy word is bei=
ng used differently and doesn't resonate well (MI capable router in IID=3D=
0). Though it's not a big deal it confuses the reader. Probably you need to=
clear the intent better there.
--
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 S=
N
dependent if provisioned or it takes instance AUTH parameters which are no=
t topology (from instance) specific today. Now imagine, with multiple topol=
ogies,
topology specific AUTH keys are configured and no SN specific keys are prov=
isioned (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 compl=
etely new (and need more discussion) and I find it hard to visualize the us=
e 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 fr=
om GENINFO point of view).
If this is not understood clearly, it can lead to potential mis-configurati=
ons and confusions for folks who is deploying this technology.
LES: The base specification (ISO 10589) and RFC 4304/5310 define three auth=
entication 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/I=
ID/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.
[Uma]: Yes, as per base standard only area or domain level AUTH scope is de=
fined. 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 rath=
er this is a deployment question. When you are providing this level of gran=
ularity (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 co=
nsequences of not using if it is indeed needed in Section 7.
5. Section 4
"There is no relationship between the Multi-topology IDs defined in [R=
FC5120] 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 I=
TID. 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 comput=
ation actually happens say an instance supporting V4 and V6 topologies as =
some TLVs are significant to particular topology as defined in 5120 today?
LES: Different instances run as "ships in the night". A legacy instance sha=
res no adjacencies or PDUs with a non-zero instance. There is no relationsh=
ip between topology specific information advertised by a legacy instance us=
ing RFC 5120 extensions and a non-zero instance sending ITID specific infor=
mation. SPFs run by a legacy instance would be based solely on the informat=
ion advertised in PDUs associated w the legacy instance. Similarly, IID/ITI=
D specific SPFs (if executed) would be based solely on the PDUs associated =
with that non-zero IID/ITID.
[Uma]: Ok, here is a simple example . Say, to get all the advantages of Pa=
ragraph 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 f=
or this purpose it is an alternative to [RFC5120]."
say one chooses to deploy MI instead of MT and standard instance (IID=3D0) =
is used for IPV4 and IID=3Dx and ITID=3Dy is used for IPv6 topology . Let's=
make it simple and further assume all
links are shared across standard IID and IID=3Dx. Now:
a. as there is no significance of ITID how other vendor nodes in the networ=
k know this is V6 topology and you are supposed to expand TLVs correspondin=
g to V6 in SPF? (no MT here)
b. even the node which is doing packing know how ITID=3Dy corresponds to IP=
v6 and tend to put only V6 related TLVs (now http://tools.ietf.org/html/rfc=
5308 is the only choice here).
or
you see - keeping all topology information in both standard IID and IID=
=3Dx and ITID=3Dy (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 t=
he advantage?
The more I see... ok, will wait for your response first.
--
Uma C.
--_000_D1D8138DDF34B34B8BC68A11262D10792B615E1F4CEUSAACMS0701e_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Les,<=
/DIV>
 =
;
Please see in-line=20
[Uma]:
1. Section=20
1
" The specifi=
cation=20
of uses of MI-IS-IS is outside the scope of this=20
document."
--
LES: "Although using MI as an altern=
ative=20
to RFC 5120 is a possible use case we are not promoting that idea – s=
imply=20
stating that MI can be used in that way.
[Uma=
]: This=20
statement directly contradicts one of the potential uses o=
f of=20
the document as mentioned in Introduction and all=20
along.
&n=
bsp; =20
<=
FONT=20
size=3D2>Section-1 Says: "MI-IS-IS might be used to support top=
ology=20
specific routing. When used for this purpose it is an alternati=
ve to=20
[RFC5120]."
=
&nb=
sp;"An=20
MI-RTR MAY use the extensions defined in this document to support mul=
tiple=20
topologies in the context of an instance with a non-zero =20
IID. "
Section-4 Says: =20
"Although it is possible for an MI-RTR to use [RFC5120] multi-topolog=
y=20
support within a non-zero instance such usage is seen as unnece=
ssary=20
and is discouraged"
Per Section-4 above, usage of MT in non-zero MI instance is=20
discouraged and now you are saying completely different thing i.e., u=
sage=20
of MI as an alternative to 5120 is not at all being promoted.=20
Firs=
t of all the=20
question is - can MI be used as alternative to 5120? If yes, this document=
=20
should be more clear how ?
If i=
ndeed MI is=20
an alternative to MT as per 07 version, then I saw multiple problems a=
s=20
discussed in item 5 below.
2. Section=20
2.1
"IS-IS PDUs associated wi=
th=20
the legacy instance MUST NOT include an IID-TLV except where noted in this=
=20
document."
It's not clear when IID-TLV is expec=
ted=20
from legacy system and how even this is possible (as you are already=
=20
saying legacy=20
system/instance).
"When=
the=20
IID =3D 0, the list of supported ITIDs MUST NOT be present"
=
=20
This suggests IID=3D0 can only be used by routers if and only if all the no=
des in=20
the network have this feature on. Can you confirm on=20
this.
LES:=20
What is being discussed here is the correct behavior when an MI capable rou=
ter=20
supports the legacy instance. In that case all PDUs associated w the legacy=
=20
instance MUST NOT include an IID-TLV (with one exceptuion noted in Section=
=20
2.6.2).
[Uma]: =20
Section=20
2: "Instance identifier #0 is reserved for the=
=20
standard instance supported by legacy systems."=20
Section 2.6.1- "these PDUs being &n=
bsp;=20
processed by legacy routers and therefore no disruption is=20
caused.."..
=
=20
"legacy systems will interpret these PDUs as being associated with II=
D=20
#0
IID=3D0 is being represent=
ed as=20
standard instance and the word legacy is used in different context in =
rest=20
of the document and here legacy word is being used differently and doesn't=
=20
resonate well (MI capable router in IID=3D0). Though it's n=
ot a=20
big deal it confuses the reader. Probably you need to clear the intent b=
etter=20
there.
--
4. Section 2.3
&=
nbsp;=20
"When multiple ITIDs are supported, ITID specific authentication MAY be use=
d in=20
SNPs and LSPs."
This is is not=
=20
possible for IIH as multiple ITID can be encoded in the same PDU. So,=
=20
essentially all topologies will share the same AUTH config for=20
SN
dependent if=20
provisioned or it takes instance AUTH parameters which are not topolo=
gy=20
(from instance) specific today. Now imagine, with multiple=20
topologies,
topology speci=
fic=20
AUTH keys are configured and no SN specific keys are provisioned (which is =
legit=20
today ), then which topo specific AUTH key will be used by IIH=20
messages?
I see allowing=
=20
topology specific AUTH keys for SNP and LSPs would be completely new =
(and=20
need more discussion) and I find it hard to visualize the use case=20
why one would =
do this=20
(I can think only from MT point of view now - say if MI is used instea=
d of=20
MT and this may not be needed but what authors see from GENINFO point of=20
view).
If this is not=
=20
understood clearly, it can lead to potential mis-configurations and confusi=
ons=20
for folks who is deploying this technology.
LES:=20
The base specification (ISO 10589) and RFC 4304/5310 define three authentic=
ation=20
contexts:
Circuit=20
scoped authentication – used in IIHs
Area=20
scoped authentication – Used in Level 1 SNPs and LSPs
Domain=20
scoped authentication – used in Level2 SNPs and LSPs
In=20
MI, the scope of SNPs/LSPs is further defined by an IID/ITID pair. It is th=
en=20
possible to have different authentication types/keys for each Level/IID/ITI=
D=20
scope. Whether an implementation would choose to support different=20
authentication type/key for each IID/ITID pair is up to the implementation =
to=20
determine.
[Uma]: Yes, as per base st=
andard=20
only area or domain level AUTH scope is defined. Now this is further fragme=
nted=20
with topology granularity with in the L1 area or L2=20
domain.
 =
; =20
Les, I don't think this is about implementation choice rather this is=
a=20
deployment question. When you are providing this level of granularity (furt=
her=20
to base spec), I presume
 =
; =20
authors foresee some issue with same key with much=20
bigger (?) scope especially when MI is used in conjunction with APP info transport?=20
 =
; =20
It's ok to have IID/ITID specific AUTH but one should know consequences of =
not=20
using if it is indeed needed in Section 7.
5.&nb=
sp;=20
Section 4
"There is no relationship between the=
=20
Multi-topology IDs defined in [RFC5120] and the ITIDs defined in this=20
document."
"An MI-RTR MAY use the extensi=
ons=20
defined in this document to support multiple topologies in the context of a=
n=20
instance with a non-zero IID.
Each =
MI=20
topology is associated with a unique LSDB identified by an ITID. An ITID=20
specific IS-IS Update Process operates on each=20
topology.
This differs from [RFC512=
0]=20
where a single LSDB/single IS-IS Update Process is used in support of all=20
topologies."
a)If =
there=20
is no relationship between MTID in 5120 and ITID here how computation actua=
lly=20
happens say an instance supporting V4 and V6 topologies as some =
TLVs=20
are significant to particular topology as defined in 5120=20
today?
LES:=20
Different instances run as “ships in the night”. A legacy insta=
nce shares no=20
adjacencies or PDUs with a non-zero instance. There is no relationship betw=
een=20
topology specific information advertised by a legacy instance using RFC 512=
0=20
extensions and a non-zero instance sending ITID specific information. SPFs =
run=20
by a legacy instance would be based solely on the information advertised in=
PDUs=20
associated w the legacy instance. Similarly, IID/ITID specific SPFs (if=20
executed) would be based solely on the PDUs associated with that non-zero=20
IID/ITID.
[Uma]: Ok, here is a simpl=
e example=20
. Say, to get all the advantages of Paragraph 3 and 4 in Section 1 - =
and I=20
am still with the statement below:
"MI-IS-IS might be used to support topology specific=20
routing. When used for this purpose it is an alternative to=20
[RFC5120]."
say one=20
chooses to deploy MI instead of MT and standard instance (IID=3D0) is used =
for=20
IPV4 and IID=3Dx and ITID=3Dy is used for IPv6 topology . Let's make it sim=
ple and=20
further assume all
links are shared across standard IID and IID=3Dx.=20
Now:
a. as there is no significance of ITID how other vendor nodes in th=
e=20
network know this is V6 topology and you are supposed to expand TLVs=20
corresponding to V6 in SPF? (no MT here)
b. even the node which is doing=
=20
packing know how ITID=3Dy corresponds to IPv6 and tend to put only V6 relat=
ed TLVs=20
(now http://tools.ietf.org/html/rfc5=
308=20
is the only choice here).
or
you see - keeping all topo=
logy=20
information in both standard IID and IID=3Dx and ITID=3Dy (no MT) and adver=
tise is=20
an option (use 5308 and only one SPF yields all)? Then why one would bother=
to=20
put IID/ITID? Do you still the advantage?
The more I see... ok, will wai=
t for=20
your response first.
--
Uma=20
C.
--_000_D1D8138DDF34B34B8BC68A11262D10792B615E1F4CEUSAACMS0701e_--
From internet-drafts@ietf.org Mon Oct 15 10:38:35 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E89021F8793; Mon, 15 Oct 2012 10:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.553
X-Spam-Level:
X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEKe12uChVaR; Mon, 15 Oct 2012 10:38:34 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E2521F86DB; Mon, 15 Oct 2012 10:38:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121015173834.29498.68586.idtracker@ietfa.amsl.com>
Date: Mon, 15 Oct 2012 10:38:34 -0700
Cc: isis-wg@ietf.org
Subject: [Isis-wg] I-D Action: draft-ietf-isis-rfc6326bis-00.txt
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 15 Oct 2012 17:38:35 -0000
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the IS-IS for IP Internets Working Group of t=
he IETF.
Title : Transparent Interconnection of Lots of Links (TRILL) Use=
of IS-IS
Author(s) : Donald Eastlake
Tissa Senevirathne
Anoop Ghanwani
Dinesh Dutt
Ayan Banerjee
Filename : draft-ietf-isis-rfc6326bis-00.txt
Pages : 49
Date : 2012-10-12
Abstract:
The IETF TRILL (Transparent Interconnection of Lots of Links)
protocol provides optimal pair-wise data frame forwarding without
configuration in multi-hop networks with arbitrary topology and link
technology, and support for multipathing of both unicast and
multicast traffic. This document specifies the data formats and code
points for the IS-IS extensions to support TRILL. These data formats
and code points may also be used by technologies other than TRILL.
This document obsoletes RFC 6326.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-isis-rfc6326bis
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-isis-rfc6326bis-00
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
From ginsberg@cisco.com Mon Oct 15 20:14:31 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C4B1F0C9F for ; Mon, 15 Oct 2012 20:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.913
X-Spam-Level:
X-Spam-Status: No, score=-9.913 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQO2APCwmN1h for ; Mon, 15 Oct 2012 20:14:25 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9B81F0C9A for ; Mon, 15 Oct 2012 20:14:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40900; q=dns/txt; s=iport; t=1350357264; x=1351566864; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=vDsyFdaVODaq33wk9AxS0tq1qD9XSXJOTTT+zsi4z9g=; b=Sy1POgsambF6y4pWJLgwVjj8KQjBda+zLYTF1heBo6cvCrdND1IQtWCU Osfhc6SiRhIrAnNxf6HQ5dfj3meWqh5CXSR4jb7BUOY+psjG1b8gDesA3 i22uwk88D3XddiKbM31VK0ISg6lsKNusm8SnF+dYxH9JEV399LyaAaCxg I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAEPQfFCtJXHB/2dsb2JhbABFgku0XQGIaIEIgiABAQEEEgEHE0UXAgEIEQQBAQsWAQYHMhQJCAEBBAESCBqHYgubTY9akF6LR4VdYAOXAI0wgWuCYA2CFw
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208,217";a="131928089"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 16 Oct 2012 03:14:22 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9G3EM81009908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Oct 2012 03:14:22 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 22:14:22 -0500
From: "Les Ginsberg (ginsberg)"
To: Uma Chunduri , "isis-wg@ietf.org"
Thread-Topic: draft-ietf-isis-mi-07 draft
Thread-Index: Ac2o3RTV6hPrVcf2T1OAoJqgYSBFMQAksk0QAEM6r5AAMnmBkA==
Date: Tue, 16 Oct 2012 03:14:21 +0000
Message-ID:
References:
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.64.14]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004
x-tm-as-result: No--51.092800-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F1184644Dxmbalnx02ciscoc_"
MIME-Version: 1.0
Subject: Re: [Isis-wg] draft-ietf-isis-mi-07 draft
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 16 Oct 2012 03:14:31 -0000
--_000_F3ADE4747C9E124B89F0ED2180CC814F1184644Dxmbalnx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Uma -
From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]
Sent: Monday, October 15, 2012 8:50 AM
To: Les Ginsberg (ginsberg); isis-wg@ietf.org
Subject: RE: draft-ietf-isis-mi-07 draft
Les,
Please see in-line [Uma]:
1. Section 1
" The specification of uses of MI-IS-IS is outside the scope of this docume=
nt."
--
LES: "Although using MI as an alternative to RFC 5120 is a possible use cas=
e we are not promoting that idea - simply stating that MI can be used in th=
at 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 [RFC=
5120]."
"An MI-RTR MAY use the extensions defined in this doc=
ument 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 [RFC51=
20] 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 alt=
ernative to 5120 is not at all being promoted.
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 R=
FC 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 - suppo=
rt multiple MTIDs as defined in RFC 5120. In this case the MTIDs would defi=
ne 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 whic=
h 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 draf=
t is agnostic on this issue. We define the protocol extensions - what the m=
ost common use cases turn out to be is for the marketplace to determine.
First of all the question is - can MI be used as alternative to 5120? If ye=
s, 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
"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 eve=
n this is possible (as you are already saying legacy system/instance).
"When the IID =3D 0, the list of supported ITIDs MUST NOT be presen=
t"
This suggests IID=3D0 can only be used by routers if and only if all th=
e nodes in the network have this feature on. Can you confirm on this.
LES: What is being discussed here is the correct behavior when an MI capabl=
e router supports the legacy instance. In that case all PDUs associated w t=
he legacy instance MUST NOT include an IID-TLV (with one exceptuion noted i=
n Section 2.6.2).
[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 th=
erefore no disruption is caused.."..
"legacy systems will interpret these PDUs as being as=
sociated with IID #0
IID=3D0 is being represented as standard instance and the word legacy is us=
ed in different context in rest of the document and here legacy word is bei=
ng used differently and doesn't resonate well (MI capable router in IID=3D=
0). Though it's not a big deal it confuses the reader. Probably you need to=
clear the intent better there.
LES2: It is common practice to refer to routers which do not support the pr=
otocol extensions being defined in a new standard as "legacy routers". We a=
re very careful to state (Section 1):
" Legacy routers support the standard or zero instance of the protocol. T=
he behavior of the standard instance is not changed in any way by the exte=
nsions defined in this document."
I do not see how the text in the document contributes to your confusion.
--
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 S=
N
dependent if provisioned or it takes instance AUTH parameters which are no=
t topology (from instance) specific today. Now imagine, with multiple topol=
ogies,
topology specific AUTH keys are configured and no SN specific keys are prov=
isioned (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 compl=
etely new (and need more discussion) and I find it hard to visualize the us=
e 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 fr=
om GENINFO point of view).
If this is not understood clearly, it can lead to potential mis-configurati=
ons and confusions for folks who is deploying this technology.
LES: The base specification (ISO 10589) and RFC 4304/5310 define three auth=
entication 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/I=
ID/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.
[Uma]: Yes, as per base standard only area or domain level AUTH scope is de=
fined. 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 rath=
er this is a deployment question. When you are providing this level of gran=
ularity (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 co=
nsequences of not using if it is indeed needed in Section 7.
LES2: There are three (not two) defined authentication scopes (as I specif=
ied above). Try searching ISO 10589 for the strings:
circuitTransmitPassword
areaTransmitPassword
domainTransmitPassword
There is no requirement that each of these passwords be unique. It is possi=
ble to successfully deploy authentication using the same key for all scopes=
. The restriction that the base spec (and RFC 5304/5310) define is that the=
re 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 pos=
sible to do so.
Please do not abuse my very clear statements on this point by saying "autho=
rs 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
"There is no relationship between the Multi-topology IDs defined in [R=
FC5120] 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 I=
TID. 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 comput=
ation actually happens say an instance supporting V4 and V6 topologies as =
some TLVs are significant to particular topology as defined in 5120 today?
LES: Different instances run as "ships in the night". A legacy instance sha=
res no adjacencies or PDUs with a non-zero instance. There is no relationsh=
ip between topology specific information advertised by a legacy instance us=
ing RFC 5120 extensions and a non-zero instance sending ITID specific infor=
mation. SPFs run by a legacy instance would be based solely on the informat=
ion advertised in PDUs associated w the legacy instance. Similarly, IID/ITI=
D specific SPFs (if executed) would be based solely on the PDUs associated =
with that non-zero IID/ITID.
[Uma]: Ok, here is a simple example . Say, to get all the advantages of Pa=
ragraph 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 f=
or this purpose it is an alternative to [RFC5120]."
say one chooses to deploy MI instead of MT and standard instance (IID=3D0) =
is used for IPV4 and IID=3Dx and ITID=3Dy is used for IPv6 topology . Let's=
make it simple and further assume all
links are shared across standard IID and IID=3Dx. Now:
a. as there is no significance of ITID how other vendor nodes in the networ=
k know this is V6 topology and you are supposed to expand TLVs correspondin=
g to V6 in SPF? (no MT here)
b. even the node which is doing packing know how ITID=3Dy corresponds to IP=
v6 and tend to put only V6 related TLVs (now http://tools.ietf.org/html/rfc=
5308 is the only choice here).
or
you see - keeping all topology information in both standard IID and IID=
=3Dx and ITID=3Dy (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 t=
he advantage?
The more I see... ok, will wait for your response first.
LES2: What a given topology is used for is not enforced by the protocol. Th=
is 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 t=
here clearly must be agreement on what purpose that topology serves - wheth=
er 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. I=
t 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 ad=
dressed by the standards - either 5120 or MI.
Les
--
Uma C.
--_000_F3ADE4747C9E124B89F0ED2180CC814F1184644Dxmbalnx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Uma -=
p>
<=
/p>
From: Uma Chun=
duri [mailto:uma.chunduri@ericsson.com]
Sent: Monday, October 15, 2012 8:50 AM
To: Les Ginsberg (ginsberg); isis-wg@ietf.org
Subject: RE: draft-ietf-isis-mi-07 draft
Les,
Please see in-line [Uma]:
=
1. Section 1
" The specification of uses of MI-IS-I=
S is outside the scope of this document."
--
LES: "Although =
using MI as an alternative to RFC 5120 is a possible use case we are not pr=
omoting that idea – simply stating that MI can be used in that way.=
span>
[Uma]: This statement
directly contradicts one of the potential uses of of the =
document as mentioned in Introduction and all along.
=
&=
nbsp; &=
nbsp;Section-1
Says: "MI-IS-IS might be used to support topology specifi=
c routing. When used for this purpose it is an alternative to [=
RFC5120]."
&nbs=
p; &=
nbsp; "An MI-RTR MAY use the extensions defined in this document =
to support multiple topologies in the context of an instance with a n=
on-zero IID. "
Section-4 Says: "Although it is p=
ossible for an MI-RTR to use [RFC5120] multi-topology support w=
ithin a non-zero instance such usage is seen as unnecessary and is discoura=
ged"
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.
LES2: You are confusing tw=
o different use cases.
=
b>
Use Case 1: Use MI a=
s an alternative to RFC 5120. In this case a non-zero instance supports mul=
tiple ITIDs. The differences between this and use of RFC 5120
in Instance #0 (the standard instance) are discussed in Section 4.
=
b>
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 c=
an be done by advertising MT TLVs (222, 235, 237) in LSPs which are themsel=
ves scoped by a given IID/ITID.
=
b>
It is use case #2 which we=
are discouraging.
=
b>
When I say “we are n=
ot promoting [use case 1]” I simply mean that the draft is agno=
stic on this issue. We define the protocol extensions – what the most=
common
use cases turn out to be is for the marketplace to determine.=
span>
=
b>
=
b>
First of all the question is -=
can MI be used as alternative to 5120? If yes, this document should be mor=
e 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
"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 legac=
y system and how even this is possible (as you are already saying leg=
acy system/instance).
"When the IID =3D 0, the li=
st of supported ITIDs MUST NOT be present"
This suggests IID=3D0 can only be used by routers if and=
only if all the nodes in the network have this feature on. Can you c=
onfirm on this.
LES: What is being discussed here is the correc=
t 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).
[Uma]:
Section 2: "Instance identifier #0 is re=
served for the standard instance supported by legacy systems.&q=
uot;
Section 2.6.1- "these PDUs being &=
nbsp; processed by legacy routers and therefore no disruption is caused..&q=
uot;..
&nb=
sp; "legacy systems wi=
ll interpret these PDUs as being associated with IID #0=
p>
IID=3D0 is being represented as standard instance =
and the word legacy is used in different context in rest of the docume=
nt and here legacy word is being used differently and doesn't
resonate well (MI capable router in IID=3D0). Though it's =
not a big deal it confuses the reader. Probably you need to clear the inten=
t better there.
LES2: It is common practice to refer to router=
s which do not support the protocol extensions being defined in a new stand=
ard as “legacy routers”. We are very careful to state
(Section 1):
“ Legacy routers support the standard&nb=
sp; or zero instance of the protocol. The behavior of the standard&nb=
sp; instance is not changed in any way by the extensions defined in this&nb=
sp; document.”
I do not see how the text in the document cont=
ributes to your confusion.
--
4. Section 2.3
"When multiple ITIDs are supported, ITID specific a=
uthentication MAY be used in SNPs and LSPs."
This is is not possible for IIH as multip=
le ITID can be encoded in the same PDU. So, essentially all topologie=
s will share the same AUTH config for SN
dependent if provisioned or it take=
s instance AUTH parameters which are not topology (from instance) specific =
today. Now imagine, with multiple topologies,
topology specific AUTH keys are configure=
d and no SN specific keys are provisioned (which is legit today ), then whi=
ch topo specific AUTH key will be used by IIH messages?=
p>
I see allowing topology specific AUTH key=
s 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 f=
rom MT point of view now - say if MI is used instead of MT and this ma=
y 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 deplo=
ying this technology.
<=
/p>
LES: The base specificati=
on (ISO 10589) and RFC 4304/5310 define three authentication contexts:=
<=
/p>
Circuit scoped authentica=
tion – used in IIHs
Area scoped authenticatio=
n – Used in Level 1 SNPs and LSPs
Domain scoped authenticat=
ion – used in Level2 SNPs and LSPs
<=
/p>
In MI, the scope of SNPs/=
LSPs is further defined by an IID/ITID pair. It is then possible to have di=
fferent authentication types/keys for each Level/IID/ITID
scope. Whether an implementation would choose to support different authent=
ication type/key for each IID/ITID pair is up to the implementation to dete=
rmine.
[Uma]: Yes, as per base stan=
dard only area or domain level AUTH scope is defined. Now this is further f=
ragmented with topology granularity with in the L1 area
or L2 domain.
&nbs=
p; Les, I don't=
think this is about implementation choice rather this is a deployment ques=
tion. When you are providing this level of granularity (further
to base spec), I presume
&nbs=
p; authors foresee some iss=
ue with same key with much bigger (?) scope especially when
MI is used in conjunction with APP info tran=
sport?
&nbs=
p; It's ok to have IID/ITID=
specific AUTH but one should know consequences of not using if it is indee=
d needed in Section 7.
<=
/p>
LES2: There are thre=
e (not two) defined authentication scopes (as I specified above). Try searc=
hing ISO 10589 for the strings:
circuitTransm=
itPassword
areaTransmitP=
assword
domainTransmi=
tPassword
=
b>
There is no requirement th=
at 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 th=
ree scopes.
With MI, an additional sco=
pe is defined (IID/ITID) for LSPs/SNPs. As I have stated multiple times, th=
e 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.
=
b>
Please do not abuse my ver=
y clear statements on this point by saying “authors foresee some issu=
e with same key…”. We do not foresee an issue – if we did=
we would
clearly state this.
=
b>
As always, within the avai=
lable scopes, how many different keys are used is a decision made by those =
who deploy authentication in their networks.
5. Section 4
"There is no relationship between the Multi-t=
opology IDs defined in [RFC5120] and the ITIDs defined in this document.&qu=
ot;
"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 op=
erates on each topology.
This differs from [RFC5120] where a si=
ngle 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 h=
ere 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?
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 assoc=
iated w the legacy instance. Similarly,
IID/ITID specific SPFs (if executed) would be based solely on the PDUs ass=
ociated with that non-zero IID/ITID.
[Uma]: Ok, here is a simple example . Say,=
to get all the advantages of Paragraph 3 and 4 in Section 1 - and I am sti=
ll with the statement below:
"MI-IS-IS might be used to support topology specific rout=
ing. When used for this purpose it is an alternative to [RFC512=
0]."
say one chooses to deploy MI instead of MT and=
standard instance (IID=3D0) is used for IPV4 and IID=3Dx and ITID=3Dy is u=
sed for IPv6 topology . Let's make it simple and further assume
all
links are shared across standard IID and IID=3Dx. Now:
a. as there is no significance of ITID how other vendor nodes in the networ=
k know this is V6 topology and you are supposed to expand TLVs correspondin=
g to V6 in SPF? (no MT here)
b. even the node which is doing packing know how ITID=3Dy corresponds to IP=
v6 and tend to put only V6 related TLVs (now
http://tools.ietf.org/html/r=
fc5308 is the only choice here).
or
you see - keeping all topology information in both standard IID=
and IID=3Dx and ITID=3Dy (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.=
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)” defin=
ed in RFC 5120 for a few reserved MTIDs – but this covers only 6 of t=
he possible 4K MTIDs. If other MTIDs are used there clearly must be agreeme=
nt
on what purpose that topology serves – whether it be to support rout=
ing of a given address family or some other purpose. However the protocol h=
as 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 thi=
s is not an issue which is being addressed by the standards
- either 5120 or MI.
Les
--
Uma C.
--_000_F3ADE4747C9E124B89F0ED2180CC814F1184644Dxmbalnx02ciscoc_--
From uma.chunduri@ericsson.com Tue Oct 16 09:24:51 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CED21F8A44 for ; Tue, 16 Oct 2012 09:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.913
X-Spam-Level:
X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8bWQvEnk7ct for ; Tue, 16 Oct 2012 09:24:46 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 819E421F86E5 for ; Tue, 16 Oct 2012 09:24:46 -0700 (PDT)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q9GGQVLO027219; Tue, 16 Oct 2012 11:26:34 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.44]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 16 Oct 2012 12:24:44 -0400
From: Uma Chunduri
To: "Les Ginsberg (ginsberg)" , "isis-wg@ietf.org"
Date: Tue, 16 Oct 2012 12:24:43 -0400
Thread-Topic: draft-ietf-isis-mi-07 draft
Thread-Index: Ac2o3RTV6hPrVcf2T1OAoJqgYSBFMQAksk0QAEM6r5AAMnmBkAAIBhGQ
Message-ID:
References:
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D1D8138DDF34B34B8BC68A11262D10792B615E26FEEUSAACMS0701e_"
MIME-Version: 1.0
Subject: Re: [Isis-wg] draft-ietf-isis-mi-07 draft
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 16 Oct 2012 16:24:51 -0000
--_000_D1D8138DDF34B34B8BC68A11262D10792B615E26FEEUSAACMS0701e_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Les,
Section-1: "MI-IS-IS might be used to support topology specific routing. Wh=
en 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 alternativ=
e to current RFC 5120? (neither the draft).
Few quick clarifications below [Uma2]:
--
Uma C.
2. Section 2.1
"IS-IS PDUs associated with the legacy instance MUST NOT include an=
IID-TLV except where noted in this document."
LES2: It is common practice to refer to routers which do not support the p=
rotocol 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 ext=
ensions defined in this document."
I do not see how the text in the document contributes to your confusion.
[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=3D0 etc..)
---
[Uma]: Yes, as per base standard only area or domain level AUTH scope is d=
efined. Now this is further fragmented with topology granularity with in th=
e L1 area or L2 domain.
Les, I don't think this is about implementation choice rath=
er this is a deployment question. When you are providing this level of gran=
ularity (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 co=
nsequences of not using if it is indeed needed in Section 7.
LES2: There are three (not two) defined authentication scopes (as I specif=
ied above). Try searching ISO 10589 for the strings:
circuitTransmitPassword
areaTransmitPassword
domainTransmitPassword
There is no requirement that each of these passwords be unique. It is poss=
ible to successfully deploy authentication using the same key for all scope=
s. The restriction that the base spec (and RFC 5304/5310) define is that th=
ere 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 pos=
sible to do so.
Please do not abuse my very clear statements on this point by saying "auth=
ors foresee some issue with same key...". We do not foresee an issue - if w=
e did we would clearly state this.
As always, within the available scopes, how many different keys are used i=
s a decision made by those who deploy authentication in their networks.
[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 differentl=
y (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 auth=
entication for the first time for IS-IS, at minimum it warrants few stateme=
nts 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 d=
eploy this technology.
But, more description around this will facilitate the right deployment dec=
isions and will not cause over/under usage.
5. Section 4
"There is no relationship between the Multi-topology IDs defined in [R=
FC5120] 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 I=
TID. 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 comput=
ation actually happens say an instance supporting V4 and V6 topologies as =
some TLVs are significant to particular topology as defined in 5120 today?
LES: Different instances run as "ships in the night". A legacy instance sha=
res no adjacencies or PDUs with a non-zero instance. There is no relationsh=
ip between topology specific information advertised by a legacy instance us=
ing RFC 5120 extensions and a non-zero instance sending ITID specific infor=
mation. SPFs run by a legacy instance would be based solely on the informat=
ion advertised in PDUs associated w the legacy instance. Similarly, IID/ITI=
D specific SPFs (if executed) would be based solely on the PDUs associated =
with that non-zero IID/ITID.
[Uma]: Ok, here is a simple example . Say, to get all the advantages of Pa=
ragraph 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 f=
or this purpose it is an alternative to [RFC5120]."
say one chooses to deploy MI instead of MT and standard instance (IID=3D0) =
is used for IPV4 and IID=3Dx and ITID=3Dy is used for IPv6 topology . Let's=
make it simple and further assume all
links are shared across standard IID and IID=3Dx. Now:
a. as there is no significance of ITID how other vendor nodes in the networ=
k know this is V6 topology and you are supposed to expand TLVs correspondin=
g to V6 in SPF? (no MT here)
b. even the node which is doing packing know how ITID=3Dy corresponds to IP=
v6 and tend to put only V6 related TLVs (now http://tools.ietf.org/html/rfc=
5308 is the only choice here).
or
you see - keeping all topology information in both standard IID and IID=
=3Dx and ITID=3Dy (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 t=
he advantage?
The more I see... ok, will wait for your response first.
LES2: What a given topology is used for is not enforced by the protocol. Th=
is is true for RFC 5120 as well as MI.
[Uma2]: Your statement above is not correct completely. 5120 indeed enforc=
es 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 don=
e precisely (and I see no issue for my use case above).
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 - whet=
her it be to support routing of a given address family or some other purpos=
e. 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 ad=
dressed by the standards - either 5120 or MI.
Les
--
Uma C.
--_000_D1D8138DDF34B34B8BC68A11262D10792B615E26FEEUSAACMS0701e_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Les,
Section-1: "MI-IS-=
IS=20
might be used to support topology specific routing. When used for this purp=
ose=20
it is an alternative to [RFC5120]."
How?
You still didn't answer my question - how one mi=
ght use=20
MI as an alternative to current RFC 5120? (neither the=20
draft).
Few quick clarific=
ations=20
below [Uma2]:
--=20
2.=20
Section 2.1
"IS-IS PDUs assoc=
iated=20
with the legacy instance MUST NOT include an IID-TLV except where noted in =
this=20
document."
LES2: It is common practice to refer to routers whi=
ch do=20
not support the protocol extensions being defined in a new standard as R=
20;legacy=20
routers”. We are very careful to state (Section 1):
“ Legacy routers supp=
ort the=20
standard or zero instance of the protocol. The behavior of the=
=20
standard instance is not changed in any way by the extensions defined=
in=20
this document.”
=
I=20
do not see how the text in the document contributes to your=20
confusion.
=
[Uma2]: I was talk=
ing about=20
legacy instance statement as referred in sec 2.1 -- I got this with difficu=
lty=20
- you mean to say standard instance there .. (MI=20
capable router in IID=3D0 etc..)
---
[Uma]: Yes, as per base standard on=
ly area=20
or domain level AUTH scope is defined. Now this is further fragmented with=
=20
topology granularity with in the L1 area or L2 domain.
&n=
bsp; =20
Les, I don't think this is about implementation choice rather this is=
a=20
deployment question. When you are providing this level of granularity (furt=
her=20
to base spec), I presume
=20
authors foresee some issue with same key with much bigger (?) sc=
ope=20
especially when=20
MI is=20
used in conjunction with APP info transport?
&n=
bsp;=20
It's ok to have IID/ITID specific AUTH but one should know consequences of =
not=20
using if it is indeed needed in Section 7.
=
LES2:=20
There are three (not two) defined authentication scopes (as I specified abo=
ve).=20
Try searching ISO 10589 for the strings:
=
=20
circuitTransmitPassword
=
=20
areaTransmitPassword
=
=20
domainTransmitPassword
=
=
There=20
is no requirement that each of these passwords be unique. It is possible to=
=20
successfully deploy authentication using the same key for all scopes. The=20
restriction that the base spec (and RFC 5304/5310) define is that there are=
at=20
most three scopes.
=
With=20
MI, an additional scope is defined (IID/ITID) for LSPs/SNPs. As I have stat=
ed=20
multiple times, the draft is agnostic on whether it is desirable to use=20
different keys for each IID/ITID – we are simply saying that it is po=
ssible to=20
do so.
=
=
Please=20
do not abuse my very clear statements on this point by saying “author=
s foresee=20
some issue with same key…”. We do not foresee an issue – =
if we did we would=20
clearly state this.
=
=
As=20
always, within the available scopes, how many different keys are used is a=
=20
decision made by those who deploy authentication in their=20
networks.
=
=
[Uma2]:
=
First of all let me be clear on wha=
t I feel=20
about on this draft overall:
- =
this is=20
just not a simple TLV addition or minor extension to the protocol, rather t=
his=20
draft gives immense potential to use IS-IS differently (I see this as a=20
"technology" in itself)
- =
have=20
immense respect for you, your wisdom and rest of the authors of the=20
draft
- I clearly sa=
w the=20
ALTO/genapp use case this is addressing except the main question on MT=20
case.
&=
nbsp;=20
Now=20
coming to the abuse claim in the context of AUTH you made- not sure wh=
y=20
even feel that way.
I am simply asking - if it is required t=
o define=20
a new topology-level authentication for the first time for IS-IS, at=
=20
minimum it warrants few statements to clarify on why and how this is more=20
useful.
Absolutely, at the end of the day it's the de=
cision=20
made by the folks who deploy this technology.
But, more description aro=
und this=20
will facilitate the right deployment decisions and will not cause=20
over/under usage.=20
5.&nb=
sp;=20
Section 4
"There is no relationship between the=
=20
Multi-topology IDs defined in [RFC5120] and the ITIDs defined in this=20
document."
"An MI-RTR MAY use the extensi=
ons=20
defined in this document to support multiple topologies in the context of a=
n=20
instance with a non-zero IID.
Each =
MI=20
topology is associated with a unique LSDB identified by an ITID. An ITID=20
specific IS-IS Update Process operates on each=20
topology.
This differs from [RFC512=
0]=20
where a single LSDB/single IS-IS Update Process is used in support of all=20
topologies."
a)If =
there=20
is no relationship between MTID in 5120 and ITID here how computation actua=
lly=20
happens say an instance supporting V4 and V6 topologies as some =
TLVs=20
are significant to particular topology as defined in 5120=20
today?
LES:=20
Different instances run as “ships in the night”. A legacy insta=
nce shares no=20
adjacencies or PDUs with a non-zero instance. There is no relationship betw=
een=20
topology specific information advertised by a legacy instance using RFC 512=
0=20
extensions and a non-zero instance sending ITID specific information. SPFs =
run=20
by a legacy instance would be based solely on the information advertised in=
PDUs=20
associated w the legacy instance. Similarly, IID/ITID specific SPFs (if=20
executed) would be based solely on the PDUs associated with that non-zero=20
IID/ITID.&=
nbsp;
[Uma]:=20
Ok, here is a simple example . Say, to get all the advantages of Para=
graph=20
3 and 4 in Section 1 - and I am still with the statement below:
<=
SPAN=20
style=3D"FONT-FAMILY: 'Courier New'; COLOR: black; FONT-SIZE: 10pt">"MI-IS-=
IS=20
might be used to support topology specific routing. When used f=
or=20
this purpose it is an alternative to [RFC5120]."
s=
ay one=20
chooses to deploy MI instead of MT and standard instance (IID=3D0) is used =
for=20
IPV4 and IID=3Dx and ITID=3Dy is used for IPv6 topology . Let's make it sim=
ple and=20
further assume all
links are shared across standard IID and IID=3Dx.=20
Now:
a. as there is no significance of ITID how other vendor nodes in th=
e=20
network know this is V6 topology and you are supposed to expand TLVs=20
corresponding to V6 in SPF? (no MT here)
b. even the node which is doing=
=20
packing know how ITID=3Dy corresponds to IPv6 and tend to put only V6 relat=
ed TLVs=20
(now http://tools.ietf.org/html/rfc5=
308=20
is the only choice here).
or
you see - keeping all topo=
logy=20
information in both standard IID and IID=3Dx and ITID=3Dy (no MT) and adver=
tise is=20
an option (use 5308 and only one SPF yields all)? Then why one would bother=
to=20
put IID/ITID? Do you still the advantage?
The more I see... ok, will wai=
t for=20
your response first.
=
LES2:=20
What a given topology is used for is not enforced by the protocol. This is =
true=20
for RFC 5120 as well as MI.
=
=
[Uma2]: Your state=
ment=20
above is not correct completely. 5120 indeed enforces what is MTID 1 =
or 2=20
to 6, and that's absolutely useful. When, I say MTID 2 everybody in the net=
work=20
knows what I am talking and what has to be done precisely (and I see =
no=20
issue for my use case above).
=
=
There=20
are “conventions(sic)” defined in RFC 5120 for a few reserved M=
TIDs – but this=20
covers only 6 of the possible 4K MTIDs. If other MTIDs are used there clear=
ly=20
must be agreement on what purpose that topology serves – whether it b=
e to=20
support routing of a given address family or some other purpose. However th=
e=20
protocol has no way of advertising or enforcing such usage. It depends on=20
consistent configuration network wide.
=
You are=20
quite correct that inconsistent usage of a topology by nodes in the network=
will=20
be problematical – but this is not an issue which is being addressed =
by the=20
standards - either 5120 or MI.
=
=20
Les
-=
-
Uma=20
C.
--_000_D1D8138DDF34B34B8BC68A11262D10792B615E26FEEUSAACMS0701e_--
From ginsberg@cisco.com Tue Oct 16 22:39:10 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CAD21F8773 for ; Tue, 16 Oct 2012 22:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.865
X-Spam-Level:
X-Spam-Status: No, score=-9.865 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG3pHEf00TAm for ; Tue, 16 Oct 2012 22:39:05 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 89BCB21F873D for ; Tue, 16 Oct 2012 22:39:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33483; q=dns/txt; s=iport; t=1350452345; x=1351661945; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=j5Pk00YpJZmPY1JN/4cPyTHjfBayFL2rQeg/ihtu6bU=; b=fqo1XlIp80osEvmmSjUxYHgkYlGe+TcPFlMWXJoMg7pDwxJxNqwduHWj MtWF2qezInbP6nQqG7+oI/6/ZT0T+uAn1Woenk2CtB9NqQKPJUba6gAA5 +Nqm7hleFVR8FOyXaPam97Uu3BPR6YUZfj3kr1k5aOY0SKIrezL4Phuhr Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFACpEflCtJV2Y/2dsb2JhbABFgkq1BQGIVoEIgiABAQEEEgEaRRcCAQgRBAEBCxYBBgcyFAkIAQEEARIIGodiC5sgoBmLT4VgYAOXAI0ygWuCbYIX
X-IronPort-AV: E=Sophos;i="4.80,597,1344211200"; d="scan'208,217";a="132396413"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 17 Oct 2012 05:39:04 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9H5d3vQ006825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 05:39:04 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 00:39:03 -0500
From: "Les Ginsberg (ginsberg)"
To: Uma Chunduri , "isis-wg@ietf.org"
Thread-Topic: draft-ietf-isis-mi-07 draft
Thread-Index: Ac2o3RTV6hPrVcf2T1OAoJqgYSBFMQAksk0QAEM6r5AAMnmBkAAIBhGQADApGtA=
Date: Wed, 17 Oct 2012 05:39:02 +0000
Message-ID:
References:
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.96.235]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000
x-tm-as-result: No--30.029900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F11847EF5xmbalnx02ciscoc_"
MIME-Version: 1.0
Subject: Re: [Isis-wg] draft-ietf-isis-mi-07 draft
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 17 Oct 2012 05:39:11 -0000
--_000_F3ADE4747C9E124B89F0ED2180CC814F11847EF5xmbalnx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]
Sent: Tuesday, October 16, 2012 9:25 AM
To: Les Ginsberg (ginsberg); isis-wg@ietf.org
Subject: RE: draft-ietf-isis-mi-07 draft
Les,
Section-1: "MI-IS-IS might be used to support topology specific routing. Wh=
en 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 alternativ=
e to current RFC 5120? (neither the draft).
LES3: Section 2 defines how the set of topologies (ITIDs) supported on a gi=
ven circuit are advertised in IIHs and how topology specific neighbor/reach=
ability 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.
Few quick clarifications below [Uma2]:
--
Uma C.
2. Section 2.1
"IS-IS PDUs associated with the legacy instance MUST NOT include an=
IID-TLV except where noted in this document."
LES2: It is common practice to refer to routers which do not support the p=
rotocol 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 ext=
ensions defined in this document."
I do not see how the text in the document contributes to your confusion.
[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=3D0 etc..)
LES3: I agree the use of "legacy" in the sentence you have quoted above sho=
uld be replaced by "standard". We will make that change. Thanx for pointin=
g this out.
I have nothing to add to the comments I have previously made on the threads=
below.
Les
---
[Uma]: Yes, as per base standard only area or domain level AUTH scope is d=
efined. Now this is further fragmented with topology granularity with in th=
e L1 area or L2 domain.
Les, I don't think this is about implementation choice rath=
er this is a deployment question. When you are providing this level of gran=
ularity (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 co=
nsequences of not using if it is indeed needed in Section 7.
LES2: There are three (not two) defined authentication scopes (as I specif=
ied above). Try searching ISO 10589 for the strings:
circuitTransmitPassword
areaTransmitPassword
domainTransmitPassword
There is no requirement that each of these passwords be unique. It is possi=
ble to successfully deploy authentication using the same key for all scopes=
. The restriction that the base spec (and RFC 5304/5310) define is that the=
re 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 pos=
sible to do so.
Please do not abuse my very clear statements on this point by saying "autho=
rs 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.
[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 differentl=
y (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 auth=
entication for the first time for IS-IS, at minimum it warrants few stateme=
nts 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 d=
eploy this technology.
But, more description around this will facilitate the right deployment dec=
isions and will not cause over/under usage.
5. Section 4
"There is no relationship between the Multi-topology IDs defined in [R=
FC5120] 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 I=
TID. 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 comput=
ation actually happens say an instance supporting V4 and V6 topologies as =
some TLVs are significant to particular topology as defined in 5120 today?
LES: Different instances run as "ships in the night". A legacy instance sha=
res no adjacencies or PDUs with a non-zero instance. There is no relationsh=
ip between topology specific information advertised by a legacy instance us=
ing RFC 5120 extensions and a non-zero instance sending ITID specific infor=
mation. SPFs run by a legacy instance would be based solely on the informat=
ion advertised in PDUs associated w the legacy instance. Similarly, IID/ITI=
D specific SPFs (if executed) would be based solely on the PDUs associated =
with that non-zero IID/ITID.
[Uma]: Ok, here is a simple example . Say, to get all the advantages of Pa=
ragraph 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 f=
or this purpose it is an alternative to [RFC5120]."
say one chooses to deploy MI instead of MT and standard instance (IID=3D0) =
is used for IPV4 and IID=3Dx and ITID=3Dy is used for IPv6 topology . Let's=
make it simple and further assume all
links are shared across standard IID and IID=3Dx. Now:
a. as there is no significance of ITID how other vendor nodes in the networ=
k know this is V6 topology and you are supposed to expand TLVs correspondin=
g to V6 in SPF? (no MT here)
b. even the node which is doing packing know how ITID=3Dy corresponds to IP=
v6 and tend to put only V6 related TLVs (now http://tools.ietf.org/html/rfc=
5308 is the only choice here).
or
you see - keeping all topology information in both standard IID and IID=
=3Dx and ITID=3Dy (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 t=
he advantage?
The more I see... ok, will wait for your response first.
LES2: What a given topology is used for is not enforced by the protocol. Th=
is is true for RFC 5120 as well as MI.
[Uma2]: Your statement above is not correct completely. 5120 indeed enforc=
es 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 don=
e precisely (and I see no issue for my use case above).
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 - whet=
her it be to support routing of a given address family or some other purpos=
e. 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 ad=
dressed by the standards - either 5120 or MI.
Les
--
Uma C.
--_000_F3ADE4747C9E124B89F0ED2180CC814F11847EF5xmbalnx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<=
/p>
<=
/p>
From: Uma Chun=
duri [mailto:uma.chunduri@ericsson.com]
Sent: Tuesday, October 16, 2012 9:25 AM
To: Les Ginsberg (ginsberg); isis-wg@ietf.org
Subject: RE: draft-ietf-isis-mi-07 draft
Les,
Section-1: <=
/span>"MI-IS-IS
might be used to support topology specific routing. When used for this pur=
pose it is an alternative to [RFC5120]."
How?
You still didn't answer my que=
stion - how one might use MI as an alternative to current RFC 5120? (neithe=
r the draft).
<=
/p>
LES3: Section 2 define=
s how the set of topologies (ITIDs) supported on a given circuit are advert=
ised in IIHs and how topology specific neighbor/reachability
information is advertised in topology (ITID) specific LSPs. Section 4 R=
11; especially the last paragraph - specifically addresses the differences =
between RFC 5120 and MI multi-topology support. The necessary informa=
tion is in the draft.
Few quick clarifications below=
[Uma2]:
--
Uma C.
2. Section 2.1
"IS-IS PDUs associated with=
the legacy instance MUST NOT include an IID-TLV except where noted in this=
document."
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):<=
span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser=
if";color:red">
“ Legacy routers support t=
he standard or zero instance of the protocol. The behavior of t=
he standard instance is not changed in any way by the extensions defi=
ned in this document.”
I do not see how the text in the document=
contributes to your confusion. =
[Uma2]: I was talking about legacy inst=
ance statement as referred in sec 2.1 -- I got this with difficulty - =
you mean to say standard instance there .. (MI
capable router in IID=3D0 etc..)
LES3: I agree the use of “legacyR=
21; in the sentence you have quoted above should be replaced by “stan=
dard”. We will make that change. Thanx for pointing this out.
I have nothing to add to the comments I ha=
ve previously made on the threads below.
Les
---
[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.=
p>
&nbs=
p; Les, I don't=
think this is about implementation choice rather this is a deployment ques=
tion. When you are providing this level of granularity (further
to base spec), I presume
&nbs=
p; authors foresee some iss=
ue with same key with much bigger (?) scope especially when
MI is used in conjunction with APP info tran=
sport?
&nbs=
p; It's ok to have IID/ITID=
specific AUTH but one should know consequences of not using if it is indee=
d needed in Section 7.
<=
/p>
LES2: There are thre=
e (not two) defined authentication scopes (as I specified above). Try searc=
hing ISO 10589 for the strings:
circuitTransm=
itPassword
areaTransmitP=
assword
domainTransmi=
tPassword
There is no requirement th=
at 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 th=
ree scopes.
With MI, an additional sco=
pe is defined (IID/ITID) for LSPs/SNPs. As I have stated multiple times, th=
e 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 ver=
y clear statements on this point by saying “authors foresee some issu=
e 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 t=
hose who deploy authentication in their networks. =
p>
[Uma2]:
First of all let=
me be clear on what I feel about on this draft overall:
&nb=
sp; - this is just not a simple TLV addition or minor ext=
ension to the protocol, rather this draft gives immense potential to use IS=
-IS differently
(I see this as a "technology" in itself)
&nb=
sp; - have immense respect for you, your wisdom and =
rest of the authors of the draft
&nb=
sp; - I clearly saw the ALTO/genapp use case this is=
addressing except the main question on MT case.
&nb=
sp;
Now coming to the abu=
se claim in the context of AUTH you made- not sure why even feel that =
way.
I am simply asking -&=
nbsp;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 en=
d of the day it's the decision made by the folks who deploy this technology=
.
But, more descri=
ption around this will facilitate the right deployment decisions and =
will not cause over/under usage.
5. Section 4
"There is no relationship between the Multi-t=
opology IDs defined in [RFC5120] and the ITIDs defined in this document.&qu=
ot;
"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 op=
erates on each topology.
This differs from [RFC5120] where a si=
ngle 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 h=
ere 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?
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 assoc=
iated w the legacy instance. Similarly,
IID/ITID specific SPFs (if executed) would be based solely on the PDUs ass=
ociated with that non-zero IID/ITID.
[Uma]: Ok, here is a simple example . Say,=
to get all the advantages of Paragraph 3 and 4 in Section 1 - and I am sti=
ll with the statement below:
"MI-IS-IS might be used to support topology specific rout=
ing. When used for this purpose it is an alternative to [RFC512=
0]."
say one chooses to deploy MI instead of MT and=
standard instance (IID=3D0) is used for IPV4 and IID=3Dx and ITID=3Dy is u=
sed for IPv6 topology . Let's make it simple and further assume
all
links are shared across standard IID and IID=3Dx. Now:
a. as there is no significance of ITID how other vendor nodes in the networ=
k know this is V6 topology and you are supposed to expand TLVs correspondin=
g to V6 in SPF? (no MT here)
b. even the node which is doing packing know how ITID=3Dy corresponds to IP=
v6 and tend to put only V6 related TLVs (now
http://tools.ietf.org/html/r=
fc5308 is the only choice here).
or
you see - keeping all topology information in both standard IID=
and IID=3Dx and ITID=3Dy (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.=
LES2: What a given topology is used for i=
s not enforced by the protocol. This is true for RFC 5120 as well as MI.
[Uma2]: Your statem=
ent above is not correct completely. 5120 indeed enforces what is MTI=
D 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 b=
e done precisely (and I see no issue for my use case above).
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 a=
greement
on what purpose that topology serves – whether it be to support rout=
ing of a given address family or some other purpose. However the protocol h=
as 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 thi=
s is not an issue which is being addressed by the standards
- either 5120 or MI.
Les
--
Uma C.
--_000_F3ADE4747C9E124B89F0ED2180CC814F11847EF5xmbalnx02ciscoc_--
From internet-drafts@ietf.org Fri Oct 19 01:07:20 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B8021F8652; Fri, 19 Oct 2012 01:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.521
X-Spam-Level:
X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viZ7Q8zEh1Uy; Fri, 19 Oct 2012 01:07:19 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C51921F843E; Fri, 19 Oct 2012 01:07:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121019080719.30355.66257.idtracker@ietfa.amsl.com>
Date: Fri, 19 Oct 2012 01:07:19 -0700
Cc: isis-wg@ietf.org
Subject: [Isis-wg] I-D Action: draft-ietf-isis-mi-08.txt
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 19 Oct 2012 08:07:20 -0000
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the IS-IS for IP Internets Working Group of t=
he IETF.
Title : IS-IS Multi-Instance
Author(s) : Stefano Previdi
Les Ginsberg
Mike Shand
Abhay Roy
Dave Ward
Filename : draft-ietf-isis-mi-08.txt
Pages : 15
Date : 2012-10-19
Abstract:
This draft describes a mechanism that allows a single router to share
one or more circuits among multiple Intermediate System To
Intermediate System (IS-IS) routing protocol instances.
Multiple instances allow the isolation of resources associated with
each instance. Routers will form instance specific adjacencies.
Each instance can support multiple topologies. Each topology has a
unique Link State Database (LSDB). Each Protocol Data Unit (PDU)
will contain a new Type Length Value (TLV) identifying the instance
and the topology(ies) to which the PDU belongs.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-isis-mi
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-isis-mi-08
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-isis-mi-08
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
From chopps@rawdofmt.org Tue Oct 23 07:25:00 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB7C21F8596 for ; Tue, 23 Oct 2012 07:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5bBNbUtItmg for ; Tue, 23 Oct 2012 07:24:59 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5500821F855A for ; Tue, 23 Oct 2012 07:24:54 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id fl11so4689300vcb.31 for ; Tue, 23 Oct 2012 07:24:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer:x-gm-message-state; bh=pjEBFABhaV8+m3G5ZC5qZks14ZJezHRNUF3M+IvEW3U=; b=PN2OgYkHG+jSx9KPRvt2vE5wtPn5xTFyl0yUFCDFlNCMujvmZnl5YhKpghCyHubZLI WgmcEvqLxdvNcY4lR4PZAvrcMx0V3D+bZXsO8mjvj5fusgZnRdsbuxO2kbMDh72Se5TI A6Dc7uqGl7FbLIggOOoVf5R2yVqvJVLXjO79Sy9oY3iI16vj0GF9AO2E4Hq9MPjNlwC6 Wy93OM2qcrwejMxvl7Xh8O7BB2NmJyjChuiviPY8vnY2FAF7rzLmaqQQaG3PnLh7nUJn ycRTQiGYgafoPneJI18G1K/KqWrQ9cZQMDKU9wOeiGSt70SoDgKyrnGMm8r9EDym7jzp JzTw==
Received: by 10.220.227.70 with SMTP id iz6mr2431478vcb.45.1351002293277; Tue, 23 Oct 2012 07:24:53 -0700 (PDT)
Received: from rtp-chopps-8711.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id qj8sm12558397veb.2.2012.10.23.07.24.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Oct 2012 07:24:51 -0700 (PDT)
From: Christian Hopps
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Oct 2012 10:24:50 -0400
Message-Id:
To: "isis-wg@ietf.org list"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQls7OhkNuOzNFj/CADKlNmaXFmdM4h8hozlq0ZpW+z9Usr7fe57ZHkOrHuQ0QLFu8u65Gz5
Cc: Christian Hopps , David D D Ward
Subject: [Isis-wg] Call for IETF-85 agenda topics
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 23 Oct 2012 14:25:00 -0000
If you would like an agenda slot for the upcoming isis-wg meeting in =
Atlanta, please reply to either Dave or myself.
Thanks,
Chris & Dave.=
From iesg-secretary@ietf.org Wed Oct 24 09:22:17 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5742A21F8C13; Wed, 24 Oct 2012 09:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level:
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0++49-6ljUpn; Wed, 24 Oct 2012 09:22:16 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2824B21F8C56; Wed, 24 Oct 2012 09:22:16 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG
To: IETF-Announce
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121024162216.17284.42821.idtracker@ietfa.amsl.com>
Date: Wed, 24 Oct 2012 09:22:16 -0700
Cc: isis chair , isis mailing list , RFC Editor
Subject: [Isis-wg] Protocol Action: 'IS-IS Multi-Instance' to Proposed Standard (draft-ietf-isis-mi-08.txt)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 24 Oct 2012 16:22:17 -0000
The IESG has approved the following document:
- 'IS-IS Multi-Instance'
(draft-ietf-isis-mi-08.txt) as Proposed Standard
This document is the product of the IS-IS for IP Internets Working Group.
The IESG contact persons are Adrian Farrel and Stewart Bryant.
A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-isis-mi/
Technical Summary
This specification provides for a method for a single router to share one or
more circuits among multiple IS-IS routing protocol instances. This allows for
the isolation of resources into distinct instances.
Working Group Summary
The consensus was strong for this specification. While there was healthy
discussion and development over multiple revisions of the draft, no strong
objections were present during the development process.
Document Quality
There are no known current implementations of the draft; however, there has been
a large interest expressed in the WG by both vendors and operators for this
specification to be completed.
Personnel
Chris Hopps (chopps@rawdofmt.org) is the Document Shepherd
Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD
IANA Note
Please note that this document requests allocation from the IS-IS TLV registry that requires
expert review. The designated experts are Chris Hopps and Dave Ward, the current ISIS WG
co-chairs. Chris is also the Document Shepherd. Thus, expert review has been performed.
Additionally, please note that this document requests allocation from the Ethernet Numbers
registry that requires application by form and expert review. The designated expert is
Dan Romascanu, and he has performed expert review and confirmed he is OK with the
allocation. A copy of the application form is presented here:
> Contact Name:
> Les Ginsberg
>
> Contact Email:
> ginsberg@cisco.com
>
> Type of Assignment:
> Two EUI-48 bit multicast MAC layer addresses.
> (Block size is 2)
>
> Registry:
> Ethernet numbers as specified in RFC 5342
>
> http://www.iana.org/assignments/ethernet-numbers/ethernet-
> numbers.xml
>
> Description:
> Unique MAC multicast destination addresses are required for support
> of IS-IS Multi-Instance. These new addresses are used to isolate IS-IS
> PDUs associated with non-zero instances of the protocol from the
> legacy instance of the protocol. In this way the non-zero instance PDUs
> will not be seen by legacy instances. This is necessary to prevent
> operation of the non-zero instances from interfering with operation of
> the legacy instances.
>
> Two addresses are required. One for all level 1 MI routers (AllL1MI-
> ISs) and one for all level 2 MI routers (AllL2MI-ISs)
>
> Additional Info:
> http://datatracker.ietf.org/doc/draft-ietf-isis-mi/
From chopps@rawdofmt.org Thu Oct 25 07:49:49 2012
Return-Path:
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAEA21F8966 for ; Thu, 25 Oct 2012 07:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvLBYvO1zmLC for ; Thu, 25 Oct 2012 07:49:48 -0700 (PDT)
Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC5FE21F8963 for ; Thu, 25 Oct 2012 07:49:48 -0700 (PDT)
Received: by mail-gh0-f172.google.com with SMTP id g10so353851ghb.31 for ; Thu, 25 Oct 2012 07:49:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=TFHN7/w6XVExA7/bQL9JdzuUjADjFyjlmyORKGpcATs=; b=XpORVP9ClpJSC9Os9AbMU3HsuK3fGCef3TFpEMFlOFbpRQGitIH2j0RZc8f13CQJty ECD8Y3eXh6E7E3iu0Otdp991C94nDoReULqdbAjXAKFDUcAdtJK8zUgKi9FIA1YQ5s9C UlVlVTHITi/9TkXeXNfBfKfC0HgakqOP75FU3WAz8CxPCsCnkk/UVLATEPpcuqw4EGFF 3OcSIEGfwMG2aQB49O4+8HvP/yzVrPuTYPsRNG835ncQJR8QJeWuAUFsLWbutp0OnbxT vBasmnvNxTvmONUO/uAVWCo8JuvP/wNreX57DpH/N3V2nNBElZBFGZGpSvuLYoegUoRy kdpw==
Received: by 10.59.10.38 with SMTP id dx6mr1538431ved.40.1351176588236; Thu, 25 Oct 2012 07:49:48 -0700 (PDT)
Received: from rtp-chopps-8711.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id q7sm11805079vdw.22.2012.10.25.07.49.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Oct 2012 07:49:47 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Christian Hopps
In-Reply-To:
Date: Thu, 25 Oct 2012 10:49:45 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id:
References:
To: "isis-wg@ietf.org list"
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkmsAt6E23rMaESvtRFelcz6+6Y+OpEui6h41esCkI7rn+Xe0oalslUn9tNJt6iLF7DfbFP
Cc: Christian Hopps , David D D Ward
Subject: [Isis-wg] Proposed Agenda Posted [Re: Call for IETF-85 agenda topics]
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 25 Oct 2012 14:49:49 -0000
Here's the current posted proposed agenda:
Proposed Agenda for isis-wg, IETF 85
------------------------------------
3m - Intro, Adminastriva, Document Status
11m - IS-IS Multi-Instance
draft-ietf-isis-mi-08.txt
Les Ginsberg
11m - IS-IS Extended Sequence number TLV
draft-chunduri-isis-extended-sequence-no-tlv-03.txt
Uma Chunduri
11m - Interface Addresses TLV
draft-eastlake-isis-ia-tlv-01.txt
Donald Eastlake
Thanks,
Chris & Dave.
On Oct 23, 2012, at 10:24 AM, Christian Hopps =
wrote:
> If you would like an agenda slot for the upcoming isis-wg meeting in =
Atlanta, please reply to either Dave or myself.
>=20
> Thanks,
> Chris & Dave.