Subject: RE: [pim] What's the definition of "quick turnaround"?

From: "Amit Shukla" <[email-masked]>
Date: Mon, 15 Aug 2005 10:43:30 -0700

Hi Dino,

Regarding scaling issue, please see my response below.

>    And what are the scaling issues? Is this a different point then in
3)?
>    Are you saying for every external source, the RP/MSDP router will
have
>    to send to all other RPs? There is a section in the spec that says
this:
>-----
>  For learning sources external to a domain, the MSDP SA messages could
>   arrive at multiple MSDP-peering Anycast-RPs. The rules for
processing
>   an SA, according to [I1], should be followed. That is, if G is
joined
>   in the domain, an (S,G) join is sent towards the source. And if data
>   accompanies the SA, each Anycast-PIM RP doing MSDP peering will
>   forward the data down each of their respective shared-trees.

>   The above assumes each Anycast-RP has external MSDP peering
>   connections.  If this is not the case, the Anycast-PIM routers with
>   the MSDP peering connections would follow the same procedure as if a
>   Data-Register or Null-Register was received from either a DR or
>   another Anycast-RP. That is, they would send Registers to the other
>   members of the Anycast-RP set.
>-----

>    So if each anycast-RP is configured to know all other RPs have
external
>    MSDP peering sessions, then the external source information won't
need
>    to be propagated from ingress RP to all others.

>    So, if I guessed wrong on your issue, can you please state it more
clearly?

Yes, if all the anycast-RP set router's have external MSDP peeing 
connection then there may not be any scaling issue assuming that 
single PIM-SM domain active source information is limited.

Let's take a different scenario, where anycast-RP set consist of
multiple
routers and only one of them has external MSDP peering connection. 
This ingress RP with external MSDP peering connection has to generate 
Registers to other members of the Anycast-RP set. It's also responsible 
for generating periodic NULL register messages for every active source 
it learned from MSDP to keep the source state alive on Anycast-RP set 
members. Depending upon how much of external active source information 
is learned, this ingress RP will soon be generating thousands of
periodic 
NULL-register messages to other RP's, which could have been done more 
efficiently if there was a way to pack multiple sources information in 
single Register message. But looks like register message format has been

designed with assumption that DR will not have so many active sources
but 
the way anycast-RP uses Register message that assumption may not be true

anymore. If register message format is big change and it can't be made 
then at least we should mention this scaling issue in spec.
 
Thanks
Amit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Dino Farinacci
Sent: Friday, August 12, 2005 6:19 PM
To: Tom Pusateri
Cc: Tom Pusateri; [email-masked]
Subject: Re: [pim] What's the definition of "quick turnaround"?

>> 1.  If spec allows RP's to do register-stop caching then there's no
>>     reason for other anycast RP peer's to suppress register stop.
>>     So either spec should make the suppression knob mandatory or
>>     remove the register-stop caching functionality. Dino has
mentioned
>>     that nobody is implementing register-stop caching.
>> 
>>     [ We found that it is not possible to implement based on the
>>     information in the current spec. There are many cases that are
>>     under specified.  We don't care if it is fully specified or
>>     removed but it can't stay like it is. We have pointed out in
>>     previous emails some of the ways that it is under specified.
>>     We came up with some solutions too but in the end, we couldn't
>>     make it work as long as some peers were suppressing register
>>     stops. - Tom ]

    Okay, we will pull register-caching out of the spec. There were no
apparent
    huge objections to this.

>> 2.  I've always thought that it would be neat to have a bit in
>>     Register message to know if the register message is coming from
>>     Anycast-RP peer or DR. This could simplify the debugging as
>>     well as catching any mis-configuration errors easily without
>>     relying on TTL field to expire.

    I commented to Amit that I didn't want to change packet formats if
we
    didn't have to. Plus this change would require a rev to the base
spec
    which I hope we all want to avoid. Hence, I didn't include it in the
    design.

>> 3.  Another thing which i wanted to discuss with you was in current
>>     form Anycast RP solution is not going to scale very well. Reason
>>     is that for each active source learned from DR/Direct/MSDP
>>     anycast RP replicate/generate a single NULL-register message
>>     to each anycast-RP peer. Why can't we change the NULL-register
>>     message format so that multiple <s,g>'s can be packed in a
>>     single message?
>> 
>>     Before Anycast RP came, this scaling issue wasn't there as DR
>>     sends these NULL-register messages and for each DR there may
>>     not be too many sources. But with Anycast-RP if you are
advertising
>>     MSDP learned external sources as well as internal source
>>     information then soon we'll be generating tons and tons of these
>>     NULL-register messages periodically, which can be easily packed
>>     in single message.

    I could add more language indicating Null-Registers are really not
    required to be forwarded by an RP to other RPs in the Anycast-RP
set.
    The state will be kept alive in those RPs via Data-Registers which
are
    periodically sent.

    It is admirable to want to do this, but I think it's too big a
change to
    PIMv2 and hence the spec progression issue as well.

>> 4.  The spec should mention the scaling issues when MSDP learned
>>     sources are adverstised using Anycast RP.

    And what are the scaling issues? Is this a different point then in
3)?
    Are you saying for every external source, the RP/MSDP router will
have
    to send to all other RPs? There is a section in the spec that says
this:

-----
   For learning sources external to a domain, the MSDP SA messages could
   arrive at multiple MSDP-peering Anycast-RPs. The rules for processing
   an SA, according to [I1], should be followed. That is, if G is joined
   in the domain, an (S,G) join is sent towards the source. And if data
   accompanies the SA, each Anycast-PIM RP doing MSDP peering will
   forward the data down each of their respective shared-trees.

   The above assumes each Anycast-RP has external MSDP peering
   connections.  If this is not the case, the Anycast-PIM routers with
   the MSDP peering connections would follow the same procedure as if a
   Data-Register or Null-Register was received from either a DR or
   another Anycast-RP. That is, they would send Registers to the other
   members of the Anycast-RP set.
-----

    So if each anycast-RP is configured to know all other RPs have
external
    MSDP peering sessions, then the external source information won't
need
    to be propagated from ingress RP to all others.

    So, if I guessed wrong on your issue, can you please state it more
clearly?

    Once I get concensus on this reply, I will cut a new rev of the
draft,
    publish it early next week to this list and maybe we can close on a
-04 
    by Friday.

    Does everyone think we can make this deadline? And Bill/Alex, can we
get
    this pushed through quickly?

Dino

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 15 Aug 2005 17:57:11 -0700

>> Amit

    How about I add the following text to this paragraph:

-----

-----

    New paragraph added:

-----

   The amount of Register traffic generated by this MSDP-peering RP would
   be equal to the number of active sources external to the domain. The 
   Source-Active state would have to be conveyed to all other RPs in the
   Anycast-RP set since the MSDP-peering RP would not know about the
   group membership associated with the other RPs. To avoid this periodic
   control traffic, it is recommended that all Anycast-RPs be configured
   with external MSDP peering sessions so no RP in the Anycast-RP set will
   have to originate Register messages on behalf of external sources.

-----

   So are we cool after we:

   o Add the above text and
   o Remove references to Register-Stop caching

   Please respond. Thanks.

Dino