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

From: saeed sami <[email-masked]>
Date: Wed, 30 Apr 2014 02:24:57 +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 cant be
posted to PIM mailing list as a single email, i have to post them in
separate  parts. and this is part 2.

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.

The answer to your questions are as follows which I hope will be
satisfying:

*1- Source register process  in PIM-NG and its similarity to PIM-SM:*

At the first glance the overall register process may seem similar to
PIM-SM, but
the register process in PIM-NG is different from PIM-SM. Bellow the process
is
briefly explained to make it clearer:

-  Source sends a unicast-encapsulated register message to the address of
the
RP which only contains the unicast address of the source and multicast
group
(G) it represents. This register message does not contain data packet.

-  RP receives the register message and saves the information within the
register
message inside a table called Multicast Mapping Table (MMT). The RP puts an
entry
in MMT containing the unicast address of the source and the multicast group
(G)
it represents alongside other information related to the source for further
use.
-  After puting an entry in MMT RP will send back an acknowledge to the
source
which indicates the successful registration of the information sent by
source.

-  after receiving the acknowledge from the RP source will start sending
keep-alive
messages to the RP as long as it represents the multicast traffic destined
for (G).

- in pim-sm a null register is in response to a register stop message sent
by RP in case RP hasn’t received any join messages for the (G) a source is
sending registers for. but since PIM-NG doesn't make use of RPT tree rooted
at an RP and the RP doesn't need to receive a join message of (*,G)  to
accept  a register message or join the RPT for (*,G) there will be only an
acknowledge and a
keep-alive.

-  the initial data packet does not need to be sent  because the overall
process through which a last hop router (client) finds a source differs
completely from that of PIM-SM.

*2- How a last hop (a router which shows interest to receive multicast
traffic destined for (G) or needs to find the source for (G) )learns about
active sources? Source-discovery:*

- in PIM-NG and in the ID, such a last hop router is called a client.

- In PIM-NG because of the way RP interacts with active sources and saves
the
information regarding active sources within the Domain in MMT, last hop
(client)
doesnt need to know about all the active sources within the Domain.

- considering the above, a client will contact the RP in case it needs to
find the
source of multicast traffic destined for (G) by sending a
unicast-encapsulated
request for source message to the RP indicating that it needs to find (S)
for (G).
((there won't be a join to RPT for (*, G).))

- after RP receives the request it will search the MMT or
AMMT(Abbreviated-MMT)
to see if it finds an entry for (S) which represents (G).

- If an entry is found in MMT or AMMT the RP will send a
unicast-encapsulated
acknowledge back to the client using the client's unicast address. This
acknowledge
contains the unicast address of the source for (G) along other information
which is used by a client.

- If an entry is not found, a null acknowledge (*,G) will be sent back to
the client.

- After receiving the acknowledge containing the unicast address of the
source for
(G) the client will directly join the SPT for (S, G).
((There will be no need for switching from RPT to SPT by the client (last
hop).))
- at this point a large number of clients or last hops won't be a problem
due to the
fact that there won't be any join to RPT rooted at the RP and the RP acts
as an
information station in PIM-NG which keeps the information regarding
existing
sources.

-  A client (last hop) won't need to send periodical query messages for
active source. A query is sent only when a client needs to find the source
of a multicast traffic.

End of part 2.

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