Subject: Re: [VRRP] tsv-dir review of draft-ietf-vrrp-unified-spec-02.txt

From: "Stephen Nadas" <[email-masked]>
Date: Mon, 3 Nov 2008 09:50:45 -0600

Hi Mark, 

Thank you for your careful reading of this draft and your comments.  

I think it's obvious that many of these should be incorporated, and
equally obvious there are also some things for the WG to mull over.

Regards,
Steve     

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mark Handley
> Sent: Thursday, October 30, 2008 08:58
> To: [email-masked]; TSV Dir; [email-masked]
> Subject: tsv-dir review of draft-ietf-vrrp-unified-spec-02.txt
> 
> I've reviewed this document as part of the transport area 
> directorate's ongoing effort to review key IETF documents. 
> These comments were written primarily for the transport area 
> directors, but are copied to the document's authors for their 
> information and to allow them to address any issues raised. 
> The authors should consider this review together with any 
> other last-call comments they receive.
> Please always CC [email-masked] if you reply to or forward 
> this review.
> 
> Generally the draft reads very well, and is clear and comprehensible.
> I had no difficulty understanding the draft overall, although 
> occasionally terms were used before they were properly 
> defined.  This isn't really a big deal, but I've highlighted 
> the below.
> 
> From a transport area point of view, the main things we're 
> looking for are whether the protocol will be well-behaved, 
> especially from the point of view of congestion control.  
> VRRP does not perform any form of congestion control, but as 
> it is purely a link-local protocol, configured by a network 
> operator to provide redundancy between two routers on the 
> same LAN segment, this is not really an issue.  One presumes 
> that a network operator choosing sub-second advertisement 
> intervals knows what he or she is doing, and knows 
> appropriate rates for their local circumstances.  Routers 
> provide many ways to shoot yourself in the foot, and this one 
> doesn't seem worth of concern.
> 
> However, the draft does have a weakness when it comes to congestion.
> It does not provide any guidance to router vendors as to 
> whether VRRP packets should receive priority treatment when 
> being transmitted.  The potentially problematic situation 
> occurs when a router is delivering more packets onto the LAN 
> than can be accomodated, and so a queue builds up in the 
> router.  Typical default queuing delays tend to be some 
> generic wide-area RTT (so that a delay-bandwidth product of 
> packets can be queued).  Thus packets being transmitted onto 
> the VRRP-protected LAN could see perhaps 100ms or more of 
> queuing delay.
> If VRRP packets enter such a queue, and the smallest VRRP 
> Advertisement_Interval is configured, the 
> Master_Down_Interval will be between 30 and 40ms.  Thus 
> normal queuing delays might cause a VRRP backup to conclude 
> that the master is down, and therefore promote itself to 
> master.  Very shortly afterwards, the delayed VRRP packets 
> from the master would arrive, causing a switch back to backup status.
> However this process can repeat many times per second, 
> causing significant disruption to traffic.
> 
> My feeling is that, if possible, VRRP packets should be 
> priority-forwarded onto the LAN, mitigating this problem.  
> However, it's not clear this is always possible.  At the 
> least, the draft ought to comment on this possible scenario 
> and the risks of very low Advertisement_Interval values in 
> the presence of congestion.
> 
> It would presumably be possible for a VRRP master to observe 
> such a situation is occurring frequently.  Under such 
> circumstances, at the least a good implementation should log 
> that there is a problem.  It might also be possible to 
> specify that the master should automatically backoff its 
> Advertisement_Interval value when it observes such thrashing. 
>  I'll leave it to the VRRP authors to think over whether that 
> might be desirable or might have unintended consequences.  I 
> think the draft can be progressed without any such adaptive 
> mechanism, but the authors may wish to think about it anyway, 
> as it might improve VRRP's robustness.
> 
> 
> Detailed comments on the spec (many of these are nit-picking, 
> but a few might be substantive):
> 
> Section 1.2, para 4:  "virtual router's IPv4 addresses"   - at this
> point in reading the draft, it wasn't clear to me whether 
> this was any of the addresses of any of the routers 
> comprising the virtual router or whether it was the address 
> being virtualized.  This became clear later on in the draft.
> 
> Section 1.3, para 4:  "could be speeded up"  - this is 
> awkward English; I'd have written "could be sped up" or 
> "could be made quicker"
> 
> Section 2.1, para 1: "Backup of an IPvX address(es)" - awkward English
> - better would be "Backup of an IPvX address or addresses"
> 
> Section 2.1, bullet 4 "Provide for election ... load 
> balancing".  It wasn't really clear to me what was meant by this.
> 
> Section 2.4, para 1:  "Sending either IPvX packets on..."  It 
> wasn't clear what this meant - do you mean "Sending either 
> IPv4 or IPv6 packets"?
> 
> Section 2.5 - is the internet draft referred to now dead?  If 
> so, this reference should probably be deleted, and the 
> sentence rephrased appropriately.
> 
> Section 3,  para 1:  "Each VRRP virtual router has a single 
> well-known MAC address allocated to it."  I understand what 
> this means, but I wonder if this should be scoped to indicate 
> it's true per link?
> There's some potential for misunderstanding that the same MAC 
> address must be used for the same VRID on other interfaces of 
> the same router, which I don't think is intended.
> 
> Section 3, para 2: I found this whole paragraph somewhat confusing.
> It's trying to say too many things in too few sentences.
> 
> Section 5.2.9, para 2:  "associated with" is a rather vague term.
> Maybe "being backed up by" or something similar would be clearer?
> 
> Section 6.1.  Should the VR MAC address be a parameter?  I 
> think it should.
> 
> Section 6.1: "Accept_Mode"  - the explanation here could be clearer.
> An example would help.
> 
> Section 6.4.1 - a "Startup event" is not defined.  I can 
> guess was is meant, but it might be better to define it.
> 
> Section 6.4.2 "Broadcast gratuitous ARP request"  should 
> probably say "Broadcast gratuitous ARP request on that interface".
> 
> Section 6.4.3 .  "Note: IPv6 Neighbor Solicitations and 
> Neighbor Advertisements  should not be dropped when 
> Accept_Mode is False."
> This would probably be better being stated a few lines 
> earlier, in the two MUST bullets.  In any event, it seems 
> like it's a MUST not a SHOULD.
> 
> Section 6.4.3, top of page 27.  I think the actions are incorrect.
> They are currently:
> 
>                @ Cancel Adver_Timer
> 
>                @ Recompute the Master_Down_Interval
> 
>                @ Set Master_Adver_Interval to Adver Interval contained
>                in the ADVERTISEMENT
> 
>                @ Set Master_Down_Timer to Master_Down_Interval
> 
>                @ Transition to the {Backup} state
> 
> I think they should be:
> 
>                @ Cancel Adver_Timer
> 
>                @ Set Master_Adver_Interval to Adver Interval contained
>                in the ADVERTISEMENT
> 
>                @ Recompute the Skew_Time
> 
>                @ Recompute the Master_Down_Interval
> 
>                @ Set Master_Down_Timer to Master_Down_Interval
> 
>                @ Transition to the {Backup} state
> 
> Ie, it should explicitly say recompute Skew_Time, but more 
> importantly, the Master_Adver_Internal needs to be set before 
> computing Master_Down_Interval, otherwise you use the old 
> (obsolete) value.
> 
> 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.
> 
> Section 7.4, para 3:
> 
>    An implementation might choose simplify this for the operator by
>    using the VRRP MAC in the formation of these link local addresses.
> 
> Should be "might" be a MAY?
> 
> "VRRP MAC" is not a defined term.  I think the right term is 
> "Virtual Router MAC Address".
> 
> This whole paragraph seemed a little vague.
> 
> Section 8.1.2:
> 
>    "When a VRRP router restarts or boots, it SHOULD not send any ARP
>    messages with its physical MAC address for the IPv4 
> address it owns,
>    it should only send ARP messages that include Virtual MAC 
> addresses."
> 
> How do you ssh to the physical router, if you're not sure 
> which router you'll actually reach?  Does this require a 
> separate IPv4 address?
> 
>       "When configuring an interface, VRRP routers should broadcast a
>       gratuitous ARP request containing the virtual router MAC address
>       for each IPv4 address on that interface."
> 
> Surely a VRRP router only does this when becoming the master?
> Otherwise backup routers can cause traffic to be blackholed 
> when their interface is configured.  Similar text appears in 8.2.2.
> 
> Section 9.1.  I don't know much about FDDI.  If you do as 
> described, I assume there's some way to avoid the packet 
> circulating forever?
> 
> 
> To summarize:  I think the draft has a few issues that need 
> to be addressed before publication.  Most of the issues are 
> pretty minor; it's up to the IESG as to whether addressing 
> them would require a new last call, but my expection is that 
> it would not.
> 
> That's all.  I hope this is of some help to you.
> 
> Cheers,
> Mark
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
> 
_______________________________________________
vrrp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vrrp

