headers
Mike McBride (mmcbride | 4 Apr 2011 21:53
Picon
Favicon

Prague wg meeting minutes

Please review and offer corrections/additions where necessary before we
post. Thanks to Greg Shepherd for the notes:

PIM WG Minutes
Prague, March 28th, 2011

Mike McBride
Recharter Proposals
 -errata: "There is a significant number of errata that need to be
addressed in order to advance RFC4601 to Draft Standard. The PIM WG will
correct the errata, as necessary, and then update RFC4601."
 -igmp: "The working group primarily works on extensions to PIM, but may
take on work related to IGMP/MLD."
 -No opposition in the room. Alias is next.

Jeffrey Zhang
4601 Revision
Address about 100 open errata
 -Three volunteers from cisco/huawei/juniper
 -00 draft in 2-3 weeks with all verified errata corrected
 -identify optional features that do not meet 2026 req's.
  -*,*,RP
  -explicit tracking
  -group to rp mappings (refer to pim-group-rp-mapping)
 -01 draft with optional features removed before July ietf
 -feedback please

Stig Venaas
pim-port-06 update
Good feedback on the list after wglc#2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stig Venaas | 6 Apr 2011 22:10

Re: Comments on draft-gulrajani-pim-hello-intid-00.txt

On 3/29/2011 5:35 AM, G. Fairhurst wrote:
>
> i promised to read this and comment on the list.

Thanks, I've made some changes now. I'll submit it
shortly as 01 unless you have any further comments.
>
> This looks like a useful thing to publish as a PS.
>
> I have a few comments:
>
> S 2.2
> " it needs to be
> unique depends on the protocol utilizing it."
> - wording, is this better:
> "The requirements for the scope in which it needs to be unique depend o
> the protocol that utilises this."
> - Actually this is the one point that I do not yet see. It seems that
> without a default level of scope, there is no clear way that different
> protocols can reliably use the same mechanism. Is it possible just to
> say that the router should use an IPv4 unicast address assigned to the
> router by default (preferably a public address if one is defined). There
> is no problem allowing an operator to reassign the value, and it then
> becomes a matter of correct implementation.

I did some changes, but kept most of the old text. It now says:

    The 32 bit Router Identifier may be used to uniquely identify
    the router.  It may be selected to be unique within some
    administrative domain, or possibly globally unique.  The
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Morin | 7 Apr 2011 12:05

PIM Pop Count - Allow more than 16 options ?

Hi working group, Greg, Dino,

Wouldn't it be a good idea to arrange for the possibility of having more 
than 16 options?

A possibility would be to give a special role to the last bit of the 
option bitmap: if set, it would mean that the next two bytes after the 
option bitmap would also carry an option bitmap (a second one for 15 
additional options), and the first option would start after this second 
option bitmap. And if the last bit of this second bitmap was set, then 
there would be yet another option bitmap...

Another possibility would be a TLV encoding for all the options...

Comments ?

-Thomas

PS: by the way, "options" here is not a great name, what about "fields" 
or "metrics"...?
Permalink | Reply | 5 comments |
headers
Jeffrey (Zhaohui) Zhang | 7 Apr 2011 12:25
Favicon

Re: PIM Pop Count - Allow more than 16 options ?

It might be easier to find the start of the first option if we have a length field to indicate how large the
bitmap is, instead of relying on the last bit of each extension of the bit map?

That length field could be the first option itself.

Jeffrey

> -----Original Message-----
> From: pim-bounces <at> ietf.org [mailto:pim-bounces <at> ietf.org] On 
> Behalf Of Thomas Morin
> Sent: Thursday, April 07, 2011 11:06 AM
> To: pim <at> ietf.org; Greg Shepherd; dino <at> cisco.com
> Subject: [pim] PIM Pop Count - Allow more than 16 options ?
> 
> Hi working group, Greg, Dino,
> 
> Wouldn't it be a good idea to arrange for the possibility of 
> having more 
> than 16 options?
> 
> A possibility would be to give a special role to the last bit of the 
> option bitmap: if set, it would mean that the next two bytes 
> after the 
> option bitmap would also carry an option bitmap (a second one for 15 
> additional options), and the first option would start after 
> this second 
> option bitmap. And if the last bit of this second bitmap was 
> set, then 
> there would be yet another option bitmap...
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeffrey (Zhaohui) Zhang | 7 Apr 2011 14:30
Favicon

Re: PIM Pop Count - Allow more than 16 options ?

> That length field could be the first option itself.

To clarify, I meant the length/size of the extended bitmap (that is separated from the standard one), and it
shoud come after (vs. before)  all the standard options. And for that reason, it might be better for it to be
the last standard option.

Jeffrey

> -----Original Message-----
> From: pim-bounces <at> ietf.org [mailto:pim-bounces <at> ietf.org] On 
> Behalf Of Jeffrey (Zhaohui) Zhang
> Sent: Thursday, April 07, 2011 11:25 AM
> To: Thomas Morin; pim <at> ietf.org; Greg Shepherd; dino <at> cisco.com
> Subject: Re: [pim] PIM Pop Count - Allow more than 16 options ?
> 
> It might be easier to find the start of the first option if 
> we have a length field to indicate how large the bitmap is, 
> instead of relying on the last bit of each extension of the bit map?
> 
> That length field could be the first option itself.
> 
> Jeffrey
> 
> > -----Original Message-----
> > From: pim-bounces <at> ietf.org [mailto:pim-bounces <at> ietf.org] On 
> > Behalf Of Thomas Morin
> > Sent: Thursday, April 07, 2011 11:06 AM
> > To: pim <at> ietf.org; Greg Shepherd; dino <at> cisco.com
> > Subject: [pim] PIM Pop Count - Allow more than 16 options ?
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 7 Apr 2011 09:29
Picon
Picon

Re: Comments on draft-gulrajani-pim-hello-intid-00.txt

A few comments in line.

On 06/04/2011 21:06, Stig Venaas wrote:
> On 3/29/2011 5:35 AM, G. Fairhurst wrote:
>>
>> i promised to read this and comment on the list.
>
> Thanks, I've made some changes now. I'll submit it
> shortly as 01 unless you have any further comments.
>
>> This looks like a useful thing to publish as a PS.
>>
>> I have a few comments:
>>
>> S 2.2
>> " it needs to be
>> unique depends on the protocol utilizing it."
>> - wording, is this better:
>> "The requirements for the scope in which it needs to be unique depend o
>> the protocol that utilises this."
>> - Actually this is the one point that I do not yet see. It seems that
>> without a default level of scope, there is no clear way that different
>> protocols can reliably use the same mechanism. Is it possible just to
>> say that the router should use an IPv4 unicast address assigned to the
>> router by default (preferably a public address if one is defined). There
>> is no problem allowing an operator to reassign the value, and it then
>> becomes a matter of correct implementation.
>
> I did some changes, but kept most of the old text. It now says:
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stig Venaas | 7 Apr 2011 19:02

Re: PIM Pop Count - Allow more than 16 options ?

Hi Thomas

On 4/7/2011 3:05 AM, Thomas Morin wrote:
> Hi working group, Greg, Dino,
>
> Wouldn't it be a good idea to arrange for the possibility of having more
> than 16 options?
>
> A possibility would be to give a special role to the last bit of the
> option bitmap: if set, it would mean that the next two bytes after the
> option bitmap would also carry an option bitmap (a second one for 15
> additional options), and the first option would start after this second
> option bitmap. And if the last bit of this second bitmap was set, then
> there would be yet another option bitmap...

I have thought of this, and I think my idea is similar to yours. If we
start running out, we define the last option (option 16) to be a
bitmap option. At that time, we can define how big we want it, e.g.
2 bytes. Those 2 bytes would then be a bitmap showing which options
follow. Following the current rules, that bitmap would then come
after the currently known options in the packet.

If we again run out, the last option in that bitmap can be a new bitmap
option as well. But I don't think we should worry about this in the
current draft. As long as we know we have a way to do it. Does this
sound reasonable?

>
> Another possibility would be a TLV encoding for all the options...
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stig Venaas | 7 Apr 2011 19:25

Re: Comments on draft-gulrajani-pim-hello-intid-00.txt

Thanks, see below.

On 4/7/2011 12:29 AM, Gorry Fairhurst wrote:
> A few comments in line.
>
> On 06/04/2011 21:06, Stig Venaas wrote:
>> On 3/29/2011 5:35 AM, G. Fairhurst wrote:
>>>
>>> i promised to read this and comment on the list.
>>
>> Thanks, I've made some changes now. I'll submit it
>> shortly as 01 unless you have any further comments.
>>
>>> This looks like a useful thing to publish as a PS.
>>>
>>> I have a few comments:
>>>
>>> S 2.2
>>> " it needs to be
>>> unique depends on the protocol utilizing it."
>>> - wording, is this better:
>>> "The requirements for the scope in which it needs to be unique depend o
>>> the protocol that utilises this."
>>> - Actually this is the one point that I do not yet see. It seems that
>>> without a default level of scope, there is no clear way that different
>>> protocols can reliably use the same mechanism. Is it possible just to
>>> say that the router should use an IPv4 unicast address assigned to the
>>> router by default (preferably a public address if one is defined). There
>>> is no problem allowing an operator to reassign the value, and it then
>>> becomes a matter of correct implementation.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stig Venaas | 7 Apr 2011 21:05

Re: Comments on draft-gulrajani-pim-hello-intid-00.txt

On 4/7/2011 11:45 AM, Gorry Fairhurst wrote:
> Looks good Stig!

Thanks, I've now submitted version 01 based on your comments,
and the comments from the pim wg meeting. I hope this version
can be considered for adoption by the wg then.

Stig

> Gorry
Permalink | Reply | 0 comments |
headers
Thomas Morin | 8 Apr 2011 09:34

Re: PIM Pop Count - Allow more than 16 options ?

Hi Stig,

Stig Venaas:
>
> On 4/7/2011 3:05 AM, Thomas Morin wrote:
>> Hi working group, Greg, Dino,
>>
>> Wouldn't it be a good idea to arrange for the possibility of having more
>> than 16 options?
>>
>> A possibility would be to give a special role to the last bit of the
>> option bitmap: if set, it would mean that the next two bytes after the
>> option bitmap would also carry an option bitmap (a second one for 15
>> additional options), and the first option would start after this second
>> option bitmap. And if the last bit of this second bitmap was set, then
>> there would be yet another option bitmap...
>
> I have thought of this, and I think my idea is similar to yours. If we
> start running out, we define the last option (option 16) to be a
> bitmap option. At that time, we can define how big we want it, e.g.
> 2 bytes. Those 2 bytes would then be a bitmap showing which options
> follow. Following the current rules, that bitmap would then come
> after the currently known options in the packet.
>
> If we again run out, the last option in that bitmap can be a new bitmap
> option as well.

Yes, this is good (also quite close to what Jeffrey suggested).

> But I don't think we should worry about this in the
(Continue reading)

Permalink | Reply | 1 comment |

Gmane