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

saeed sami <sami.biz.email@gmail.com> Fri, 27 February 2015 19:18 UTC

Return-Path: <sami.biz.email@gmail.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 510861AC3BF for <pim@ietfa.amsl.com>; Fri, 27 Feb 2015 11:18:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 Y2Vx4NhjFsod for <pim@ietfa.amsl.com>; Fri, 27 Feb 2015 11:18:52 -0800 (PST)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D901AC3BC for <pim@ietf.org>; Fri, 27 Feb 2015 11:18:52 -0800 (PST)
Received: by mail-qg0-f51.google.com with SMTP id e89so1853271qgf.10 for <pim@ietf.org>; Fri, 27 Feb 2015 11:18:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VmKj7f7aPUq7GcuPikCuVBYxVunbhkDmvPwlffjlGZc=; b=vx3T/57WITc8QKP6BaR1lPBSo9kqgq9p8UN9QZSehdTRc8StJhgRsjrxRlxoo37xBa ppvb+hyrMuQxO/G5/xxfxpFs8uk93KCvwZSbDgUg0Wl2pEmfaWwUW+I0IsbcuRo8d9Vv jAlSBWCz0XQIqPzVh64E8PrL4sJ2TSfEGXRN/E3GWuP1BjFFEbKUPGa5+kilCGRUFan5 zPk9+0ko/Ci22n5NJYWVoO55OPxDnVJJyYXjtzFShg/yNgsDSL1pYJrs0pRr85lINHob YX7L+tG6vpoVIQCfIJGP7lrDe8APWitUTEcrv3LdH/7++DRmqUYK8BDxbdnVJZmK41TL ppJw==
X-Received: by 10.229.99.135 with SMTP id u7mr32281579qcn.4.1425064731839; Fri, 27 Feb 2015 11:18:51 -0800 (PST)
Received: from [192.168.1.4] ([178.253.50.251]) by mx.google.com with ESMTPSA id s19sm3201687qac.5.2015.02.27.11.18.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 27 Feb 2015 11:18:49 -0800 (PST)
Message-ID: <54F0C313.1020901@gmail.com>
Date: Fri, 27 Feb 2015 22:48:43 +0330
From: saeed sami <sami.biz.email@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: pim@ietf.org, pim-chairs@tools.ietf.org
References: <mailman.176.1424980817.27725.pim@ietf.org>
In-Reply-To: <mailman.176.1424980817.27725.pim@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/pim/wrWEJ-gHpG60bBMUaeYTIokpelU>
Subject: [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:18:54 -0000

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.

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.

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.

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.

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

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.

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




On 02/26/2015 11:30 ب.ظ, pim-request@ietf.org wrote:
> Re: New Version Notification for
>        draft-yong-rtgwg-igp-multicast-arch-00.txt