---

From: "Stephen Nadas" <[email-masked]>
Date: Tue, 4 Nov 2008 10:06:56 -0600

When Mark Handley reviewed draft-ietf-vrrp-unified-spec-02.txt, one area
the WG should (imho) discuss  is excerpted below. 

This thread is started to discuss the below scenario.  Please comment. 

Thanks,
Steve

---

From: "Stephen Nadas" <[email-masked]>
Date: Tue, 4 Nov 2008 10:24:13 -0600

Hi Mark, 

This text came from the v6 draft.  I think it alludes to the idea that
once can imagine, e.g., 1/2 of the hosts using one VRRP router and the
other half another, although I think it might be more clear to say
either: 

- Provide for selection of multiple virtual routers on a network for
load balancing
                 
(i.e., s/elect/select/) 

- Provide for capability of multiple virtual routers on a network for
load balancing

(i.e. s/election/capability/) 

If I read your comment correctly, the word "election" is what is
confusing here.  Does this meet your concern? 

Thanks, 
Steve

---

From: "Stephen Nadas" <[email-masked]>
Date: Tue, 4 Nov 2008 10:38:27 -0600

Hi Mark, 

Makes sense to me.  WG comments please. 

Steve

---

From: "Stephen Nadas" <[email-masked]>
Date: Tue, 4 Nov 2008 10:44:51 -0600

