Question on Election Algorithm

56th IETF VRRP WG Meeting

VRRP WG will be meeting in San Francisco. Please send me any potential agenda
items that you might have.

regards
Mukesh

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

very minor tweak suggested to draft-ietf-vrrp-spec-v2-06.txt

As I am reading through this specification as a new reader, the
following stands out:

: 7.1  Receiving VRRP Packets
: [...]
:       - MAY verify that "Count IP Addrs" and the list of IP Address
:         matches the IP_Addresses 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.

I believe that the bottom sentence is mandatory.
Since it is in the same paragraph, one might consider the "MAY" and
the "If the above check fails" to apply and thus you only MUST
drop the packet if you are verifying the count and the list.

I would suggest rewording the second sentence as a new paragraph:

If the packet was not generated by the address owner (Priority does
not equal 255 (decimal)), and either the "Count IP Addrs" or
the list of IP Addresses fails to match the IP_Addresses configured
for the VRID, then the receive MUST drop the packet.

--

-- 
Jeff Haas 
NextHop Technologies
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Re: very minor tweak suggested to draft-ietf-vrrp-spec-v2-06.txt

Jeff , as per rfc we are not dropping a non ip address owner 
generated packet if the IP address(es) associated with the VRID 
are not valid.Only we SHOULD log the event and MAY indicate via 
network management about the misconfiguration.Also we should 
further continue processing of the packet.Only in the case of 
address owner we MUST drop the packet.
As far as what u have suggested , we should also drop the non ip 
address owner generated packets.
cheer,
ashish thakur

On Thu, 16 Jan 2003 Jeffrey Haas wrote :
>As I am reading through this specification as a new reader, the
>following stands out:
>
>: 7.1  Receiving VRRP Packets
>: [...]
>:       - MAY verify that "Count IP Addrs" and the list of IP 
>Address
>:         matches the IP_Addresses 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.
>
>I believe that the bottom sentence is mandatory.
>Since it is in the same paragraph, one might consider the "MAY" 
>and
>the "If the above check fails" to apply and thus you only MUST
>drop the packet if you are verifying the count and the list.
>
>I would suggest rewording the second sentence as a new 
>paragraph:
>
>If the packet was not generated by the address owner (Priority 
>does
>not equal 255 (decimal)), and either the "Count IP Addrs" or
>the list of IP Addresses fails to match the IP_Addresses 
>configured
>for the VRID, then the receive MUST drop the packet.
>
>
>--
>Jeff Haas
>NextHop Technologies
>_______________________________________________
>vrrp mailing list
>vrrp <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Re: very minor tweak suggested to draft-ietf-vrrp-spec-v2-06.txt

Ashish,

On Thu, Jan 16, 2003 at 04:36:06AM -0000, ashish  thakur wrote:
> Jeff , as per rfc we are not dropping a non ip address owner 
> generated packet if the IP address(es) associated with the VRID 
> are not valid.Only we SHOULD log the event and MAY indicate via 
> network management about the misconfiguration.Also we should 
> further continue processing of the packet.Only in the case of 
> address owner we MUST drop the packet.

This is opposite the way I read the spec.

As I read the spec (cited below), we MUST drop the packet
if the priority is not 255.  If it *does* equal 255, we may
continue processing.

> ashish thakur

> >: 7.1  Receiving VRRP Packets
> >: [...]
> >:       - MAY verify that "Count IP Addrs" and the list of IP 
> >Address
> >:         matches the IP_Addresses 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.

--

-- 
Jeff Haas 
NextHop Technologies
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

VRRP IPSEC-AH FSM extension

Hi Mukesh,

I am currently writing the draft we discussed in a previous mail... In 
the discussion I need to offer an extended VRRP FSM design to expose all 
possible AH case. The FSM diagram I propose is the following :

                              +---------------+
             +----------------|               |----------------+
             |                |     Fault     |                |
             |  +------------>|               |<------------+  |
             |  |             +---------------+             |  |
             |  |                     ^                     |  |
             |  |                     |                     |  |
             |  |             +---------------+             |  |
             |  |  +--------->|               |<---------+  |  |
             |  |  |          |  Initialize   |          |  |  |
             |  |  |  +-------|               |-------+  |  |  |
             |  |  |  |       +---------------+       |  |  |  |
             |  |  |  |                               |  |  |  |
             V  |  |  V                               V  |  |  V
          +---------------+                       +---------------+
          |               |---------------------->|               |
          |    Master     |                       |    Backup     |
          |               |<----------------------|               |
          +---------------+                       +---------------+

I just add a new STATE : the FAULT state. This state is reflecting an 
interface physical state : shut or no shut, due to hardware failure, 
media link detection failure, ... All layer1 related errors. Since VRRP 
is extremly interface state dependent, I really think this state must be 
considered. There is two point of view, integrating this state directly 
into Master and Backup state but creating a new dedicated state  can be 
, IMHO, better for devel point of view, since FSM implementation is 
simplest. Especially for IPSEC-AH extension. What is your opinion ?

Best regards,
Alexandre

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Re: VRRP IPSEC-AH FSM extension

Hi Alexandre,

I am going to india for 15 days and will be back on 16th Feb. I will get
back to you after that.

In the meantime, I would appreciate if WG members could discuss the proposal
in WG and express their opinion/comments.

Thanks..
- Mukesh

ext Alexandre Cassen wrote:

> Hi Mukesh,
>
> I am currently writing the draft we discussed in a previous mail... In
> the discussion I need to offer an extended VRRP FSM design to expose all
> possible AH case. The FSM diagram I propose is the following :
>
>                               +---------------+
>              +----------------|               |----------------+
>              |                |     Fault     |                |
>              |  +------------>|               |<------------+  |
>              |  |             +---------------+             |  |
>              |  |                     ^                     |  |
>              |  |                     |                     |  |
>              |  |             +---------------+             |  |
>              |  |  +--------->|               |<---------+  |  |
>              |  |  |          |  Initialize   |          |  |  |
>              |  |  |  +-------|               |-------+  |  |  |
>              |  |  |  |       +---------------+       |  |  |  |
>              |  |  |  |                               |  |  |  |
>              V  |  |  V                               V  |  |  V
>           +---------------+                       +---------------+
>           |               |---------------------->|               |
>           |    Master     |                       |    Backup     |
>           |               |<----------------------|               |
>           +---------------+                       +---------------+
>
> I just add a new STATE : the FAULT state. This state is reflecting an
> interface physical state : shut or no shut, due to hardware failure,
> media link detection failure, ... All layer1 related errors. Since VRRP
> is extremly interface state dependent, I really think this state must be
> considered. There is two point of view, integrating this state directly
> into Master and Backup state but creating a new dedicated state  can be
> , IMHO, better for devel point of view, since FSM implementation is
> simplest. Especially for IPSEC-AH extension. What is your opinion ?
>
> Best regards,
> Alexandre

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp