RE: FW: I-D ACTION:draft-nadas-vrrp-unified-spec-00.txt

Hi Don, 

Thanks for the comments; please see inline @ [SJN<x>].  My plan is 
to resolve these comments and respin draft as -01.  Please also 
see [SJN3]; if you can send me some text I can then include it.   

Regards, 
Steve  

> -----Original Message-----
> From: Don Provan [mailto:[email protected]] 
> Sent: Thursday, September 06, 2007 9:04 PM
> To: Stephen Nadas (RL/TNT); [email protected]
> Subject: RE: [VRRP] FW: I-D 
> ACTION:draft-nadas-vrrp-unified-spec-00.txt 
> 
> Steve,
> 
> This looks good to me. I see no significant problems, but I'm 
> going to make a couple of functional comments followed by 
> some editorial comments of less importance.
> 
> Functional 1: I'm convinced that not only can we handle 
> unmatched intervals, it's a good idea to support them for 
> many reasons. Just in the simple backup case, for example, it 
> makes no sense for the backup router to advertise on a 
> subsecond interval while the primary router is down, so we 
> should expect it to be standard practice for the owner to be 
> configured with a much faster interval than the backup.

[SJN1] I might change "it makes no sense" to "it may not make 
[SJN1] sense", but I'm ok with your point.

> 
> I mention this because I think some of the sections need to 
> be updated to reflect this. Section 5.2.7, for example, 
> should explicitly discuss the fact that routers can be 
> configured to different values, and, in my opinion, here (or 
> somewhere) the spec should say that implementations don't 
> have to have centisecond granularity as long as they report 
> the interval they actually use.

[SJN2] I think I am a bit confused about your last sentence 
[SJN2] wrt interop.  Can you please expand your comments? 

> 
> This would be the logical place to put the discussion about 
> systems configured to smaller intervals should always have 
> higher priorities. Then section A.3.1 can just refer to the 
> general discussion while pointing out the essentially 
> identical case where the higher priority node is v3 and the 
> lower one v2.
> 
> Similarly, the problem of a subsecond implementation 
> overwhelming a less capable implementation should be 
> discussed here, and
> A.3.2 should refer to it while mentioning that VRRPv2 
> implementations don't expect subsecond advertisements.
> 
> If everyone agrees to the logic of this, I'm willing to take 
> the first crack at rewriting this section to include these new ideas.

[SJN3] This is a fine way forward as far as I am concerned; 
[SJN3] we can also what the list may have to say. 

> 
> (By the way, shouldn't section 5.2.7 be "*Maximum* 
> Advertisement Interval"? The master is promising to send 
> packets with that interval or a smaller one, right?)
> 

[SJN4] I can reword along these lines. 

> Functional 2: In section 6.4.3, in the master event 
> processing description, the master's handling of an arriving 
> advertisement with higher priority doesn't mention the 
> PREEMPT flag. Is it intentional that a preemption happen in 
> this case even though the PREEMPT flag is FALSE?

[SJN5] not intentional. Hence, needs a fix. 

> 
> Editorial 1: Remove the editorial comment in the second 
> sentence in the first paragraph: I think section 4.1 is a 
> perfectly reasonable configuration, having a file server back 
> up a router, for example.
> But in any case, there's no reason for the spec to comment on 
> whether it is "expected to occur in actual practice".
> 

[SJN6] ok (this text is quite old. I think...) 

> Editorial 2: In section 8.1.1 (ICMP Redirects), the second 
> paragraph ends with "One method to deduce the virtual router 
> used is to examine the destination MAC address in the packet 
> that triggered the redirect."
> Is there another method? If so, I can't think of it. If not, 
> then explicitly say "The way to deduce...."
> 

[SJN7] ok. 

> Editorial 3: In section A.1, I find the rational for "upgrade only"
> to be weak, so I suggest removing it. Try the last half of 
> the section as, "2. Mixing VRRPv2 and VRRPv3 should only be 
> done when transitioning from VRRPv2 to VRRPv3. Mixing the two 
> versions should not be considered a permanent solution." and 
> leave it at that. In other words, just explain that that's 
> all the spec supports without offering a weak justification.
> 

[SJN8] ok. 

> Thanks, again. I think we're on the right track.
> -don
> 
> > -----Original Message-----
> > From: Stephen Nadas (RL/TNT) [mailto:[email protected]]
> > Sent: Wednesday, August 15, 2007 1:20 PM
> > To: [email protected]
> > Subject: [VRRP] FW: I-D ACTION:draft-nadas-vrrp-unified-spec-00.txt
> > 
> > 
> > Here's a go at the unified approach.
> > -steve
> > 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > Sent: Wednesday, August 15, 2007 4:15 PM
> > To: [email protected]
> > Subject: I-D ACTION:draft-nadas-vrrp-unified-spec-00.txt
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > 
> > 
> > 	Title		: Virtual Router Redundancy Protocol Version 3
> > for IPv4 and IPv6
> > 	Author(s)	: S. Nadas
> > 	Filename	: draft-nadas-vrrp-unified-spec-00.txt
> > 	Pages		: 43
> > 	Date		: 2007-8-15
> > 	
> >    This memo defines the Virtual Router Redundancy Protocol 
> (VRRP) for
> >    IPv4 and IPv6.  It is version three (3) of the protocol and it is
> >    based on VRRP (version 2) for IPv4 that is defined in RFC
> > 3768 and on
> >    draft-ieft-vrrp-ipv6-spec-08.txt.  VRRP specifies an election
> >    protocol that dynamically assigns responsibility for a virtual 
> > router
> >    to one of the VRRP routers on a LAN.  The VRRP router 
> controlling 
> > the
> >    IPv4 or IPv6 address(es) associated with a virtual 
> router is called
> >    the Master, and forwards packets sent to these IPv4 or IPv6
> >    addresses.  VRRP Master routers are configured with 
> virtual IPv4 or
> >    IPv6 addresses and VRRP Backup routers infer the address 
> family of
> >    the virtual addresses being carried based on the transport 
> > protocol.
> >    IPv4 addresses and IPv6 addresses never belong to the same group,
> >    that is, each address family has its own set of VRRP groups.  The
> >    election process provides dynamic fail over in the forwarding
> >    responsibility should the Master become unavailable.  
> For IPv4, the
> >    advantage gained from using VRRP is a higher availability default
> >    path without requiring configuration of dynamic routing or router
> >    discovery protocols on every end-host.  For IPv6, the advantage
> >    gained from using VRRP for IPv6 is a quicker switch over 
> to back up
> >    routers than can be obtained with standard IPv6 Neighbor Discover
> >    (RFC 2461) mechanisms.
> > 
> > 
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-nadas-vrrp-unified-s
> pec-00.txt
> 
> To remove yourself from the I-D Announcement list, send a 
> message to [email protected] with the word 
> unsubscribe in the body of the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then 
> "get draft-nadas-vrrp-unified-spec-00.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email protected].
> In the body type:
> 	"FILE /internet-drafts/draft-nadas-vrrp-unified-spec-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 

_______________________________________________
vrrp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/vrrp