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

From: Stig Venaas <[email-masked]>
Date: Mon, 19 May 2014 11:30:10 -0700

Hi

Sorry for the late response, let me comment on this.

On 4/29/2014 3:54 PM, saeed sami wrote:
> 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.____
>

There are implementations that only send null registers as well,
including for the initial register. Also, this is a unicast message.

> -  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.____

Which is a bit similar to responding with a register stop.
>
> -  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).____

This is like the periodic PIM null registers.

> - 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.____

This part is different, I agree.
>
> -  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.

Right, the data packet does not need to be sent for the multicast tree
to get constructed, but it means that applications will not get the
initial packet. There are other proposals with this shortcoming as well,
and for many applications this is fine. But at least this has a
significant impact on some applications, so it is worth emphasizing.
The different PIM protocols today usually allow for delivery of the
initial data packet. I should note that I'm proposing a way of
simplifying PIM-SM myself where initial packets would get dropped (by
avoiding PIM registers). So this is not unique to your proposal, and
I think it is OK for some deployments/applications.

> *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.____

This works well if the receiver is joining after the source started.
But what happens if the source starts later?

> -  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.

Assume that you have no active sources, but a host send an IGMP report
for a group G in order to receive. Then the client will send a request
to the RP as you described above, but it would not find any source
information.

Now if a source later starts to send, then you would like this host to
start receiving, but how does that happen? Either the client would need
to periodically query the RP, or the RP would need to keep track of
interested clients and send a notification.

Stig

> End of part 2.
>
>
>
> On Fri, Apr 25, 2014 at 10:32 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Send pim mailing list submissions to
>     [email-masked] <mailto:[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] <mailto:[email-masked]>
>
>     You can reach the person managing the list at
>     [email-masked] <mailto:[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] <mailto:[email-masked]>>
>     To: saeed sami <[email-masked]
>     <mailto:[email-masked]>>, pim <[email-masked]
>     <mailto:[email-masked]>>
>     Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng
>     Message-ID: <[email-masked]
>     <mailto:[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
>
>
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>