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

Lucy yong <lucy.yong@huawei.com> Fri, 27 February 2015 19:56 UTC

Return-Path: <lucy.yong@huawei.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923861A0007 for <pim@ietfa.amsl.com>; Fri, 27 Feb 2015 11:56:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hzt_dkLbkHi0 for <pim@ietfa.amsl.com>; Fri, 27 Feb 2015 11:56:14 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1392D1A0006 for <pim@ietf.org>; Fri, 27 Feb 2015 11:56:12 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTB50298; Fri, 27 Feb 2015 19:56:11 +0000 (GMT)
Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 27 Feb 2015 19:56:10 +0000
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Fri, 27 Feb 2015 11:55:59 -0800
From: Lucy yong <lucy.yong@huawei.com>
To: saeed sami <sami.biz.email@gmail.com>, "pim@ietf.org" <pim@ietf.org>, "pim-chairs@tools.ietf.org" <pim-chairs@tools.ietf.org>
Thread-Topic: [pim]New Version Notification for, draft-yong-rtgwg-igp-multicast-arch-00.txt
Thread-Index: AQHQUsI90X432xBFik6wIUIahigLTZ0E4WRw
Date: Fri, 27 Feb 2015 19:55:59 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D454581F5@dfweml701-chm>
References: <mailman.176.1424980817.27725.pim@ietf.org> <54F0C313.1020901@gmail.com>
In-Reply-To: <54F0C313.1020901@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.144.237]
Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D454581F5dfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/pim/_wcHo6CI4EF3PYTKuATGwJltHbM>
Subject: Re: [pim] New Version Notification for, draft-yong-rtgwg-igp-multicast-arch-00.txt
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Feb 2015 19:56:16 -0000

Hi Saeed,



Please see inline below.



-----Original Message-----
From: saeed sami [mailto:sami.biz.email@gmail.com]
Sent: Friday, February 27, 2015 1:19 PM
To: pim@ietf.org; pim-chairs@tools.ietf.org
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.



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.



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?



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.



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.



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.



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.



Thanks,

Lucy









On 02/26/2015 11:30 ب.ظ, pim-request@ietf.org<mailto:pim-request@ietf.org> wrote:

> Re: New Version Notification for

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