Nikhil Ninan | 3 Apr 12:25 2006
Picon
Picon

PIM Join/Prune Messages

Hello there,
                Could someone tell me how does PIM combine group 
information, i.e. no. of joins and no. of prunes, on a group by group 
basis onto a single Join/Prune message.
Cheers
Nikhil
David McWalter | 3 Apr 12:39 2006

RE: PIM Join/Prune Messages

Hello again Nikhil.

The message format below is from the PIM spec.
http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-12.txt

If your question is about logic rather than message format, then you'll need to clarify it.

DMcW.

4.9.5.  Join/Prune Message Format
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |   Reserved    |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Upstream Neighbor Address (Encoded-Unicast format)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Reserved     | Num groups    |          Holdtime             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Multicast Group Address 1 (Encoded-Group format)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Number of Joined Sources    |   Number of Pruned Sources    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Joined Source Address 1 (Encoded-Source format)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             .                                 |
|                             .                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Joined Source Address n (Encoded-Source format)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Continue reading)

Nikhil Ninan | 3 Apr 12:49 2006
Picon
Picon

Re: PIM Join/Prune Messages

David McWalter wrote:
> Hello again Nikhil.
>
> The message format below is from the PIM spec.
> http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-12.txt
>
> If your question is about logic rather than message format, then you'll need to clarify it.
>
> DMcW.
>
> 4.9.5.  Join/Prune Message Format
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |PIM Ver| Type  |   Reserved    |           Checksum            |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |        Upstream Neighbor Address (Encoded-Unicast format)     |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  Reserved     | Num groups    |          Holdtime             |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |         Multicast Group Address 1 (Encoded-Group format)      |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |   Number of Joined Sources    |   Number of Pruned Sources    |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |        Joined Source Address 1 (Encoded-Source format)        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                             .                                 |
> |                             .                                 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |        Joined Source Address n (Encoded-Source format)        |
(Continue reading)

Christopher Thomas Brown | 3 Apr 18:10 2006

Re: PIM Join/Prune Messages

Nikhil Ninan wrote:
> >-----Original Message-----
> >From: Nikhil Ninan [mailto:nikhil <at> erg.abdn.ac.uk]
> >Sent: 03 April 2006 11:25
> >To: pim <at> ietf.org
> >Subject: [pim] PIM Join/Prune Messages
> >
> >
> >Hello there,
> >                Could someone tell me how does PIM combine group 
> >information, i.e. no. of joins and no. of prunes, on a group by group 
> >basis onto a single Join/Prune message.
> >Cheers
> >Nikhil
> >
> >_______________________________________________
> >pim mailing list
> >pim <at> ietf.org
> >https://www1.ietf.org/mailman/listinfo/pim
> >
> >
> >
> >  
> my question is about the logic not the format :-)
> Cheers
> Nikhil

The only logic that the PIM-SM specification requires is that (S,G,rpt)
prunes for a given group must be contained in the same message as the
(*,G) join for that group. The spec also says which prunes to include if
(Continue reading)

Dino Farinacci | 3 Apr 19:23 2006
Picon

Re: BSR update

>> Slide 6, Unicast BSMs
>> 
>> New revision says that they must be sent from the primary address,
>> and also only accepts them from the primary. I believe Dino said this
>> was problematic. But I must say now that I'm not sure why. Could you
>> clarify Dino? Or anyone else?

    The problem with unicast BSMs, as sent by the DR on a LAN when a new
    neighbor comes up, is if the ARP cache is not primed with the new 
    neighbor, then the BSM is *typically* dropped by the local system (when
    the ARP implementation does not queue packets). 

    Since the PIM neighbor adjacency and the unicast routing protocol adjacency
    are coming up at the same time, it is typically a race on which one sends 
    the first unicast packet to the newly booted router. And since there is 
    less chit-chat in PIM for bringing up an adjacency (versus OSPF or, IS-IS 
    which never sends a unicast packet), it's the BSM that triggers the ARP
    request.

    So I am questioning the probablistic usefulness of unicast BSMs. I think
    a simple solution is to link-local multicast them. But the new neighbor
    needs to not RPF-check these. So either:

    o The new neighbor accepts all BSMs within a short-time of discovering
      the DR, or

    o Set a bit in the BSM to unconditionally accept (and not forward) the
      BSM. This would be useful from another repsect in that the new neighbor
      wouldn't have to determine if the DR is sending it. Especially, in the
      case where the new neighbor is just becoming the DR.
(Continue reading)

Venu Hemige | 5 Apr 23:01 2006
Picon

RE: BSR update


Stig, 

Please see comments inline.

> 
> Slide 5, BSM Forwarding
> 
> New revision says that routers in C-BSRs state must forward
> non-preferred BSMs from elected BSR. The reasons for this are
> clear, and I believe everyone agrees.
> 
> New revision also says that P-BSRs should forward non-preferred BSMs.
> This is not so clear, but there are some advantages, and no real
> negative impacts.
>

There is benefit in doing this. I think we should keep it.

In addition, I think it would be useful to make the following changes to
BSM forwarding:

In Accept-Preferred state, if we receive a non-preferred BSM from E-BSR,
then we should perform the same actions as we would if a preferred BSM
was received. The important thing is that the BSM should be forwarded so
that other routers (some of which may be C-BSRs) also note that the
current E-BSR may no longer be E-BSR.