Hi Mark, 

Regards 1st point, good qn. I would like to hear WG comments please. 

Regards 2nd point, yes, when master.  I can clarify text. 

Thanks,
Steve

---

From: "Stephen Nadas" <[email-masked]>
Date: Tue, 4 Nov 2008 10:49:10 -0600

> described, I assume there's some way to avoid the packet 

Me either.  Text taken from earlier.  WG comments please to address
Mark's comment.

Thanks,
Steve

---

From: "don provan" <[email-masked]>
Date: Tue, 4 Nov 2008 10:06:07 -0800

I greatly appreciate the input your are giving from your broader
perspective. We'd be foolish to ignore your advice. That's why I
asked about routing protocol specs: I have no experience with them
(lately), so I have no idea how they address issues such as queuing
delay. Presumably people working on routing protocols have discussed
these issues to death, *and* with tons of experience to inform them.
I can't think of any differences that makes VRRP unique, so I was
hoping we could leverage the wisdom already enshrined in more
mature specs.

Yes, I agree that a new mechanism is not required at this time.
-don

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Mark Handley
> Sent: Tuesday, November 04, 2008 9:41 AM
> To: don provan
> Cc: Stephen Nadas; TSV Dir; vrrp
> Subject: Re: [VRRP] Congestion questions and
> draft-ietf-vrrp-unified-spec-02.txt
> 
> 
> I think primarily it's a problem with subsecond timeouts.  These bring
> the possible timeout range below typical queuing delays at congested
> routers, whereas before the default delays were long enough to be
> fairly robust.
> 
> I've not been involved with VRRP, so feel free to ignore my advice.
> However, I think that the simplest solution is to simply discuss the
> potential issue in the spec, and leave it to vendors to decide how to
> mitigate the potential problem.
> 
> Detecting thrashing and backing off would probably be beneficial, but
> it's not worth delaying this spec over.  However the WG might think
> whether this is something worth considering for an enhancement
> document.
> 
>  - Mark
> 
> On Tue, Nov 4, 2008 at 5:30 PM, don provan <[email-masked]> wrote:
> > VRRP is operating as a routing protocol, and the queuing
> > delay problem would seem universal to routing protocols.
> > What do routing protocol specs say about this?
> >
> > Is this a problem only because of the subsecond changes?
> > Or is it an issue with the existing VRRP spec and its minimum
> > 3 second timeout? In the back of my mind, I've been thinking
> > that the subsecond work was really just reducing the VRRP
> > transmission rate limit so that the interval can be set low
> > enough to be comparable with today's networks to what the 1
> > second transmission rate was, vis-a-vis these same queuing
> > issues in the networks available when VRRP was first published.
> > The logic is that networks are a thousand times faster today,
> > so a transmission rate of 1ms should be just as pedestrian
> > today as a rate of 1 second was when VRRPv1 was invented.
> >
> > At the same time, all the points raised here seem reasonable,
> > and I have to objection to the spec addressing them as people
> > see fit. But as far as I know, no one has much experience with
> > subsecond VRRP in real world environments, so I'm not sure what
> > concrete suggestions we can make about it.
> >
> > I'd like to avoid complicating the spec with ways to deal
> > with high transmission rates in heavily congested networks
> > when we don't really know whether or not the *real* answer
> > is "don't run high transmission rates in heavily congested
> > networks." If anything, I'd say we should beef up the
> > protocol's ability to deal with *any* intermittent connectivity
> > failures rather than one that specifically deals only with
> > the failures caused by unexpected queuing delays. For example:
> >
> >> It might also be possible to
> > This only deals only with queuing delays. If, instead, we
> > taught backups to increase their timeout when they detected
> > themselves thrashing, we'd handle the problem caused by queuing
> > delay *and* problems caused by high packet loss rates with the
> > same mechanism. But the real question is whether the protocol
> > should deal with these issues at all, or whether it's
> > sufficient for the network administrator to.
> >
> > -don
> >
> >> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >> Stephen Nadas
> >> Sent: Tuesday, November 04, 2008 8:07 AM
> >> To: Mark Handley; TSV Dir; [email-masked]
> >> Subject: [VRRP] Congestion questions and
> >> draft-ietf-vrrp-unified-spec-02.txt
> >>
> >>
> >> When Mark Handley reviewed
> >> draft-ietf-vrrp-unified-spec-02.txt, one area

