Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Tue, 12 April 2011 05:05 UTC

Return-Path: <manav.bhatia@alcatel-lucent.com>
X-Original-To: ospf@ietfc.amsl.com
Delivered-To: ospf@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 45A8AE0716 for <ospf@ietfc.amsl.com>; Mon, 11 Apr 2011 22:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.698
X-Spam-Level:
X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[AWL=1.901, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUU1ZlYi4tkI for <ospf@ietfc.amsl.com>; Mon, 11 Apr 2011 22:05:21 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id AC34DE0711 for <ospf@ietf.org>; Mon, 11 Apr 2011 22:05:21 -0700 (PDT)
Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3C55GHM001034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 00:05:18 -0500 (CDT)
Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3C55EdY012319 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Apr 2011 10:35:14 +0530
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 12 Apr 2011 10:35:14 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Michael Barnes <michael_barnes@usa.net>, "curtis@occnc.com" <curtis@occnc.com>, Abhay Roy <akr@cisco.com>
Date: Tue, 12 Apr 2011 10:34:15 +0530
Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai
Thread-Index: Acv4wnjm/tplLuZkRcWXYCGjweZOCAACw1zg
Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD037B1F@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <741PDLDGY7792S02.1302579230@web02.cms.usa.net>
In-Reply-To: <741PDLDGY7792S02.1302579230@web02.cms.usa.net>
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
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 05:05:22 -0000

Hi Michael,

> > right direction and would not have to be revisited quite as soon if
> > something more robust were proposed.
> > 
> > Bottom line.  Falls short of what I'd like to see but no objection.
> > 
> > Curtis
> 
> I agree with Curis. I'd really like to see the first version 
> of this spec at
> least have the extended sequence number as is being discussed for v2.

I disagree that AT should have a 64 bit sequence space in the base specification primarily because we are not yet sure if the KARP boot count approach is what the WG will finally converge on (in which case we would need an extended sequence space). Also note that the AT provides an "Auth Type" field which can be assigned a new value (similar to how it will be done for OSPFv2) once we decide to move to a different scheme. The same standard that extends the OSPFv2 sequence space can also do it for OSPFv3 AT block - really hardly an overhead.

Also note that you could consider this proposal as just bringing OSPFv3 at par with OSPFv2. Once this is done, any proposal that extends OSPFv2 will natively work for OSPFv3 as well.

Cheers, Manav