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

From: "Michael Barnes" <[email-masked]>
Date: Mon, 11 Apr 2011 20:33:50 -0700

------ Original Message ------
Received: Mon, 11 Apr 2011 07:43:06 PM PDT
From: Curtis Villamizar <[email-masked]>
To: Abhay Roy <[email-masked]>Cc: "[email-masked]" <[email-masked]>
Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for
OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-03.txt

> 
> In message <[email-masked]>
> Abhay Roy writes:
> >  
> > We are starting the Working Group Last Call of this revision of the
> > subject draft.
> >  
> > This drafts is intended to be a Proposed Standard. The OSPF WG last
> > call will begin today and will end at 5pm PST, April 25th, 2011.
> >  
> > Abhay/Acee
> 
> 
> It is weak with only the 32 bit sequence number.  That said, if there
> is concensus for moving forward as-is I have no objection.  It is a
> step in the right direction, though IMHO it is too small a step in the
> 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.

Regards,
Michael

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 12 Apr 2011 10:34:15 +0530

Hi Michael,

> 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