---

From: "Stephen Nadas" <[email-masked]>
Date: Tue, 4 Nov 2008 12:11:05 -0600

Hi Mark, 

I've started several threads to cover the more substantive issues -
these email threads are on VRRP list and not reproduced here. 

Please see inline for the less substantive issues. 

Thank you again for your detailed and thoughtful feedback. 

Regards,
Steve 
 
> as it might improve VRRP's robustness.

See separate thread 

> being virtualized.  This became clear later on in the draft.

Will revisit & try to clarify

> awkward English; I'd have written "could be sped up" or 

Ok 

> - better would be "Backup of an IPvX address or addresses"

Ok 

> balancing".  It wasn't really clear to me what was meant by this.

See separate thread 

> wasn't clear what this meant - do you mean "Sending either 

Will revisit & consider clarifications

> sentence rephrased appropriately.

ok

> the same router, which I don't think is intended.

Will revisit & consider clarifications

> It's trying to say too many things in too few sentences.

Will revisit & consider clarifications

> Maybe "being backed up by" or something similar would be clearer?

Will revisit & consider clarifications

> Section 6.1.  Should the VR MAC address be a parameter?  I 

I think the combination of IPv4 or IPv6 and the VRID forces the VR MAC. 

> Section 6.1: "Accept_Mode"  - the explanation here could be clearer.

Will revisit & consider clarifications

> guess was is meant, but it might be better to define it.

Will revisit & consider clarifications

> probably say "Broadcast gratuitous ARP request on that interface".

Ok 

> like it's a MUST not a SHOULD.

Will revisit & consider clarifications

> computing Master_Down_Interval, otherwise you use the old 

See separate thread 

> can't do unless you do an optional action.

Will revisit & consider clarifications

> Should be "might" be a MAY?

Will revisit & consider clarifications

> This whole paragraph seemed a little vague.

Will fix term and will revisit & consider clarifications

> when their interface is configured.  Similar text appears in 8.2.2.

See separate thread

> described, I assume there's some way to avoid the packet 

See separate thread 

> That's all.  I hope this is of some help to you.

I'm sure this will improve the draft.

---

From: "Mukesh Gupta" <[email-masked]>
Date: Tue, 4 Nov 2008 10:11:45 -0800

[WG member hat on]

Mark,

Doesn't this apply to all routing protocols? AFAIK, the general
recommendation or practice is should be using netctrl queues for the
control traffic such as routing protocols and that should be documented
in some BCP independently. For example, does the OSPF spec
suggest/recommend how to handle congestion?

Regards
Mukesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Nadas

Thanks,
Steve

---

From: "don provan" <[email-masked]>
Date: Tue, 4 Nov 2008 10:31:25 -0800

WARNING: contains banned part

Subject: RE: [VRRP] Election or selection? Was tsv-dir review ofdraft-ietf-vrrp-unified-spec-02.txt
From: "don provan" <[email-masked]>
To: "'Stephen Nadas'" <[email-masked]>, "'Mark Handley'" <[email-masked]>, "'TSV Dir'" <[email-masked]>, <[email-masked]>
Date: Tue, 4 Nov 2008 10:31:25 -0800

How about "Allow" instead of "Provide for election of"?
But I agree with your analysis: "election" is misused here.
Masters are elected, not virtual routers.
-don

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Stephen Nadas
> Sent: Tuesday, November 04, 2008 8:24 AM
> Subject: [VRRP] Election or selection? Was tsv-dir review
> ofdraft-ietf-vrrp-unified-spec-02.txt
> 
> 
>

---

From: "don provan" <[email-masked]>
Date: Tue, 4 Nov 2008 09:30:36 -0800

Subject: RE: [VRRP] Congestion questions and draft-ietf-vrrp-unified-spec-02.txt
From: "don provan" <[email-masked]>
To: "'Stephen Nadas'" <[email-masked]>, "'Mark Handley'" <[email-masked]>, "'TSV Dir'" <[email-masked]>, <[email-masked]>
Date: Tue, 4 Nov 2008 09:30:36 -0800

-don

---

From: "don provan" <[email-masked]>
Date: Tue, 4 Nov 2008 10:37:39 -0800

Subject: RE: [VRRP] Actions after receive ADV with non-zero pri (was RE: tsv-dirreview of draft-ietf-vrrp-unified-spec-02.txt)
From: "don provan" <[email-masked]>
To: "'Stephen Nadas'" <[email-masked]>, "'Mark Handley'" <[email-masked]>, <[email-masked]>, "'TSV Dir'" <[email-masked]>, <[email-masked]>
Date: Tue, 4 Nov 2008 10:37:39 -0800

> Makes sense to me.  WG comments please. 

Yes. Good catch.
-don

---

From: "don provan" <[email-masked]>
Date: Tue, 4 Nov 2008 11:27:35 -0800

Subject: RE: [VRRP] Arps and grat arps was (RE: tsv-dir review ofdraft-ietf-vrrp-unified-spec-02.txt)
From: "don provan" <[email-masked]>
To: "'Stephen Nadas'" <[email-masked]>, "'Mark Handley'" <[email-masked]>, "'TSV Dir'" <[email-masked]>, <[email-masked]>
Date: Tue, 4 Nov 2008 11:27:35 -0800

> > which router you'll actually reach?  Does this require a 

Yes, a separate IPv4 address is required. Since there's no
particular reason to think that any given physical router will
be able to use the VR IP address at any given time, a separate
IPv4 address is required in order to address the physical router.

The idea that one router "owns" the VR IP address is an attempt
to reduce the number of other IP addresses required by one: the
owner can *always* use his address when he wants to because he
will always be the master when he's up.

> when their interface is configured.  Similar text appears in 8.2.2.

Well, I do think the text is intended to refer to the situation
where the master is "configuring" the interface in the sense of
adjusting it to make it function correctly for its role as the
master interface for the VR. I agree with you and Steve that
that could be clearer.

