headers
Stephen Nadas | 3 Nov 2008 16:18
Picon
Favicon

Re: late question/comment on vrrp-unified-spec-02: IPv4 equivalence

Hi James, 

I looked at 3768, which references 1256 as info and only refers to it as
one of several ways a host might get an IPv4 address.  As
vrrp-unified-spec-02 was heavily based on 3768 for its IPv4 sections,
this explains why it doesn't discuss this.  Ignoring unified question
for a moment, it looks to me that a 3768 compliant backup not running
1256 of a (3768 compliant) master that was running 1256 could hose a
1256 client.  

The question is what, if anything, to do?  As editor, first I'd like to
do nothing as 3768 was silent.  Failing that, maybe clone 8.2.3 into
8.1.x and mention possibility of 1256?  My understanding is that editor
is in a "waiting for guidance" mode just now; the vrrp list is silent,
so I've copied the necessary folks.  

Thanks,
Steve 

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson <at> sun.com] 
> Sent: Thursday, October 30, 2008 14:28
> To: Stephen Nadas
> Cc: vrrp <at> ietf.org
> Subject: late question/comment on vrrp-unified-spec-02: IPv4 
> equivalence
> 
> I searched the list, and found no mention of this issue.  
> Apologies if my searching-fu is insufficient, and it's 
> already been dealt with, and also because I know that this is
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stephen Nadas | 3 Nov 2008 16:50
Picon
Favicon

Re: tsv-dir review of draft-ietf-vrrp-unified-spec-02.txt

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: ietf-bounces <at> ietf.org [mailto:ietf-bounces <at> ietf.org] On 
> Behalf Of Mark Handley
> Sent: Thursday, October 30, 2008 08:58
> To: ietf <at> ietf.org; TSV Dir; vrrp <at> ietf.org
> 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 tsv-dir <at> ietf.org 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Nadas | 3 Nov 2008 17:15
Picon
Favicon

Re: late question/comment on vrrp-unified-spec-02: IPv4 equivalence

> 
> > The question is what, if anything, to do?  As editor, first 
> I'd like 
> > to do nothing as 3768 was silent.
> 
> By that token, it was also silent about router discovery in 
> an IPv6 environment.

I'm a bit confused here, bcos 3768 was IPv4 only. 

Thanks,
Steve 
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Stephen Nadas | 4 Nov 2008 17:06
Picon
Favicon

Congestion questions and draft-ietf-vrrp-unified-spec-02.txt

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 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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stephen Nadas | 4 Nov 2008 17:24
Picon
Favicon

Election or selection? Was tsv-dir review of draft-ietf-vrrp-unified-spec-02.txt


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

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  

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen Nadas | 4 Nov 2008 17:38
Picon
Favicon

Actions after receive ADV with non-zero pri (was RE: tsv-dir review of draft-ietf-vrrp-unified-spec-02.txt)

> Section 6.4.3, top of page 27.  I think the actions are incorrect.
> They are currently:
> 
>                 <at>  Cancel Adver_Timer
> 
>                 <at>  Recompute the Master_Down_Interval
> 
>                 <at>  Set Master_Adver_Interval to Adver Interval contained
>                in the ADVERTISEMENT
> 
>                 <at>  Set Master_Down_Timer to Master_Down_Interval
> 
>                 <at>  Transition to the {Backup} state
> 
> I think they should be:
> 
>                 <at>  Cancel Adver_Timer
> 
>                 <at>  Set Master_Adver_Interval to Adver Interval contained
>                in the ADVERTISEMENT
> 
>                 <at>  Recompute the Skew_Time
> 
>                 <at>  Recompute the Master_Down_Interval
> 
>                 <at>  Set Master_Down_Timer to Master_Down_Interval
> 
>                 <at>  Transition to the {Backup} state
> 
> Ie, it should explicitly say recompute Skew_Time, but more
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Nadas | 4 Nov 2008 17:44
Picon
Favicon

Arps and grat arps was (RE: tsv-dir review of draft-ietf-vrrp-unified-spec-02.txt)


> 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.

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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Stephen Nadas | 4 Nov 2008 17:46
Picon
Favicon

FW: Actions after receive ADV with non-zero pri (was RE: tsv-dir reviewof draft-ietf-vrrp-unified-spec-02.txt)

Insure on VRRP list...
-steve  

-----Original Message-----
From: ietf-bounces <at> ietf.org [mailto:ietf-bounces <at> ietf.org] On Behalf Of
Stephen Nadas
Sent: Tuesday, November 04, 2008 11:38
To: Mark Handley; ietf <at> ietf.org; TSV Dir; vrrp <at> ietf.org
Subject: Actions after receive ADV with non-zero pri (was RE: tsv-dir
reviewof draft-ietf-vrrp-unified-spec-02.txt) 

> Section 6.4.3, top of page 27.  I think the actions are incorrect.
> They are currently:
> 
>                 <at>  Cancel Adver_Timer
> 
>                 <at>  Recompute the Master_Down_Interval
> 
>                 <at>  Set Master_Adver_Interval to Adver Interval contained
>                in the ADVERTISEMENT
> 
>                 <at>  Set Master_Down_Timer to Master_Down_Interval
> 
>                 <at>  Transition to the {Backup} state
> 
> I think they should be:
> 
>                 <at>  Cancel Adver_Timer
> 
>                 <at>  Set Master_Adver_Interval to Adver Interval contained
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Nadas | 4 Nov 2008 17:49
Picon
Favicon

FDDI operation (was RE: tsv-dir review of draft-ietf-vrrp-unified-spec-02.txt)

> 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?
> 

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

Thanks,
Steve
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 2 comments |
headers
don provan | 4 Nov 2008 19:06
Favicon

Re: Congestion questions and draft-ietf-vrrp-unified-spec-02.txt

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

> -----Original Message-----
> From: mark.j.handley <at> gmail.com [mailto:mark.j.handley <at> gmail.com]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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane