Re: [pim] New Version Notification for, draft-yong-rtgwg-igp-multicast-arch-00.txt

[Haoweiguo <[e-mail]>]

Hi Saeed,

Thanks for your detail comments, pls see my further replies below with [weiguo].

weiguo

________________________________
From: pim [[e-mail]] on behalf of Lucy yong [[e-mail]]
Sent: Saturday, February 28, 2015 3:55
To: saeed sami; [e-mail]; [e-mail]
Subject: Re: [pim] New Version Notification for, draft-yong-rtgwg-igp-multicast-arch-00.txt


Hi Saeed,



Please see inline below.



-----Original Message-----
From: saeed sami [mailto:[e-mail]]
Sent: Friday, February 27, 2015 1:19 PM
To: [e-mail]; [e-mail]
Subject: [pim]New Version Notification for, draft-yong-rtgwg-igp-multicast-arch-00.txt



Dear Weiguo and Lucy,

Hi.

it might be a little late but i just had the privilege of reading your draft.

having a unified routing protocol with both unicat and multicats capabilities is great idea which we have talked about it couple of times through email.



Lucy: It is not late! Thx. Glad that we agree on this point.

[weiguo]: Yes, unified protocol for both unicast and multicast can be used to simplify network management and optimize network performance, we have consensus on this important point.



But the problem with your draft at least to my eyes is the fact that it adds additional process over head with regards to multicast control plain on available routers, due to the fact that each router must run specific algorithm'(s) to calculate and form  distribution tree per multicast group . now add this to the  states each router Must keep per tree, and we will see lots of resource consumption and waste.



Lucy: To support multicast routing, need some process because it is not unicast. Comparing use of another protocol and process, the addition is less. It reuses some existing unicast algorithm as well. Router is much more powerful than 10, 20 years ago. The concern is not necessary. There are different techniques to address these concerns.

[weiguo]: The additional calculating cost is not so much, pls don't too worry about this. We have this implementation on data center switches, the extra multicast calculating imposes little on normal unicast routing performance.



If you have read Draft-Sami-Pim-Ng you can see that it is providing the possibility of using underlay unicast infrastructure with regards to the control plain and Source discovery instead of forming RPTs which you are trying to avoid too, and makes it faster in source discovery. one of PIM-NG's key features is that it doesnt need msdp to exchange SA messages and only needs unicast reach ability. so there wont be much calculation over head regarding the control plain and PIM-NG can be considered a hybrid multicast protocol.

Lucy: Sorry, haven’t followed up this approach. Do you mean use delivering mcast packet as a unicast packet?

[weiguo]:In NVO3 underlay networks, bidir-PIM is more popular than PIM-SM/PIM-SSM to carry BUM traffic in each overlay virtual network. The special source discovery isn't needed. The IGP multicast solution can replace bidir-PIM. Maybe PIM-NG is an enhanced solution for PIM-SM/SSM, the purpose is different.



The RPF check mentioned in the Draft alongside the  path selection done by IGP might cause the packets to be Dropped specifically with parallel links between 2 routers and  if not configured carefully can cause serious problems.

Lucy: The solution will tackle this issue.

[weiguo]: Don't worry about this parallel links scenario, it can be well solved in this solution. A tie-breaking algorithm is used in this solution to ensure only one link being selected for a multicast group, the tie-breaking algorithm also can achieve loadbalancing between the parrallel links for different multicast groups. All these don't need special configuration.



Now regarding the Bidirectional logic and distribution trees, having a default Tree and consequently making all routers to calculate the same tree doesn't seem a good idea, while what operators need is to be able to benefit from redundancy and also will put another process overhead on available routers. i see no advantage over existing BIDIR PIM

Lucy: That solution is similar to BIDIR PIM but without using PIM protocol. This allows IP fabric automation. Now we will focus on the IGP multicast architecture first and will work on the solution later.

[weiguo]: In default mode, if node or link failure occurs in the network, multicast re-calculating will be triggered just as unicast routing process.

If we want to achieve MFRR result(restrict traffic disruption in less than 50ms), distribution tree rebundancy and protection mechanism can be considered.



Now if you allow me i would like to say that Redundancy in Bidirectional logic is what PIM-NG can provide operators. it allows to have redundant Tree Roots per Bidirectional Tree and eventually Redundant Bidirectional Trees per Multicast Group all working together without a problem which is, what is needed the most. also it provides a unique bidirectional multicast group auto sense mechanism which over all makes it that revolutionary protocol suitable for any scenario and specifically DC domains. of course Bidirectional PIM can not be found in current Draft-Sami-Pim-Ng as it is one of its key features among many other features and i was waiting for my provisional patent app number to arrive and so it arrived, and you will see the new Bidir Logic providing redundancy in the new revision for the very first time.

Lucy: IGP multicast needs to address these. Hope you will work together on this subject. If your method is more advanced, we can adopt your. Does your solution relies on IGP protocol? (Sorry, I have not studies yet, but will). Now the key is to convince the WG to work on this. It seems that you are in favor of working on that.

[weiguo]: TRILL has distribution tree rebundancy mechanism using parent selection method. Maybe you have some other good solutions, we can work together on this subject.



I think having a unified routing protocol is great and what is needed the most but not at any cost specifically putting so much process overhead on routers in a network such as a data center. BUT there is a way of having the unified routing protocol everyone is looking for !!!

Lucy: Sure this is a good way to do this. We need to work on them and identify the one.

[weiguo]: Hope we can work together on this unified solution.

Thanks,

Lucy









On 02/26/2015 11:30 ب.ظ, [e-mail]<mailto:[e-mail]> wrote:

> Re: New Version Notification for

>        draft-yong-rtgwg-igp-multicast-arch-00.txt