But it doesn't really matter: all routers *can* send gratuitous
ARP messages for the VR. The VR ARP information is constant: it
does not change when the VRRP master changes. No black hole would
be created: all the entries map the VR IP address to the VR MAC
address. The current master is the node that receives all packets
sent to the VR MAC address no matter what node actually distributed
the VR ARP mapping.

-don

---

From: "don provan" <[email-masked]>
Date: Tue, 4 Nov 2008 13:04:35 -0800

Do they sniff MAC addresses in ARP packets? I didn't know that
was legal.

The source MAC address in the ARP packet's MAC header must always
be the physical MAC address of the system, of course, never the
VR MAC address. I've only ever heard of switches learning based
on the source MAC address *in* the MAC header. Am I about to have
a learning experience?
-don
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark Handley
  Sent: Tuesday, November 04, 2008 12:36 PM
  To: don provan
  Cc: Stephen Nadas; TSV Dir; vrrp
  Subject: Re: [VRRP] Arps and grat arps was (RE: tsv-dir review ofdraft-ietf-vrrp-unified-spec-02.txt)

  On Tue, Nov 4, 2008 at 7:27 PM, don provan <[email-masked]> wrote:

  Won't you blackhole the traffic if you do this on a LAN composed of MAC-learning switches?

   - Mark

---

From: "don provan" <[email-masked]>
Date: Tue, 4 Nov 2008 13:47:47 -0800

I don't understand how the ARP type matters as long as the
response doesn't use the VR MAC address in the MAC header.
-don
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark Handley
  Sent: Tuesday, November 04, 2008 1:27 PM
  To: don provan
  Cc: Stephen Nadas; TSV Dir; vrrp
  Subject: Re: [VRRP] Arps and grat arps was (RE: tsv-dir review ofdraft-ietf-vrrp-unified-spec-02.txt)

  Sorry - my confusion - the text does say ARP *request*, but I was thinking of ARP responses.  You are of course correct.

   - Mark

  On Tue, Nov 4, 2008 at 9:04 PM, don provan <[email-masked]> wrote:

      -----Original Message-----
      From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark Handley
      Sent: Tuesday, November 04, 2008 12:36 PM
      To: don provan
      Cc: Stephen Nadas; TSV Dir; vrrp
      Subject: Re: [VRRP] Arps and grat arps was (RE: tsv-dir review ofdraft-ietf-vrrp-unified-spec-02.txt)

       - Mark

---

From: "Mark Handley" <[email-masked]>
Date: Thu, 30 Oct 2008 12:58:26 +0000

I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they receive.
Please always CC [email-masked] if you reply to or forward this
review.

Generally the draft reads very well, and is clear and comprehensible.
I had no difficulty understanding the draft overall, although
occasionally terms were used before they were properly defined.  This
isn't really a big deal, but I've highlighted the below.

>From a transport area point of view, the main things we're looking for
are whether the protocol will be well-behaved, especially from the
point of view of congestion control.  VRRP does not perform any form
of congestion control, but as it is purely a link-local protocol,
configured by a network operator to provide redundancy between two
routers on the same LAN segment, this is not really an issue.  One
presumes that a network operator choosing sub-second advertisement
intervals knows what he or she is doing, and knows appropriate rates
for their local circumstances.  Routers provide many ways to shoot
yourself in the foot, and this one doesn't seem worth of concern.

However, the draft does have a weakness when it comes to congestion.
It does not provide any guidance to router vendors as to whether VRRP
packets should receive priority treatment when being transmitted.  The
potentially problematic situation occurs when a router is delivering
more packets onto the LAN than can be accomodated, and so a queue
builds up in the router.  Typical default queuing delays tend to be
some generic wide-area RTT (so that a delay-bandwidth product of
packets can be queued).  Thus packets being transmitted onto the
VRRP-protected LAN could see perhaps 100ms or more of queuing delay.
If VRRP packets enter such a queue, and the smallest VRRP
Advertisement_Interval is configured, the Master_Down_Interval will be
between 30 and 40ms.  Thus normal queuing delays might cause a VRRP
backup to conclude that the master is down, and therefore promote
itself to master.  Very shortly afterwards, the delayed VRRP packets
from the master would arrive, causing a switch back to backup status.
However this process can repeat many times per second, causing
significant disruption to traffic.

