headers
Mukesh Gupta | 4 Aug 2008 19:59
Favicon

FW: Please ask your WG...


-----Original Message-----
From: wgchairs-bounces <at> ietf.org [mailto:wgchairs-bounces <at> ietf.org] On
Behalf Of NomCom Chair
Sent: Sunday, August 03, 2008 7:43 AM
To: Working Group Chairs
Subject: Please ask your WG... 

To volunteer for the nomcom.
The nomcom process is (in my opinion) better served by a large pool of
volunteers drawn from a wide spectrum of IETF attendees.
As such, please ask on your individual mailing lists for folks to
volunteer.

Obviously, the exact method for doing so is up to you.
The most recent call for volunteers can be reference here:
    https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1617
Whether you copy that message, or reference is probably up to you and
the
habits of your working group mailing list.
If you want to reference or copy the status message I sent out, that can
be found at:
    https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1618

Thank you,
Joel M. Halpern
Nomcom Chair
jmh <at> joelahlpern.com
nomcom-chair <at> ietf.org
_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kalyan.Tata | 18 Aug 2008 01:59
Picon

Re: indexing order in vrrpAssociatedIpAddrTable in draft-ietf-vrrp-unified-mib-06.txt

Hi Prakash,
    The order was as you suggested in the initial drafts. This was discussed in one of the ietf meetings and  I think
Wijnen, Bert suggested and every one agreed to change the order to what it is right now.
The rational (as I remember it) for vrrpOperationsInetAddrType to be first is that operators would like to walk on IPv4 or IPv6 virtual routers with out actually  knowing vrids or ifindexes.
 
I do not remember the exact reason of the other part of the order. Am CCing the WG to see if Mukesh or anyone else
remembers the discussion.

Thanks,
Kalyan

 

From: ext Banthia, Prakash (Prakash) [mailto:pbanthia <at> alcatel-lucent.com]
Sent: Thursday, August 14, 2008 3:43 PM
To: Tata Kalyan (Nokia-S&S/MtView)
Cc: Chung Kam Chung, Georges (Georges); Abdouni, Bassem (Bassem); Bailey, Reva Sue (Reva)
Subject: indexing order in vrrpAssociatedIpAddrTable in draft-ietf-vrrp-unified-mib-06.txt

Kalyan,
Let me introduce myself. I am part of the team which is implementing draft-ietf-vrrp-unified-mib-06.txt here at Alcatel-Lucent.
And I have a question on the indexing order in vrrpAssociatedIpAddrTable.
 
From original VRRP-MIB, here is the indexing order:
vrrpAssoIpAddrEntry OBJECT-TYPE
    INDEX    { ifIndex, vrrpOperVrId, vrrpAssoIpAddr }
 
From the new draft which support IPv6, here is the indexing order:
vrrpAssociatedIpAddrEntry OBJECT-TYPE
    INDEX    { vrrpOperationsInetAddrType, vrrpOperationsVrId,
               ifIndex, vrrpAssociatedIpAddr }
 
I would like to have vrrpOperationsInetAddrType and vrrpAssociatedIpAddr objects together which is typically how ipv6 support is generally implemented. Our utility routines always assume these to be together.
 
So I would prefer the following INDEX for vrrpAssociatedIpAddrTable:
    INDEX    {  vrrpOperationsVrId, ifIndex, vrrpOperationsInetAddrType, vrrpAssociatedIpAddr }
 
Let me know your thoughts on this.
Thanks.
--prakash
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 1 comment |
headers
Huafeng Lu | 20 Aug 2008 11:25
Picon

ipv6 multicast address


Hi,

The following is stated in the draft:

5.1.2.2.  Destination Address

   The IPv6 multicast address as assigned by the IANA for VRRP is:

   FF02:0:0:0:0:0:XXXX:XXXX

   This is a link-local scope multicast address.  Routers MUST NOT
   forward a datagram with this destination address regardless of its
   Hop Limit.

So the address is not fixed? A master virtual router can send adv to any
addr in this range, and a backup virtual router has to join all
multicast groups within this range? This doesn't sounds quite clear to me.

Can someone explain a bit to me? Thanks.
--
Huafeng
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 5 comments |
headers
Chiu Hsia Peng | 20 Aug 2008 14:32
Picon

Potential Forwarding Loop

Hi,
The following is stated in the RFC 3768.

8.4.  Potential Forwarding Loop

   A VRRP router SHOULD not forward packets addressed to the IP
Address(es) it becomes Master for if it is not the owner.  Forwarding
these packets would result in unnecessary traffic.  Also in the case
   of LANs that receive packets they transmit (e.g., token ring) this
 can result in a forwarding loop that is only terminated when the IP
TTL expires.

...
I am confused about the above description. Since 6.4.3 already
describe: A master, .. MUST NOT accept packets addressed to the IP
address(es) associated with the virtual router if it is not the IP
address owner. I think if a VRRP router doesn't accept a packet, it
can be implied that the router doesn't forward it either.

What's the purpose of this section?
Could someone give me a concrete example about the potential forwarding loop?

 Thanks.
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 1 comment |
headers
John Cruz (johcruz | 20 Aug 2008 19:29
Picon
Favicon

Re: ipv6 multicast address

Please see Section 13. The address to be used is FF02::12.

John

13.  IANA Considerations

   VRRP for IPv6 needs an IPv6 link-local scope multicast address
   assigned by the IANA for this specification.  The IPv6 multicast
   address should be of the following form:

      FF02:0:0:0:0:0:XXXX:XXXX

   The values assigned address should be entered into section 5.1.2.2.

   A convenient assignment of this link-local scope multicast would be:
      FF02:0:0:0:0:0:0:12

> -----Original Message-----
> From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf
Of
> Huafeng Lu
> Sent: Wednesday, August 20, 2008 2:26 AM
> To: vrrp <at> ietf.org
> Subject: [VRRP] ipv6 multicast address
> 
> 
> Hi,
> 
> The following is stated in the draft:
> 
> 5.1.2.2.  Destination Address
> 
>    The IPv6 multicast address as assigned by the IANA for VRRP is:
> 
>    FF02:0:0:0:0:0:XXXX:XXXX
> 
>    This is a link-local scope multicast address.  Routers MUST NOT
>    forward a datagram with this destination address regardless of its
>    Hop Limit.
> 
> 
> 
> So the address is not fixed? A master virtual router can send adv to
> any
> addr in this range, and a backup virtual router has to join all
> multicast groups within this range? This doesn't sounds quite clear to
> me.
> 
> Can someone explain a bit to me? Thanks.
> --
> Huafeng
> _______________________________________________
> vrrp mailing list
> vrrp <at> ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 4 comments |
headers
Huafeng Lu | 21 Aug 2008 05:25
Picon

Re: ipv6 multicast address

John Cruz (johcruz) wrote:
> Please see Section 13. The address to be used is FF02::12.

Thanks John. But this is only a "convenient assignment". Although I 
guess most implementation will just use ff02::12 for sending, it's 
possible that someone will send to ff02::13 or sth else.

So why a block of addresses (not a single address instead) was assigned 
for VRRP in the first place?

> 
> John
> 
> 13.  IANA Considerations
> 
>    VRRP for IPv6 needs an IPv6 link-local scope multicast address
>    assigned by the IANA for this specification.  The IPv6 multicast
>    address should be of the following form:
> 
>       FF02:0:0:0:0:0:XXXX:XXXX
> 
>    The values assigned address should be entered into section 5.1.2.2.
> 
>    A convenient assignment of this link-local scope multicast would be:
>       FF02:0:0:0:0:0:0:12
> 
> 
> 
>> -----Original Message-----
>> From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf
> Of
>> Huafeng Lu
>> Sent: Wednesday, August 20, 2008 2:26 AM
>> To: vrrp <at> ietf.org
>> Subject: [VRRP] ipv6 multicast address
>>
>>
>> Hi,
>>
>> The following is stated in the draft:
>>
>> 5.1.2.2.  Destination Address
>>
>>    The IPv6 multicast address as assigned by the IANA for VRRP is:
>>
>>    FF02:0:0:0:0:0:XXXX:XXXX
>>
>>    This is a link-local scope multicast address.  Routers MUST NOT
>>    forward a datagram with this destination address regardless of its
>>    Hop Limit.
>>
>>
>>
>> So the address is not fixed? A master virtual router can send adv to
>> any
>> addr in this range, and a backup virtual router has to join all
>> multicast groups within this range? This doesn't sounds quite clear to
>> me.
>>
>> Can someone explain a bit to me? Thanks.
>> --
>> Huafeng
>> _______________________________________________
>> vrrp mailing list
>> vrrp <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 3 comments |
headers
John Cruz (johcruz | 21 Aug 2008 06:39
Picon
Favicon

Re: ipv6 multicast address

Hi,

According to RFC 3307, a reserved multicast address should be of the
format FF02::<GROUPID-32bits>. This is what is indicated in the VRRP
draft. The Xs don't refer to a block.

Moreover, this statement is under the "IANA Considerations". It is for
IANA to assign this address. To the best of my knowledge, this will be
the
address assigned by IANA. But I don't know when it will be assigned
though.

Hope this helps.
John

> -----Original Message-----
> From: Huafeng.Lv <at> Sun.COM [mailto:Huafeng.Lv <at> Sun.COM]
> Sent: Wednesday, August 20, 2008 8:25 PM
> To: John Cruz (johcruz)
> Cc: vrrp <at> ietf.org
> Subject: Re: [VRRP] ipv6 multicast address
> 
> John Cruz (johcruz) wrote:
> > Please see Section 13. The address to be used is FF02::12.
> 
> Thanks John. But this is only a "convenient assignment". Although I
> guess most implementation will just use ff02::12 for sending, it's
> possible that someone will send to ff02::13 or sth else.
> 
> So why a block of addresses (not a single address instead) was
assigned
> for VRRP in the first place?
> 
> >
> > John
> >
> > 13.  IANA Considerations
> >
> >    VRRP for IPv6 needs an IPv6 link-local scope multicast address
> >    assigned by the IANA for this specification.  The IPv6 multicast
> >    address should be of the following form:
> >
> >       FF02:0:0:0:0:0:XXXX:XXXX
> >
> >    The values assigned address should be entered into section
> 5.1.2.2.
> >
> >    A convenient assignment of this link-local scope multicast would
> be:
> >       FF02:0:0:0:0:0:0:12
> >
> >
> >
> >> -----Original Message-----
> >> From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On
Behalf
> > Of
> >> Huafeng Lu
> >> Sent: Wednesday, August 20, 2008 2:26 AM
> >> To: vrrp <at> ietf.org
> >> Subject: [VRRP] ipv6 multicast address
> >>
> >>
> >> Hi,
> >>
> >> The following is stated in the draft:
> >>
> >> 5.1.2.2.  Destination Address
> >>
> >>    The IPv6 multicast address as assigned by the IANA for VRRP is:
> >>
> >>    FF02:0:0:0:0:0:XXXX:XXXX
> >>
> >>    This is a link-local scope multicast address.  Routers MUST NOT
> >>    forward a datagram with this destination address regardless of
> its
> >>    Hop Limit.
> >>
> >>
> >>
> >> So the address is not fixed? A master virtual router can send adv
to
> >> any
> >> addr in this range, and a backup virtual router has to join all
> >> multicast groups within this range? This doesn't sounds quite clear
> to
> >> me.
> >>
> >> Can someone explain a bit to me? Thanks.
> >> --
> >> Huafeng
> >> _______________________________________________
> >> vrrp mailing list
> >> vrrp <at> ietf.org
> >> https://www.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 2 comments |
headers
Huafeng Lu | 21 Aug 2008 06:44
Picon

Re: ipv6 multicast address

John Cruz (johcruz) ??:
> Hi,
> 
> According to RFC 3307, a reserved multicast address should be of the
> format FF02::<GROUPID-32bits>. This is what is indicated in the VRRP
> draft. The Xs don't refer to a block.
> 
> Moreover, this statement is under the "IANA Considerations". It is for
> IANA to assign this address. To the best of my knowledge, this will be
> the
> address assigned by IANA. But I don't know when it will be assigned
> though.
> 
> Hope this helps.

Yes that makes sense. Thanks for the explanation!

> John
> 
>> -----Original Message-----
>> From: Huafeng.Lv <at> Sun.COM [mailto:Huafeng.Lv <at> Sun.COM]
>> Sent: Wednesday, August 20, 2008 8:25 PM
>> To: John Cruz (johcruz)
>> Cc: vrrp <at> ietf.org
>> Subject: Re: [VRRP] ipv6 multicast address
>>
>> John Cruz (johcruz) wrote:
>>> Please see Section 13. The address to be used is FF02::12.
>> Thanks John. But this is only a "convenient assignment". Although I
>> guess most implementation will just use ff02::12 for sending, it's
>> possible that someone will send to ff02::13 or sth else.
>>
>> So why a block of addresses (not a single address instead) was
> assigned
>> for VRRP in the first place?
>>
>>> John
>>>
>>> 13.  IANA Considerations
>>>
>>>    VRRP for IPv6 needs an IPv6 link-local scope multicast address
>>>    assigned by the IANA for this specification.  The IPv6 multicast
>>>    address should be of the following form:
>>>
>>>       FF02:0:0:0:0:0:XXXX:XXXX
>>>
>>>    The values assigned address should be entered into section
>> 5.1.2.2.
>>>    A convenient assignment of this link-local scope multicast would
>> be:
>>>       FF02:0:0:0:0:0:0:12
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On
> Behalf
>>> Of
>>>> Huafeng Lu
>>>> Sent: Wednesday, August 20, 2008 2:26 AM
>>>> To: vrrp <at> ietf.org
>>>> Subject: [VRRP] ipv6 multicast address
>>>>
>>>>
>>>> Hi,
>>>>
>>>> The following is stated in the draft:
>>>>
>>>> 5.1.2.2.  Destination Address
>>>>
>>>>    The IPv6 multicast address as assigned by the IANA for VRRP is:
>>>>
>>>>    FF02:0:0:0:0:0:XXXX:XXXX
>>>>
>>>>    This is a link-local scope multicast address.  Routers MUST NOT
>>>>    forward a datagram with this destination address regardless of
>> its
>>>>    Hop Limit.
>>>>
>>>>
>>>>
>>>> So the address is not fixed? A master virtual router can send adv
> to
>>>> any
>>>> addr in this range, and a backup virtual router has to join all
>>>> multicast groups within this range? This doesn't sounds quite clear
>> to
>>>> me.
>>>>
>>>> Can someone explain a bit to me? Thanks.
>>>> --
>>>> Huafeng
>>>> _______________________________________________
>>>> vrrp mailing list
>>>> vrrp <at> ietf.org
>>>> https://www.ietf.org/mailman/listinfo/vrrp
> 

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Mukesh Gupta | 21 Aug 2008 09:45
Favicon

Re: ipv6 multicast address

The IANA assignments are done when the draft is published as an RFC.

John is right. The IANA will assign the address suggested in the draft.

Regards
Mukesh

-----Original Message-----
From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of
John Cruz (johcruz)
Sent: Wednesday, August 20, 2008 9:40 PM
To: Huafeng.Lv <at> Sun.COM
Cc: vrrp <at> ietf.org
Subject: Re: [VRRP] ipv6 multicast address

Hi,

According to RFC 3307, a reserved multicast address should be of the
format FF02::<GROUPID-32bits>. This is what is indicated in the VRRP
draft. The Xs don't refer to a block.

Moreover, this statement is under the "IANA Considerations". It is for
IANA to assign this address. To the best of my knowledge, this will be
the
address assigned by IANA. But I don't know when it will be assigned
though.

Hope this helps.
John

> -----Original Message-----
> From: Huafeng.Lv <at> Sun.COM [mailto:Huafeng.Lv <at> Sun.COM]
> Sent: Wednesday, August 20, 2008 8:25 PM
> To: John Cruz (johcruz)
> Cc: vrrp <at> ietf.org
> Subject: Re: [VRRP] ipv6 multicast address
> 
> John Cruz (johcruz) wrote:
> > Please see Section 13. The address to be used is FF02::12.
> 
> Thanks John. But this is only a "convenient assignment". Although I
> guess most implementation will just use ff02::12 for sending, it's
> possible that someone will send to ff02::13 or sth else.
> 
> So why a block of addresses (not a single address instead) was
assigned
> for VRRP in the first place?
> 
> >
> > John
> >
> > 13.  IANA Considerations
> >
> >    VRRP for IPv6 needs an IPv6 link-local scope multicast address
> >    assigned by the IANA for this specification.  The IPv6 multicast
> >    address should be of the following form:
> >
> >       FF02:0:0:0:0:0:XXXX:XXXX
> >
> >    The values assigned address should be entered into section
> 5.1.2.2.
> >
> >    A convenient assignment of this link-local scope multicast would
> be:
> >       FF02:0:0:0:0:0:0:12
> >
> >
> >
> >> -----Original Message-----
> >> From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On
Behalf
> > Of
> >> Huafeng Lu
> >> Sent: Wednesday, August 20, 2008 2:26 AM
> >> To: vrrp <at> ietf.org
> >> Subject: [VRRP] ipv6 multicast address
> >>
> >>
> >> Hi,
> >>
> >> The following is stated in the draft:
> >>
> >> 5.1.2.2.  Destination Address
> >>
> >>    The IPv6 multicast address as assigned by the IANA for VRRP is:
> >>
> >>    FF02:0:0:0:0:0:XXXX:XXXX
> >>
> >>    This is a link-local scope multicast address.  Routers MUST NOT
> >>    forward a datagram with this destination address regardless of
> its
> >>    Hop Limit.
> >>
> >>
> >>
> >> So the address is not fixed? A master virtual router can send adv
to
> >> any
> >> addr in this range, and a backup virtual router has to join all
> >> multicast groups within this range? This doesn't sounds quite clear
> to
> >> me.
> >>
> >> Can someone explain a bit to me? Thanks.
> >> --
> >> Huafeng
> >> _______________________________________________
> >> vrrp mailing list
> >> vrrp <at> ietf.org
> >> https://www.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Don Provan | 21 Aug 2008 01:48
Favicon

Re: Potential Forwarding Loop

By "accept", 6.4.3 is speaking of receiving the packets into
its IP layer for IP receive handling. The point in this section
is that the master should not pretend to actually *be* the node
with the VR's IP address other than to answer ARPs for it.
(Unless, of course, it *is* the VR IP address's owner.)

This has nothing to do with accepting the packets into
the system to begin with and considering them for forwarding,
although I suppose I can see why you didn't find that clear.
But you can read these two sections as saying, "do not accept
packets addressed to VR addresses you do not own either for
local reception or for forwarding." The thought processes that
led to the two observations don't really intersect, so I think
that's why they two issues are raised separately and without
any relation even though, as you're pointing out, they're
really two parts of the same concept: ignore packets addressed
to a VR IP address you don't own.

I hope that clears things up, because I'm going to ignore your
question about the forwarding loop: it's a somewhat obscure
point, anyway, and it is sufficient to understand that forwarding
the VR IP address owner's packets is a bad idea. Is there some
reason you want to do it, anyway, or are your just interested
in the clarification?
-don

> -----Original Message-----
> From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org]On Behalf Of
> Chiu Hsia Peng
> Sent: Wednesday, August 20, 2008 5:33 AM
> To: vrrp <at> ietf.org
> Subject: [VRRP] Potential Forwarding Loop
> 
> 
> Hi,
> The following is stated in the RFC 3768.
> 
> 8.4.  Potential Forwarding Loop
> 
>    A VRRP router SHOULD not forward packets addressed to the IP
> Address(es) it becomes Master for if it is not the owner.  Forwarding
> these packets would result in unnecessary traffic.  Also in the case
>    of LANs that receive packets they transmit (e.g., token ring) this
>  can result in a forwarding loop that is only terminated when the IP
> TTL expires.
> 
> ...
> I am confused about the above description. Since 6.4.3 already
> describe: A master, .. MUST NOT accept packets addressed to the IP
> address(es) associated with the virtual router if it is not the IP
> address owner. I think if a VRRP router doesn't accept a packet, it
> can be implied that the router doesn't forward it either.
> 
> What's the purpose of this section?
> Could someone give me a concrete example about the potential 
> forwarding loop?
> 
>  Thanks.
> _______________________________________________
> vrrp mailing list
> vrrp <at> ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |

Gmane