Regards,
-Venu
(Continue reading)

Stig Venaas | 9 Apr 15:42 2006
Picon
Picon

Re: BSR update

Dino Farinacci wrote:
>>> Slide 6, Unicast BSMs
>>>
>>> New revision says that they must be sent from the primary address,
>>> and also only accepts them from the primary. I believe Dino said this
>>> was problematic. But I must say now that I'm not sure why. Could you
>>> clarify Dino? Or anyone else?
> 
>     The problem with unicast BSMs, as sent by the DR on a LAN when a new
>     neighbor comes up, is if the ARP cache is not primed with the new 
>     neighbor, then the BSM is *typically* dropped by the local system (when
>     the ARP implementation does not queue packets). 
> 
>     Since the PIM neighbor adjacency and the unicast routing protocol adjacency
>     are coming up at the same time, it is typically a race on which one sends 
>     the first unicast packet to the newly booted router. And since there is 
>     less chit-chat in PIM for bringing up an adjacency (versus OSPF or, IS-IS 
>     which never sends a unicast packet), it's the BSM that triggers the ARP
>     request.
> 
>     So I am questioning the probablistic usefulness of unicast BSMs. I think
>     a simple solution is to link-local multicast them. But the new neighbor
>     needs to not RPF-check these. So either:
> 
>     o The new neighbor accepts all BSMs within a short-time of discovering
>       the DR, or
> 
>     o Set a bit in the BSM to unconditionally accept (and not forward) the
>       BSM. This would be useful from another repsect in that the new neighbor
>       wouldn't have to determine if the DR is sending it. Especially, in the
(Continue reading)

Stig Venaas | 9 Apr 16:48 2006
Picon
Picon

Re: BSR update

Venu Hemige wrote:
> Stig, 
> 
> Please see comments inline.
> 
>> Slide 5, BSM Forwarding
>>
>> New revision says that routers in C-BSRs state must forward
>> non-preferred BSMs from elected BSR. The reasons for this are
>> clear, and I believe everyone agrees.
>>
>> New revision also says that P-BSRs should forward non-preferred BSMs.
>> This is not so clear, but there are some advantages, and no real
>> negative impacts.
>>
> 
> There is benefit in doing this. I think we should keep it.
> 
> In addition, I think it would be useful to make the following changes to
> BSM forwarding:
> 
> In Accept-Preferred state, if we receive a non-preferred BSM from E-BSR,
> then we should perform the same actions as we would if a preferred BSM
> was received. The important thing is that the BSM should be forwarded so
> that other routers (some of which may be C-BSRs) also note that the
> current E-BSR may no longer be E-BSR.

I agree. I didn't mention this, but this was fixed in the previous 
revision. What we did was to add a paragraph to the description of the 
receive preferred event. It reads as follows:
(Continue reading)

Venu Hemige | 10 Apr 01:20 2006
Picon

RE: BSR update


Stig,

I see it now. But it is a little less intuitive. I think defining an
"Acceptable BSM from Elected BSR" and adding a specific FSM event into
the state machine would have been better. It goes well with the language
used in the draft (like Non-Preferred BSM from Elected BSR).

Regards,
-Venu

> -----Original Message-----
> From: Stig Venaas [mailto:stig.venaas <at> uninett.no]
> Sent: Sunday, April 09, 2006 7:48 AM
> To: venu.hemige <at> alcatel.com
> Cc: pim <at> ietf.org
> Subject: Re: [pim] BSR update
> 
> Venu Hemige wrote:
> > Stig,
> >
> > Please see comments inline.
> >
> >> Slide 5, BSM Forwarding
> >>
> >> New revision says that routers in C-BSRs state must forward
> >> non-preferred BSMs from elected BSR. The reasons for this are
> >> clear, and I believe everyone agrees.
> >>
> >> New revision also says that P-BSRs should forward non-preferred
(Continue reading)

Christopher Thomas Brown | 10 Apr 19:05 2006

Re: BSR update

Stig Venaas wrote:
> I would like to not change the draft more than necessary, but I must say 
> I like the idea of getting rid of unicast BSMs if possible.
> 
> I prefer your first alternative, i.e., not adding a new flag. However, I 
> would also like to avoid the complexity of finding out whether the BSM 
> came from the DR (the DR in this new routers absence). What about 
> skipping that check? Currently there is no check that the unicasted BSM 
> came from the DR either. However, the unicasted BSM is supposed to be 
> sent by the DR, so we should still say that this triggered multicasted 
> BSM is to be sent by the DR.
> 
> Do you see any problems with just saying that for a short time after 
> startup, the RPF check is not required?

I think it couldn't be required.  If the router is restarting it likely
doesn't have an MRIB with which to do an RPF check.

> Then there is the issue of forwarding. We could perhaps say that RPF 
> should still be performed. I wonder if it would be safe enough to just 
> forward it and have the neighbours perform RPF.
> 
> So, to conclude, how about saying that if no previous BSM has been 
> accepted (for the particular scope zone) and less than BS_Period has 
> elapsed since startup, then the RPF check should be skipped.
> 
> I believe this would greatly simplify the implementation (no unicast 
> BSMs, just a minor special case at startup). There is significant 
> complexity in securing unicast BSMs (e.g. Router Alerts or use of ttl 
> 255, verifying ttls and backwards compatibility) that would simply go away.
(Continue reading)


Gmane