Subject: [VRRP] VRRP versions & Misc L2s (was RE: DISCUSS and COMMENT: draft-ietf-vrrp-unified-spec )

From: "Stephen Nadas" <[email-masked]>
Date: Wed, 5 Nov 2008 07:16:04 -0600

Hi Dan, 

Thank you for these comments.  I will fix and/or consider clarifications
for the next pass. 

Regarding DISCUSS: 

1) Perhaps it is clarifying to say that the text discussing the VRRP
version came from the v6 draft, and there is no such text in 3768.  But
3768 does send packets with the version field set to 2 and I think all
"VRRPv3" is trying to say is that  the unified draft sends packets with
the version field set to 3.       

2) I do not know of such deployments and I'd be happy to loose all of
this text, perhaps VRRP list knows more.  

Thanks,
Steve   

> -----Original Message-----
> From: Dan Romascanu [mailto:[email-masked]] 
> Sent: Tuesday, November 04, 2008 16:09
> To: [email-masked]
> Cc: [email-masked]; 
> [email-masked]
> Subject: DISCUSS and COMMENT: draft-ietf-vrrp-unified-spec 
> 
> Discuss:
> 1. The version management and transition plan for VRRP is 
> unlear to me. The Introduction section mentions that this 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'. However RFC 3768 does not 
> make the claim to be VRRPv2, itlooks like this terminology 
> was decided later and is defined here for the first time. On 
> the other hand draft-ieft-vrrp-ipv6-spec-08.txt which VRRPv3 
> is based upon is just an informative reference and is 
> actually an expired I-D? Should not this document update RFC 
> 3768, and should not at least part of the migration and 
> coexistence issues in Appendix A be moved to the Operational 
> Issues section? 
> 
> 2. I do not understand what is the logic of including a 
> section 9 'Operation over FDDI, Token Ring, and ATM LANE' in 
> this document. Has anybody heard about a deployment of any of 
> these layer 2 networks lately, and with VRRP atop of them?
> 
> Comment:
> 
> Appendix B and part of Appendix C excepting the part refering 
> to changes from RFC 3768 should be dropped at publication.
> 
> 
_______________________________________________
vrrp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vrrp

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 5 Nov 2008 14:22:46 +0100

Concerning 1) - yes, clarification of the terminology in the
introduction section on the lines of what you explain here would
probably help, so if you can draw a proposal for text I would be happy
to consider it. Also, should this document be marked on the header as an
update to RFC 3768? 

Dan

> From: Stephen Nadas [mailto:[email-masked]] 
> Sent: Wednesday, November 05, 2008 3:16 PM
> To: Romascanu, Dan (Dan); [email-masked]
> [email-masked]; [email-masked]
> Subject: VRRP versions & Misc L2s (was RE: DISCUSS and 
> COMMENT: draft-ietf-vrrp-unified-spec )
> 
> Hi Dan, 
> 
> Thank you for these comments.  I will fix and/or consider 
> clarifications for the next pass. 
> 
> Regarding DISCUSS: 
> 
> 1) Perhaps it is clarifying to say that the text discussing 
> the VRRP version came from the v6 draft, and there is no such 
> text in 3768.  But
> 3768 does send packets with the version field set to 2 and I 
> think all "VRRPv3" is trying to say is that  the unified 
> draft sends packets with
> 2) I do not know of such deployments and I'd be happy to 
> loose all of this text, perhaps VRRP list knows more.  
> 
> Thanks,
> Steve   
> 
> > 1. The version management and transition plan for VRRP is unlear to 
> > me. The Introduction section mentions that this 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'. However 
> > RFC 3768 does not make the claim to be VRRPv2, itlooks like this 
> > terminology was decided later and is defined here for the 
> first time. 
> > On the other hand draft-ieft-vrrp-ipv6-spec-08.txt which VRRPv3 is 
> > based upon is just an informative reference and is actually 
> an expired 
> > I-D? Should not this document update RFC 3768, and should 
> not at least 
> > part of the migration and coexistence issues in Appendix A 
> be moved to 
> > the Operational Issues section?
> > 
> > 2. I do not understand what is the logic of including a section 9 
> > 'Operation over FDDI, Token Ring, and ATM LANE' in this 
> document. Has 
> > anybody heard about a deployment of any of these layer 2 networks 
> > lately, and with VRRP atop of them?
> > 
> > Comment:
> > 
> > Appendix B and part of Appendix C excepting the part refering to 
> > changes from RFC 3768 should be dropped at publication.
> > 
> > 
>