Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng(part 3)

From: saeed sami <[email-masked]>
Date: Wed, 30 Apr 2014 02:51:58 +0330

Dear Mr.Venaas,
Hello
First of all let me thank you for your review, comments and the time you
have
dedicated to review my work "draft-sami-pim-ng-02".

http://tools.ietf.org/html/draft-sami-pim-ng-02

Since answering to your questions will be a little lengthy and can't be
posted to PIM mailing list as a single email, I have to answer in separate
parts. and this is part 3 of the series.

Please kindly find the answers and explanations to your questions and
doubts bellow. i hope that as you mentioned in your email there will be
more comments from other members after this.

*3- Will there be a 30 second delay between the time a source becomes
active and a last hop learns about it? : *
- since as soon as a source becomes active and the register message is sent
to RP the information related to it is saved in MMT or AMMT by the RP, as
soon as a client (last hop) comes up with the need to find the source , it
will only need to ask the RP. There will be no delay in finding the source.

- since after receiving the address of the source there won't be any join
to RPT rooted at the RP and the client (last hop) will immediately join the
SPT for (G) using the unicast address of the source received from the RP,
there won't be any delays and PIM-NG will be one cycle a head of PIM-SM
since there is no switching from RPT to SPT.

- The above being explained there won't be any delay.

- Also because in PIM-NG neighbor routers inform each other about the
groups

they are join the SPT for, if a neighboring PIM-NG router comes up later
with the need to find (S) for the same (G) a neighbor is joined the SPT
for, there won't be the need to send a request to RP and instead the client
will send its join to its neighbor.

End of part 3.

On Fri, Apr 25, 2014 at 10:32 PM, <[email-masked]> wrote:

> Send pim mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/pim
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of pim digest..."
>
>
> Today's Topics:
>
>    1. Re: New updated and edited version of draft-sami-pim-ng
>       (Stig Venaas)
>    2. Re: New updated and edited version of draft-sami-pim-ng
>       (saeed sami)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 24 Apr 2014 14:24:56 -0700
> From: Stig Venaas <[email-masked]>
> To: saeed sami <[email-masked]>, pim <[email-masked]>
> Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi
>
> I have some comments on your draft. I've been hoping that others in the
> working group would also comment on this. Maybe with my comments here we
> can start a discussion and hopefully also get others in the working
> group to take part.
>
> On 4/10/2014 3:55 PM, saeed sami wrote:
> > A new version of draft-sami-pim-ng is submitted and can be reached at :
> > http://www.ietf.org/internet-drafts/draft-sami-pim-ng-02.txt
> >
> > It is edited and some parts and sections are updated.
> >
> > Your reviews and comments are most appreciated. and I hope to read the
> > comments of PIM working group experts soon.
> >
> > Abstract:
> >     This document specifies protocol independent multicast- Next
> >     generation or simply called PIM-NG. like PIM-SM, PIM-NG uses the
> >     underlying unicast routing information, but unlike PIM-SM it doesn't
> >     necessarily need to build unidirectional shared trees rooted at a
> >     Rendezvous Point (RP) per group, due to the fact that the processes
> >     through which a source registers with the Rendezvous Point and a host
> >     finds the source of the multicast destination groups it needs are
> >     done in a whole new way. So at some points PIM-NG works faster than
> >     its predecessor. Also the new Domain concept, unique to PIM-NG, along
> >     the RPF check method used in PIM-NG specifications provides many
> >     features along a robust and flexible control and administration over
> >     multicast networks.
>
> I see you have put a lot of work into this. There are a lot of concepts
> defined, new message types etc. but I think the main difference from
> PIM-SM that I want to focus on is the source discovery part (including
> the behavior of RPs). I have not read about the domain concept in detail
> yet. I think parts of what you are proposing could be achieved without
> necessarily having a completely new PIM protocol.
>
> Both in PIM-SM and in your proposal the RPs have knowledge of active
> sources. How the RPs learn about the sources are not very different.
>
> You propose a register message to be sent when the source becomes
> active. It does not contain a data packet. With PIM-SM you could also
> do this by sending a Null register. You also have periodic messages
> for keeping this state alive, which is not really different from
> sending periodic Null registers.
>
> Your approach and the Null register approach work well except for one
> issue. Initial data packets from a source would be dropped. This is a
> concern for some applications. For many applications I think it is
> acceptable though.
>
> Now, what is very different in PIM-SM and your proposal is how the
> last hop routers learn about active sources.
>
> With your proposal my understanding is that a last hop router sends a
> unicast query for sources to the RP to ask for active sources. Then you
> have the last hop router send periodic queries every 30 seconds in case
> there are new sources?
>
> One issue I see here is scaling when there are a large number of last
> hop routers. The more significant issue is I think that it may take up
> to 30 seconds from a source starts sending until a last hop router
> learns that the source is active. Is that correct? That is in my opinion
> unacceptable for many applications. This could be improved if the RP
> stores state, remembering that certain routers should be notified if a
> new source becomes active. This could be a problem if there are a large
> number of last hop routers though.
>
> I can understand that it is nice to avoid data registers and shared
> trees, but it has some impact on applications.
>
> I would like to hear your thoughts on this. Both regarding my concerns
> above, but also the advantages and issue you see with your approach
> compared to PIM-SM.
>
> I will be offline for the next 10 days, but hopefully this can get a
> discussion started in the working group.
>
> Stig
>
>
>
>
>
>
>
>
>
>
>
> sincerely yours
MR.SAEED SAMI