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

From: Mukesh Gupta <[email-masked]>
Date: Tue, 14 Jul 2009 00:47:50 -0700

Pekka,

[WG chair hat off]
[Copying the WG list]

>  - "Updates: 3768" (VRRPv2 spec) was added to the header.  Should this
>    be "Obsoletes: 3768".  Has the WG thought about this?  E.g. would
>    you like implementations to transition to VRRPv3?

Mukesh> I agree that it should be "Obsoletes: 3768".  The new spec does address a few issues in the VRRPv2 spec and the WG should recommend the implementations to transition to VRRPv3.

>    Operational issues aside, as you know, there have already been
>    v6-only draft-ietf-vrrp-ipv6-spec implementations that use Version
>    code 3.  This may or may not be a problem, depending on the
>    differences of v6 parts of this spec and vrrp-ipv6-spec.

That's a good point.  Steve, could you please check the differences between the v6 parts of this spec and the vrrp-ipv6-spec and see if both the version will be interoperable or not?  If there are enough differences, we might have to increment the version number in this spec :(

Pekka, I just know of one implementation (Nokia) of vrrp-ipv6-spec. Do you know of any more?

Regards
Mukesh

---

From: Pekka Savola <[email-masked]>
Date: Tue, 14 Jul 2009 11:08:27 +0300 (EEST)

> Pekka, I just know of one implementation (Nokia) of vrrp-ipv6-spec. 

You should ;-) -- Juniper's JunOS introduced VRRP for IPv6 in 8.4R 
(August 2007), and the implementation was based on 
draft-ietf-vrrp-ipv6-spec-07.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Mukesh Gupta <[email-masked]>
Date: Tue, 14 Jul 2009 01:16:43 -0700

Thanks!  I just joined Juniper.  I should have checked :)

I do remember sending multiple email on the WG mailing list asking for implementations to prepare the implementation report and receiving no replies :)

---

From: "Stephen Nadas" <[email-masked]>
Date: Tue, 14 Jul 2009 17:36:17 -0500