My feeling is that, if possible, VRRP packets should be
priority-forwarded onto the LAN, mitigating this problem.  However,
it's not clear this is always possible.  At the least, the draft ought
to comment on this possible scenario and the risks of very low
Advertisement_Interval values in the presence of congestion.

It would presumably be possible for a VRRP master to observe such a
situation is occurring frequently.  Under such circumstances, at the
least a good implementation should log that there is a problem.  It
might also be possible to specify that the master should automatically
backoff its Advertisement_Interval value when it observes such
thrashing.  I'll leave it to the VRRP authors to think over whether
that might be desirable or might have unintended consequences.  I
think the draft can be progressed without any such adaptive mechanism,
but the authors may wish to think about it anyway, as it might improve
VRRP's robustness.

Detailed comments on the spec (many of these are nit-picking, but a
few might be substantive):

Section 1.2, para 4:  "virtual router's IPv4 addresses"   - at this
point in reading the draft, it wasn't clear to me whether this was any
of the addresses of any of the routers comprising the virtual router
or whether it was the address being virtualized.  This became clear
later on in the draft.

Section 1.3, para 4:  "could be speeded up"  - this is awkward
English; I'd have written "could be sped up" or "could be made
quicker"

Section 2.1, bullet 4 "Provide for election ... load balancing".  It
wasn't really clear to me what was meant by this.

Section 2.4, para 1:  "Sending either IPvX packets on..."  It wasn't
clear what this meant - do you mean "Sending either IPv4 or IPv6
packets"?

Section 2.5 - is the internet draft referred to now dead?  If so, this
reference should probably be deleted, and the sentence rephrased
appropriately.

Section 3,  para 1:  "Each VRRP virtual router has a single well-known
MAC address allocated to it."  I understand what this means, but I
wonder if this should be scoped to indicate it's true per link?
There's some potential for misunderstanding that the same MAC address
must be used for the same VRID on other interfaces of the same router,
which I don't think is intended.

Section 6.1.  Should the VR MAC address be a parameter?  I think it should.

Section 6.4.1 - a "Startup event" is not defined.  I can guess was is
meant, but it might be better to define it.

Section 6.4.2 "Broadcast gratuitous ARP request"  should probably say
"Broadcast gratuitous ARP request on that interface".

Section 6.4.3 .  "Note: IPv6 Neighbor Solicitations and Neighbor
Advertisements  should not be dropped when Accept_Mode is False."
This would probably be better being stated a few lines earlier, in the
two MUST bullets.  In any event, it seems like it's a MUST not a
SHOULD.

               @ Cancel Adver_Timer

I think they should be:

               @ Cancel Adver_Timer

Ie, it should explicitly say recompute Skew_Time, but more
importantly, the Master_Adver_Internal needs to be set before
computing Master_Down_Interval, otherwise you use the old (obsolete)
value.

Section 7.1:

   indicate via network management that a misconfiguration was detected.

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.

Section 7.4, para 3:

"VRRP MAC" is not a defined term.  I think the right term is "Virtual
Router MAC Address".

Section 8.1.2:

   "When a VRRP router restarts or boots, it SHOULD not send any ARP
   messages with its physical MAC address for the IPv4 address it owns,
   it should only send ARP messages that include Virtual MAC addresses."

How do you ssh to the physical router, if you're not sure which router
you'll actually reach?  Does this require a separate IPv4 address?

Surely a VRRP router only does this when becoming the master?
Otherwise backup routers can cause traffic to be blackholed when their
interface is configured.  Similar text appears in 8.2.2.

Section 9.1.  I don't know much about FDDI.  If you do as described, I
assume there's some way to avoid the packet circulating forever?

To summarize:  I think the draft has a few issues that need to be
addressed before publication.  Most of the issues are pretty minor;
it's up to the IESG as to whether addressing them would require a new
last call, but my expection is that it would not.

Cheers,
Mark

---

From: "Mark Handley" <[email-masked]>
Date: Tue, 4 Nov 2008 17:41:22 +0000

- Mark

---

From: "Mark Handley" <[email-masked]>
Date: Tue, 4 Nov 2008 20:36:07 +0000

