Re: [VRRP] draft-ietf-vrrp-unified-spec-03.txt

[Mukesh Gupta <[e-mail]>]

Steve,

Sorry for responding late and thanks for doing the due diligence on this one.  After reading your email and looking at the changes, I agree that the implementations of the older draft should interoperate with the unified VRRP without any obvious issues.

Not sure if you have looked at the latest comments that Jari posted to the tracker https://datatracker.ietf.org/idtracker/draft-ietf-vrrp-unified-spec/.  Please look at them, if you already have not, and address them.

Lars/Pasi/Dan, we would appreciate if you could review the latest version and remove the DISCUSS if the latest version of the draft addresses your concerns satisfactorily.

Thanks!
- Mukesh

-----Original Message-----
From: Stephen Nadas [mailto:[e-mail]] 
Sent: Wednesday, July 15, 2009 1:31 PM
To: Mukesh Gupta; Pekka Savola
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Christian Vogt; Jari Arkko; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: draft-ietf-vrrp-unified-spec-03.txt 

Hi Mukesh, 

Here's what I did, wrt checking IPv6 interop between (A)
draft-ietf-vrrp-ipv6-spec-08.txt and (B) draft-ietf-vrrp-unified-03.txt
(actually pre-04 which numbered all these steps - but otherwise this is
same as -03 for this purpose).   

Following the rest of this discussion in detail depends on looking at
the attachments. 

I looked at sections 6.4.1 (init) , 6.4.2 (backup)  , 6.4.3 (master),
7.1(recv) & 7.2(transmit).  I labeled all the IPv6 and IPVx (i.e., 4 and
6 steps in common) as follows: 

	- by section: i-init, b-backup, m-master, r-recv, t-transmit, 
	- then by "6" for (A) and "u" for (B) 
	- and then with an alphanumeric as an id 

(so m63 is master state's 3rd step in (A) and mu3 is master state's 3rd
step in (B); step mub is 11th master state step in unified, etc.).
Things that don't line up/or may need something changed are labeled XXX.


Differences: 

6.4.1 (init) 
      sections are same but perhaps for editorial changes. 

6.4.2 (backup) 
      unified adds a step between "bum" and "bun" that recomputes
Master_Down_Interval.  I think this went in as byproduct of Mark
Handley's review note:
http://www.ietf.org/mail-archive/web/vrrp/current/msg01003.html
 
      otherwise sections are same but perhaps for editorial changes. 

6.4.3 (master) 

      1) unified  missed a step between "m63/m64" that said "MUST
respond to ND rtr solicits"  - this appears to be an editor goof and
should be added to unified.         

      2) Unified added a step (635) between steps "mu3" and "mu4" that
says "if accept mode is false: MUST NOT drop IPv6 Neighbor Solicits and
N. Adverts."  Editorially it looks like that maybe better placed in
w/step (650).    

      3) Unified added 2 steps in between "muo" and "mup" to recompute
skew and master_down_interval.  See Mark Handley's note:
http://www.ietf.org/mail-archive/web/vrrp/current/msg01003.html

      otherwise sections are same but perhaps for editorial changes. 

7.1 recv 
    softened step "r68" into "ru8" and removed "r69" and "r6a" based on
Don Provan's note, which says it copied wrrp list, but I can't see in
archive.  Anyway it is attached. 

    otherwise sections are same but perhaps for editorial changes. 

7.2 transmit 
    sections are same but perhaps for editorial changes. 
    
    editorially, "XXX" and "tu2" are same and should be pulled outside
of the if.


I think unified fixes some small things.  Maybe I'm missing something
basic, but I think IPv6 implementations would interop w/unified
implementations without issues.  There could be some issues where
unified has fixed something but (A) would have these issues too. 


Steve 



   

SJN> -----Original Message-----
SJN> From: Stephen Nadas 
SJN> Sent: Tuesday, July 14, 2009 6:36 PM
SJN> To: 'Mukesh Gupta'; Pekka Savola
SJN> Cc: [e-mail]; [e-mail]; 
SJN> [e-mail]; [e-mail]; [e-mail]; Christian 
SJN> Vogt; Jari Arkko; [e-mail]; 
SJN> [e-mail]; 
SJN> [e-mail]; [e-mail]
SJN> Subject: RE: draft-ietf-vrrp-unified-spec-03.txt 
SJN> 
SJN> SJN> That's a good point.  Steve, could you please check 
SJN> the differences 
SJN> SJN> between the v6 parts of this spec and the 
SJN> vrrp-ipv6-spec and see if 
SJN> SJN> both the version will be interoperable or not?  If 
SJN> there are enough 
SJN> SJN> differences, we might have to increment the version 
SJN> number in this 
SJN> SJN> spec :(
SJN> 
SJN> I am thinking we didn't change any of the IPv6 (at least 
SJN> intentionally) but I will check and get back.  
SJN> 
SJN> Steve