SJN> That's a good point.  Steve, could you please check the 
SJN> differences between the v6 parts of this spec and the 
SJN> vrrp-ipv6-spec and see if both the version will be 
SJN> interoperable or not?  If there are enough differences, we 
SJN> might have to increment the version number in this spec :(

I am thinking we didn't change any of the IPv6 (at least intentionally)
but I will check and get back.  

Steve

---

From: "Stephen Nadas" <[email-masked]>
Date: Wed, 15 Jul 2009 15:31:13 -0500

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: [email-masked]; [email-masked]; 
SJN> [email-masked]; [email-masked]; [email-masked]; Christian 
SJN> Vogt; Jari Arkko; [email-masked]; 
SJN> [email-masked]; 
SJN> [email-masked]; [email-masked]
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 

Subject: RE: May, should, must confusing section 7.1 vrrp
From: "Don Provan" <[email-masked]>
To: "Stephen Nadas" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Mon, 13 Apr 2009 13:05:57 -0500

I have to admit, I don't recall why I'm being singled out for these
questions. Did I rewrite this at some point or something? I have to
admit, I've always found myself at odds with this part of the spec
because it always seems as if my philosophy is much more liberal than
the original intent. But I'll do my best to answer, anyway...

"1) the check that the _local router_ isn't the IPvX address owner need
not say anything about _Priority 255_.  Right?"

I assume the intent was to reinforce that priority 255 *means* "owner".
I agree that "priority 255" makes one think of the packet rather than
the interface, but I don't think it's entirely wrong since we do, in
fact, signify ownership only by assigning 255 as our priority on the VR.
But it is redundant, and you can remove it if you feel that redundancy
causes confusion. 

"That is confusing and
afaict irelevant (If I get an adv for an address I own I must drop  &
shld log)"

I'm not sure what you're confused about. The owner should always
ignore any attempts by someone else to control the VR, and that
appears to be what the paragraph is saying.

"2) I am confused about the check that the packet came from the address
owner.  (Why can't I can get an adv from a master who is not the address
owner, eg a dfferent backup for a down master address owner.)"

My interpretation is that the original intent was that advertisements
from owners should be given special attention because they are assumed
to be more correct than any other information, including the local
configuration. Any other non-owner master might be configured worse
than us, but the owner's configuration is assumed to be golden.

"Is this latter a stand alone check that is really needed? (or maybe
some
text that has just been carried along?)  it doesn't seem to have
anything to do with the preceding MAY (which seems to be essence of
Mark's comment.)"

As I recall, originally the ``MAY verify that "Count IPvX Addrs" and the
list of IPvX Address matches the IPvX Address(es) configured for the
VRID''
was a MUST, and that's probably where the "MUST drop" came from. I think
the idea was that we should ignore advertisements from routers with a
misconfiguration of the IP addresses unless it was the owner, in which
case we should consider ourselves wrong.

I've always felt that there was a latent flaw in the VRRP design that
called for it to distrust any other router except the owner. I believe
this was a mistaken attempt at security, but we've subsequently rejected
VRRP security itself as counter-productive, and I think we need to
extend this to these consistency checks. In this section, I think that
means only reporting any inconsistent configurations but always continue
with normal advertisement processing rather than ever dropping an
advertisement because it differs from the one we would send.

-don

-----Original Message-----
From: Stephen Nadas [mailto:[email-masked]] 
Sent: Monday, April 06, 2009 3:12 PM
To: Don Provan
Cc: [email-masked]; [email-masked]
Subject: May, should, must confusing section 7.1 vrrp 

Hi Don, 

I'm trying, once again, to clean this up.   Been busy elsewhere... 

Mark H. pointed out: 

> Section 7.1:
> 
> - MAY verify that "Count IPvX Addrs" and the list of IPvX Address
>       matches the IPvX Address(es) configured for the VRID
> 
>    If the above check fails, the receiver SHOULD log the event and MAY
>    indicate via network management that a misconfiguration 
> was detected.
>    If the packet was not generated by the address owner (Priority does
>    not equal 255 (decimal)), the receiver MUST drop the packet,
>    otherwise continue processing.
> 
> This combination of MAY, SHOULD and MUST is confusing.  Also 
> it's not clear if the second "If" is conditional on the first 
> "If".  It seems like you may have a mandatory action that you 
> can't do unless you do an optional action.
> 

So I agree it's confusing.  The text (from rfc, and -v6 and from
combined) all say the same.  In particular the immediately prior text
isn't much better: 

      - MUST verify that the VRID is configured on the receiving
        interface and the local router is not the IPv6 Address owner
        (Priority equals 255 (decimal)).

   If any one of the above checks fails, the receiver MUST discard the
   packet, SHOULD log the event and SHOULD indicate via network
   management that an error occurred.

      - MAY verify that the IPv6 Address matches the IPv6_Address
(As above...)

So here's my questions: 

1) the check that the _local router_ isn't the IPvX address owner need
not say anything about _Priority 255_.  Right?  That is confusing and
afaict irelevant (If I get an adv for an address I own I must drop  &
shld log)  

2) I am confused about the check that the packet came from the address
owner.  (Why can't I can get an adv from a master who is not the address
owner, eg a dfferent backup for a down master address owner.)  

Is this latter a stand alone check that is really needed? (or maybe some
text that has just been carried along?)  it doesn't seem to have
anything to do with the preceeding MAY (which seems to be essence of
Mark's comment.) 

Thanks,
Steve

---

From: Mukesh Gupta <[email-masked]>
Date: Mon, 20 Jul 2009 18:10:42 -0700

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:[email-masked]] 
Sent: Wednesday, July 15, 2009 1:31 PM
To: Mukesh Gupta; Pekka Savola
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Christian Vogt; Jari Arkko; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: draft-ietf-vrrp-unified-spec-03.txt 

Hi Mukesh, 

Differences: 

6.4.1 (init) 

6.4.2 (backup) 

6.4.3 (master) 

7.1 recv 

7.2 transmit 

Steve