> sent to the VR MAC address no matter what node actually distributed

Won't you blackhole the traffic if you do this on a LAN composed of
MAC-learning switches?

 - Mark

---

From: "Mark Handley" <[email-masked]>
Date: Tue, 4 Nov 2008 21:27:23 +0000

Sorry - my confusion - the text does say ARP *request*, but I was thinking
of ARP responses.  You are of course correct.

 - Mark

On Tue, Nov 4, 2008 at 9:04 PM, don provan <[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]]*On
> Behalf Of *Mark Handley
> *Sent:* Tuesday, November 04, 2008 12:36 PM
> *To:* don provan
> *Cc:* Stephen Nadas; TSV Dir; vrrp
> *Subject:* Re: [VRRP] Arps and grat arps was (RE: tsv-dir review
> ofdraft-ietf-vrrp-unified-spec-02.txt)
>
>
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 05 Nov 2008 16:36:00 -0800

Hi, all,

>>    "When a VRRP router restarts or boots, it SHOULD not send any ARP

FWIW, this might read better as "SHOULD NOT"

> Regards 2nd point, yes, when master.  I can clarify text. 

I understand sending the gratuitous ARP on reboot/restart, but I don't
understand why it matters that the physical MAC *not* be ARPed. It
should not matter - the VR uses a separate IP address and MAC address
anyway, right?

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 05 Nov 2008 16:43:06 -0800

Mark Handley wrote:
> Sorry - my confusion - the text does say ARP *request*, but I was
> thinking of ARP responses.  You are of course correct.
> 
>  - Mark
> 
> On Tue, Nov 4, 2008 at 9:04 PM, don provan <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Not only switches, FWIW, but end hosts sniff too. This caused a problem
a few IETFs back (as someone on this list may recall).

Joe

>         *From:* [email-masked]
>         <mailto:[email-masked]>
>         [mailto:[email-masked]
>         <mailto:[email-masked]>]*On Behalf Of *Mark Handley
>         On Tue, Nov 4, 2008 at 7:27 PM, don provan <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 05 Nov 2008 16:40:40 -0800

> Me either.  Text taken from earlier.  WG comments please to address

AFAICT, this could cause a packet to circulate forever; FDDI doesn't
have a counter AFAIR (it was a *long* time ago...)

Joe

---

From: Matt Mathis <[email-masked]>
Date: Wed, 5 Nov 2008 21:23:49 -0500 (EST)

> have a counter AFAIR (it was a *long* time ago...)

The problem is not in the normal token passing process, but the process for 
electing a master, which is responsible for generating the clock for the 
entire ring, keeping a bit FIFO to absorb jitter introduced by phase locked 
loop hunting, and other management functions such as re-injecting tokens after 
a hiccup as well as several self diagnostic functions.  AFAICR the mac address 
in used for tie breaking when a new master is elected.  From the words in the 
vrrp draft, I have to assume that duplicate mac addresses cause the algorithm 
to fail.

In the normal token passing process the station which injects the frame is the 
one to removes it.  This is not done by matching the addresses, but by 
steering the bits in the layer 1 serialization logic.  Normally the sending 
station is removing the head of the frame while it is still sending the tail. 
A given station can send multiple frames, but at some point it must send a 
special "token" frame.  Any station which has traffic to send can claim the 
token (by flipping one symbol) thereby changing it into a a packet preamble, 
and the process continues with a new sender.

Loosing the token (a ring of all idle symbols) is detected and corrected by 
the master.

Yea, we had lots of FDDI at one point.

Thanks,
--MM--
-------------------------------------------
Matt Mathis     http://staff.psc.edu/mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.
_______________________________________________
vrrp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vrrp

---

From: "don provan" <[email-masked]>
Date: Thu, 6 Nov 2008 13:12:38 -0800

> Not only switches, FWIW, but end hosts sniff too. This caused 
> a problem a few IETFs back (as someone on this list may recall).

I don't care who sniffs what as long as they don't draw incorrect
conclusions about the mapping addressed by the ARP packet based
on MAC layer information. Anyone that does that is simply broken
and will be confused by VRRP no matter who sends what ARP messages.
-don
_______________________________________________
vrrp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vrrp