From nobody Wed Apr 2 01:24:50 2014 Return-Path: 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 3B08C1A016A; Wed, 2 Apr 2014 01:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 kLPPBHDcT9Gz; Wed, 2 Apr 2014 01:24:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B720C1A0168; Wed, 2 Apr 2014 01:24:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140402082440.14459.84671.idtracker@ietfa.amsl.com> Date: Wed, 02 Apr 2014 01:24:40 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pim/Iy8dEJ4uLOzEYDIPri3pgNzSCxE Cc: pim@ietf.org Subject: [pim] I-D Action: draft-ietf-pim-explicit-rpf-vector-04.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 08:24:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Explicit RPF Vector Authors : Javed Asghar IJsbrand Wijnands Sowmya Krishnaswamy Apoorva Karan Vishal Arya Filename : draft-ietf-pim-explicit-rpf-vector-04.txt Pages : 7 Date : 2014-04-02 Abstract: The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 can be included in a PIM Join Attribute such that the RPF neighbor is selected based on the unicast reachability of the RPF Vector instead of the Source or RP associated with the multicast tree. This document defines a new RPF Vector Attribute type such that an explicit RPF neighbor list can be encoded in the PIM Join Attribute, bypassing the unicast route lookup. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pim-explicit-rpf-vector/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pim-explicit-rpf-vector-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pim-explicit-rpf-vector-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 3 06:08:00 2014 Return-Path: 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 86F331A02D4 for ; Thu, 3 Apr 2014 06:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Fl4xa_zPyo15 for ; Thu, 3 Apr 2014 06:07:53 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 194E51A0354 for ; Thu, 3 Apr 2014 06:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10768; q=dns/txt; s=iport; t=1396530457; x=1397740057; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=XI+FxNjTUYYNEzLJKIYt8V7ze2MoQwY/Ka5M7Lklfaw=; b=c35xMcJRospHdsDZNE7l1Hfb427YlLGrYxzyywObRwnfXuvvVZ9nZkUY 2oljVIPoK57r5Vzxx4iAIHXkYTeGxgP54QfpMHkXXTFmo7yGRNDvx/Fqi JgGmHSrQAio9MLalIntR3l5TBXj9WmZ1jt2HR9O4h1ZWJ2tvIozxz3fyT A=; X-IronPort-AV: E=Sophos;i="4.97,787,1389744000"; d="scan'208";a="109758608" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by mtv-iport-2.cisco.com with ESMTP; 03 Apr 2014 13:07:36 +0000 Received: from rtp-vpn4-985.cisco.com (rtp-vpn4-985.cisco.com [10.82.211.217]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s33D7Y0D026562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Apr 2014 13:07:35 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: IJsbrand Wijnands In-Reply-To: <061601cf4e9b$adb85570$09290050$@olddog.co.uk> Date: Thu, 3 Apr 2014 15:07:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <85DAD28B-6A14-4BEB-B324-816A0FFA347D@cisco.com> References: <008e01cf1a88$eefd3600$ccf7a200$@olddog.co.uk> <533BC9AE.8020602@cisco.com> <061601cf4e9b$adb85570$09290050$@olddog.co.uk> To: X-Mailer: Apple Mail (2.1510) X-Auto-Response-Suppress: DR, OOF, AutoReply Archived-At: http://mailarchive.ietf.org/arch/msg/pim/J8qc0LSRo50Nwmj-Jr5FCojKFGA Cc: draft-ietf-pim-explicit-rpf-vector.all@tools.ietf.org, Javed Asghar , Alia Atlas , pim@ietf.org, "viking-vidmon-dev\(mailer list\)" Subject: Re: [pim] AD review of draft-ietf-pim-explicit-rpf-vector X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 13:07:57 -0000 Thanks Adrian, > Forwarded to Alia who now has the joy of being your AD. > =20 > =46rom me, just to note that you cannot demand a code point from IANA, = you can only request one. The way to do it is to use the TBD form of the = text I suggested and then say. "It is requested that IANA assign the = value 4." We'll change it to say 'requested'. > =20 > Note for future reference that if you feel an attachment for a = specific code point you really, really need to apply for an early = allocation (RFC 7120) because someone else might come along in the = intervening time and use your value for something else. Yes, we know about that. I remember discussing it with Stig at one = point, but since this was the only draft in the queue to request such = value I think the conclusion was that its not necessary to do early = allocation, but your right, we should really always do that to be safe. Thx, Ice. > =20 > Adrian > =20 > From: Javed Asghar [mailto:jasghar@cisco.com]=20 > Sent: 02 April 2014 09:26 > To: adrian@olddog.co.uk; draft-ietf-pim-explicit-rpf-vector=20 > Subject: Re: AD review of draft-ietf-pim-explicit-rpf-vector > =20 > Hi,=20 >=20 > Submitted updated draft: = http://www.ietf.org/internet-drafts/draft-ietf-pim-explicit-rpf-vector-04.= txt > Please see comments inline below. >=20 > Cheers, > -Javed. >=20 >=20 > On 1/26/2014 3:22 AM, Adrian Farrel wrote: > Hi, > =20 > I have done my usual AD review of this document after receiving the > publication request. The purpose of the review is to catch and fix > any issues that might otherwise show up in IETF last call or IESG > review. This helps smooth the passage of the document later and also > increases the quality text. > =20 > This seems like a good and simple proposal, and I don't want to bog > it down. But there are a number of small editorial issues and a=20 > couple of technical questions included below. > =20 > I have put the document into "Revised I-D Needed" state and will=20 > wait to see an updated version before I start the IETF last call. > But please feel free to debate any of these points with me. > =20 > Thanks for the work. > =20 > Adrian > =20 > --- > =20 > You need to fix the idnits before I can put this to IETF last call. > =20 > - Missing page breaks > - 2119 boilerplate broken (you have "SHALL" "NOT") > - there is a line too long > - missing reference for [draft-mofrr-karan] > =20 > [Shepherd - Your write-up says no nits found. How come?] > =20 > --- =20 > =20 > Conventionally we have used the term "strict" in counterpoint to > "loose" to describe hops, and termed the whole path "explicit". I > don't suppose this matters: you are defining your own terms for a > new application in PIM. > =20 > However, this has led to some confusion in the text because of the > normal use of the English word "explicit". For example, the Abstract > says: > This document defines a new Reverse Path Forwarding (RPF) Vector=20 > TLV to build multicast trees via an explicit path sent in the PIM=20= > join.=20 > ...which doesn't give any clue to the distinction between this work=20 > and RFC 5496. You might be better with something like: > The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC = 5496 > can be included in a PIM Join Attribute to allow a leaf to apply > controls to the path of a multicast tree. This document defines a > new Vector Attribute type so that an RPF Vector TLV can be used to > indicate that the unicast address indicated in the TLV must be used > as the next hop in the multicast tree. > =20 > This kind of language could usefully be repeated throughout the > document. >=20 > JA>>> Updated >=20 >=20 > --- > =20 > Section 1 > =20 > For some applications, it might be useful to have a way to specify > the explicit path along which the PIM join is propagated. =20 > =20 > Could you possibly be a little less vague? :-) > If this is the level of certainty you have for the utility of your = work > then it shouldn't be on the Standards Track. Fortunately, you *do* = have > a good use case later in the document. > =20 > I suggest re-ordering paragraphs: > =20 > 3, 4, 2 > =20 > ...and delete paragraph 1. > =20 > --- >=20 > JA>>> Updated. >=20 >=20 > Suggest to rename Section 3 "Motivation" > =20 > --- >=20 > JA>>> Updated >=20 >=20 > Section 3 > =20 > As noted above, you need to provide the reference for > [draft-mofrr-karan]. But actually, I wonder whether you really need to > include the citation as the text in the paragraph seems to hold up = well > without any further explanation. > =20 > --- >=20 > JA>>> Updated. >=20 >=20 > Section 3 > =20 > It might be useful to have a way to specify the explicit path=20 > along which the PIM join is propagated. > =20 > I think you established that it *is* useful in the previous text. >=20 > JA>>> Corrected. >=20 >=20 > --- > =20 > Section 3 > =20 > How the Explicit RPF Vector list is determined is outside the=20 > scope of this document. It may either be manually configured by > the network operator or procedures may be implemented on the=20 > egress router to dynamically calculate the vector list based on=20 > a link state database protocol, like OSPF or IS-IS. > =20 > I agree that this should be out of scope and you should say so. > However, having said it is out of scope, why do you go on to=20 > discuss it? >=20 > JA>>> Ack. This is implementation specific. We have changed this = discussion as example. This was feedback from previous reviews. >=20 >=20 > --- > =20 > You should give more clarity as to why an RPF list using 5496 list > entries would not be good enough. In Figure 1 it would appear that the > list {R4, R3, R6, R5, R2, R1} would work just fine using 5496. >=20 > JA>>> Added more clarity with a comparison between Explicit RPF Vector = and RFC5496 procedures. >=20 >=20 > --- > =20 > Section 5 > =20 > This draft uses PIM join attribute type 4 for specifying an = Explicit=20 > RPF Vector.=20 > =20 > Please make this: > =20 > This draft uses PIM join attribute type TBD by IANA for specifying = an > Explicit RPF Vector.=20 > =20 > --- >=20 > JA>>> Updated. >=20 >=20 > Section 7 is describing, for example, simple network with source S and > leafs R1 and R2... > =20 > A R1 > / \ / > S C > \ / \ > B R2 > =20 > ...where R1 sends explicit RPF TLVs {C, A} and that path is set up. > Then R2 sends explicit RPF TLVs {C, B}. > =20 > Section 3.3.3 of RFC 5384 is cited as the tie-breaker.=20 > This is OK, but it appears to say that the Explicit RPF is not=20 > mandatory. It would be nice to make it very clear that a receiver has > no expectations that the explicit RPF list it supplies will actually = be > used. >=20 > JA>>> There is no change in our draft with respect to this behavior = and its documented well in RFC 5384 section 3.3.3. Adding more text = could confuse the reader. We felt the current text is sufficient. Let us = know if this is ok with you.=20 >=20 >=20 > --- > =20 > Section 10 > =20 > This is important material to include, but I think it needs some work. > =20 > The F bit MUST be set to 0 by a downstream router in the join that=20= > is sent to the upstream router that does not support Explicit RPF=20= > vector. > =20 > But the downstream router doesn't know whether the upstream router=20 > supports the new vector or not! So I think you need... > =20 > The F bit MUST be set to 0 in all Explicit RPF vectors in case the > upstream router receiving the join does not support the TLV. As > described in section 3.3.2 of [RFC5384], routers that do not=20 > understand the type of a particular attribute that has the F bit > clear will discard it and continue to process the join. > =20 > This processing is particularly important when the routers that > do not support the Explicit RPF TLV are identified as hops in the > explicit RPF list, because failing to remove the RPF vectors could > cause upstream routers to send the join back toward these routers > causing loops. >=20 > JA>>> Updated. Thanks for the clarity. Its very precise. >=20 >=20 > =20 > However, this doesn't seem to be the only way that loops can be caused > (referring back to section 9). > I don't see this mentioned in RFC 5496 either, but surely: > - the RPF list could contain an explicit loop > - the use of loose hops with poorly ordered list entries could create = a > loop > =20 > It is fine to note that this is caught by normal PIM processing, but=20= > you should say so, and you should say what happens to the join. It > seems to me that 3.3.4 of 5496 only catches the case where join is > targeting the same upstream neighbor. But the sequential list nature > of the RPF list means that the loop might not be "endless" but could > still be a loop. How is this caught and handled? >=20 >=20 > JA>>> Please note that the explicit or loose RPF vector list at every = hop will consume the RPF vector entry. If an explicit or loose RPF = vector list is constructed poorly (eg. mis-config) the processing of the = RPF vector is still as described in RFC 5496 and doesn't need to change. = We need to fix the user error.=20 >=20 >=20 > --- > =20 > Section 11 > =20 > Please replace... > =20 > OLD > Type > ---- > The Vector Attribute type is 4. > NEW > Type > ---- > The Vector Attribute type is TBD by IANA. > END > =20 > --- >=20 > JA>>> We would like to request type 4 attribute from IANA explicitly.=20= >=20 >=20 > Section 13 seems light! > =20 > The RPF list (and especially the explicit RPF) provides a way to > cause traffic to take different routes through the network. This > could be used to cause traffic to take expensive paths, to be > routed through hot parts of the network, or to be directed to > snooping nodes. > =20 > This means that the existence of the RPF TLV makes the use of=20 > security in PIM more important to prevent tampering with the RPF > list. > JA>>> Good point.=20 >=20 >=20 > But it also raises a question of policy and authorization. Clearly, > when a receiver seeks to join a multicast tree, it must be=20 > authenticated for that join. But additionally, you may want to note=20 > that the inclusion of an RPF list by a receiver should be subject to > policy. >=20 > JA>>> Updated.=20 >=20 >=20 > . > =20 > =20 From nobody Thu Apr 3 06:11:24 2014 Return-Path: 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 6C9451A01F6 for ; Thu, 3 Apr 2014 06:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 v3nLw27XnsK0 for ; Thu, 3 Apr 2014 06:11:18 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id A37E01A020F for ; Thu, 3 Apr 2014 06:11:18 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id v1so1644752yhn.0 for ; Thu, 03 Apr 2014 06:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pBx6grlK1gWTrD0h94GBp79CC5FDuBGc8YOdFwJNJPI=; b=MX0XycB2OQu8pWnQbTuZwkCqYKNrBG68Sb94lIlI42SnX9dTdPnsO6WHG2t8KCYbNY Ap5udO4K1LsdcO4kV3/h7j4imaNciZExEpLHvlfbUsvELOHv+rlpxZorGa2i/yE/ywu7 wk9a+C88Anoa3nfVSC2WcVTl1rIuyHWZAYoVm3CbJ4lefjFOb3DxnFXzBnXYGCeEiLKk qG7dKMosmO4CEhZmprH/vasaI8wo6l/X6gAeNidnlIi8Z81ZqvjWEphtsZ1Pq5hyf9Rd oSG5bLlndl3G8h6ELW0q1I9qwzhiImldIBAIY2Pz60PJhFwLB/8xRUP/06SXqDCpEHWV 1jmA== MIME-Version: 1.0 X-Received: by 10.236.220.72 with SMTP id n68mr3913037yhp.102.1396530674292; Thu, 03 Apr 2014 06:11:14 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Thu, 3 Apr 2014 06:11:14 -0700 (PDT) In-Reply-To: <85DAD28B-6A14-4BEB-B324-816A0FFA347D@cisco.com> References: <008e01cf1a88$eefd3600$ccf7a200$@olddog.co.uk> <533BC9AE.8020602@cisco.com> <061601cf4e9b$adb85570$09290050$@olddog.co.uk> <85DAD28B-6A14-4BEB-B324-816A0FFA347D@cisco.com> Date: Thu, 3 Apr 2014 09:11:14 -0400 Message-ID: From: Alia Atlas To: IJsbrand Wijnands Content-Type: multipart/alternative; boundary=001a11c2badac25e9a04f6232299 Archived-At: http://mailarchive.ietf.org/arch/msg/pim/XlIoA2kqIgBA90MlNN7nPcoou24 Cc: "viking-vidmon-dev\(mailer list\)" , Javed Asghar , draft-ietf-pim-explicit-rpf-vector.all@tools.ietf.org, Alia Atlas , pim@ietf.org Subject: Re: [pim] AD review of draft-ietf-pim-explicit-rpf-vector X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 13:11:23 -0000 --001a11c2badac25e9a04f6232299 Content-Type: text/plain; charset=ISO-8859-1 Thanks for updating the draft. I will review it very soon so we can get it moving along. Alia On Thu, Apr 3, 2014 at 9:07 AM, IJsbrand Wijnands wrote: > Thanks Adrian, > > > Forwarded to Alia who now has the joy of being your AD. > > > > From me, just to note that you cannot demand a code point from IANA, you > can only request one. The way to do it is to use the TBD form of the text I > suggested and then say. "It is requested that IANA assign the value 4." > > We'll change it to say 'requested'. > > > > > Note for future reference that if you feel an attachment for a specific > code point you really, really need to apply for an early allocation (RFC > 7120) because someone else might come along in the intervening time and use > your value for something else. > > Yes, we know about that. I remember discussing it with Stig at one point, > but since this was the only draft in the queue to request such value I > think the conclusion was that its not necessary to do early allocation, but > your right, we should really always do that to be safe. > > Thx, > > Ice. > > > > > > Adrian > > > > From: Javed Asghar [mailto:jasghar@cisco.com] > > Sent: 02 April 2014 09:26 > > To: adrian@olddog.co.uk; draft-ietf-pim-explicit-rpf-vector > > Subject: Re: AD review of draft-ietf-pim-explicit-rpf-vector > > > > Hi, > > > > Submitted updated draft: > http://www.ietf.org/internet-drafts/draft-ietf-pim-explicit-rpf-vector-04.txt > > Please see comments inline below. > > > > Cheers, > > -Javed. > > > > > > On 1/26/2014 3:22 AM, Adrian Farrel wrote: > > Hi, > > > > I have done my usual AD review of this document after receiving the > > publication request. The purpose of the review is to catch and fix > > any issues that might otherwise show up in IETF last call or IESG > > review. This helps smooth the passage of the document later and also > > increases the quality text. > > > > This seems like a good and simple proposal, and I don't want to bog > > it down. But there are a number of small editorial issues and a > > couple of technical questions included below. > > > > I have put the document into "Revised I-D Needed" state and will > > wait to see an updated version before I start the IETF last call. > > But please feel free to debate any of these points with me. > > > > Thanks for the work. > > > > Adrian > > > > --- > > > > You need to fix the idnits before I can put this to IETF last call. > > > > - Missing page breaks > > - 2119 boilerplate broken (you have "SHALL" "NOT") > > - there is a line too long > > - missing reference for [draft-mofrr-karan] > > > > [Shepherd - Your write-up says no nits found. How come?] > > > > --- > > > > Conventionally we have used the term "strict" in counterpoint to > > "loose" to describe hops, and termed the whole path "explicit". I > > don't suppose this matters: you are defining your own terms for a > > new application in PIM. > > > > However, this has led to some confusion in the text because of the > > normal use of the English word "explicit". For example, the Abstract > > says: > > This document defines a new Reverse Path Forwarding (RPF) Vector > > TLV to build multicast trees via an explicit path sent in the PIM > > join. > > ...which doesn't give any clue to the distinction between this work > > and RFC 5496. You might be better with something like: > > The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 > > can be included in a PIM Join Attribute to allow a leaf to apply > > controls to the path of a multicast tree. This document defines a > > new Vector Attribute type so that an RPF Vector TLV can be used to > > indicate that the unicast address indicated in the TLV must be used > > as the next hop in the multicast tree. > > > > This kind of language could usefully be repeated throughout the > > document. > > > > JA>>> Updated > > > > > > --- > > > > Section 1 > > > > For some applications, it might be useful to have a way to specify > > the explicit path along which the PIM join is propagated. > > > > Could you possibly be a little less vague? :-) > > If this is the level of certainty you have for the utility of your work > > then it shouldn't be on the Standards Track. Fortunately, you *do* have > > a good use case later in the document. > > > > I suggest re-ordering paragraphs: > > > > 3, 4, 2 > > > > ...and delete paragraph 1. > > > > --- > > > > JA>>> Updated. > > > > > > Suggest to rename Section 3 "Motivation" > > > > --- > > > > JA>>> Updated > > > > > > Section 3 > > > > As noted above, you need to provide the reference for > > [draft-mofrr-karan]. But actually, I wonder whether you really need to > > include the citation as the text in the paragraph seems to hold up well > > without any further explanation. > > > > --- > > > > JA>>> Updated. > > > > > > Section 3 > > > > It might be useful to have a way to specify the explicit path > > along which the PIM join is propagated. > > > > I think you established that it *is* useful in the previous text. > > > > JA>>> Corrected. > > > > > > --- > > > > Section 3 > > > > How the Explicit RPF Vector list is determined is outside the > > scope of this document. It may either be manually configured by > > the network operator or procedures may be implemented on the > > egress router to dynamically calculate the vector list based on > > a link state database protocol, like OSPF or IS-IS. > > > > I agree that this should be out of scope and you should say so. > > However, having said it is out of scope, why do you go on to > > discuss it? > > > > JA>>> Ack. This is implementation specific. We have changed this > discussion as example. This was feedback from previous reviews. > > > > > > --- > > > > You should give more clarity as to why an RPF list using 5496 list > > entries would not be good enough. In Figure 1 it would appear that the > > list {R4, R3, R6, R5, R2, R1} would work just fine using 5496. > > > > JA>>> Added more clarity with a comparison between Explicit RPF Vector > and RFC5496 procedures. > > > > > > --- > > > > Section 5 > > > > This draft uses PIM join attribute type 4 for specifying an Explicit > > RPF Vector. > > > > Please make this: > > > > This draft uses PIM join attribute type TBD by IANA for specifying an > > Explicit RPF Vector. > > > > --- > > > > JA>>> Updated. > > > > > > Section 7 is describing, for example, simple network with source S and > > leafs R1 and R2... > > > > A R1 > > / \ / > > S C > > \ / \ > > B R2 > > > > ...where R1 sends explicit RPF TLVs {C, A} and that path is set up. > > Then R2 sends explicit RPF TLVs {C, B}. > > > > Section 3.3.3 of RFC 5384 is cited as the tie-breaker. > > This is OK, but it appears to say that the Explicit RPF is not > > mandatory. It would be nice to make it very clear that a receiver has > > no expectations that the explicit RPF list it supplies will actually be > > used. > > > > JA>>> There is no change in our draft with respect to this behavior and > its documented well in RFC 5384 section 3.3.3. Adding more text could > confuse the reader. We felt the current text is sufficient. Let us know if > this is ok with you. > > > > > > --- > > > > Section 10 > > > > This is important material to include, but I think it needs some work. > > > > The F bit MUST be set to 0 by a downstream router in the join that > > is sent to the upstream router that does not support Explicit RPF > > vector. > > > > But the downstream router doesn't know whether the upstream router > > supports the new vector or not! So I think you need... > > > > The F bit MUST be set to 0 in all Explicit RPF vectors in case the > > upstream router receiving the join does not support the TLV. As > > described in section 3.3.2 of [RFC5384], routers that do not > > understand the type of a particular attribute that has the F bit > > clear will discard it and continue to process the join. > > > > This processing is particularly important when the routers that > > do not support the Explicit RPF TLV are identified as hops in the > > explicit RPF list, because failing to remove the RPF vectors could > > cause upstream routers to send the join back toward these routers > > causing loops. > > > > JA>>> Updated. Thanks for the clarity. Its very precise. > > > > > > > > However, this doesn't seem to be the only way that loops can be caused > > (referring back to section 9). > > I don't see this mentioned in RFC 5496 either, but surely: > > - the RPF list could contain an explicit loop > > - the use of loose hops with poorly ordered list entries could create a > > loop > > > > It is fine to note that this is caught by normal PIM processing, but > > you should say so, and you should say what happens to the join. It > > seems to me that 3.3.4 of 5496 only catches the case where join is > > targeting the same upstream neighbor. But the sequential list nature > > of the RPF list means that the loop might not be "endless" but could > > still be a loop. How is this caught and handled? > > > > > > JA>>> Please note that the explicit or loose RPF vector list at every > hop will consume the RPF vector entry. If an explicit or loose RPF vector > list is constructed poorly (eg. mis-config) the processing of the RPF > vector is still as described in RFC 5496 and doesn't need to change. We > need to fix the user error. > > > > > > --- > > > > Section 11 > > > > Please replace... > > > > OLD > > Type > > ---- > > The Vector Attribute type is 4. > > NEW > > Type > > ---- > > The Vector Attribute type is TBD by IANA. > > END > > > > --- > > > > JA>>> We would like to request type 4 attribute from IANA explicitly. > > > > > > Section 13 seems light! > > > > The RPF list (and especially the explicit RPF) provides a way to > > cause traffic to take different routes through the network. This > > could be used to cause traffic to take expensive paths, to be > > routed through hot parts of the network, or to be directed to > > snooping nodes. > > > > This means that the existence of the RPF TLV makes the use of > > security in PIM more important to prevent tampering with the RPF > > list. > > JA>>> Good point. > > > > > > But it also raises a question of policy and authorization. Clearly, > > when a receiver seeks to join a multicast tree, it must be > > authenticated for that join. But additionally, you may want to note > > that the inclusion of an RPF list by a receiver should be subject to > > policy. > > > > JA>>> Updated. > > > > > > . > > > > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > --001a11c2badac25e9a04f6232299 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for updating the draft. =A0I will review it very so= on so we can get it moving along.

Alia


On Thu, Apr 3, 2014= at 9:07 AM, IJsbrand Wijnands <ice@cisco.com> wrote:
Thanks Adrian,

> Forwarded to Alia who now has the joy of being your AD.
>
> From me, just to note that you cannot demand a code point from IANA, y= ou can only request one. The way to do it is to use the TBD form of the tex= t I suggested and then say. "It is requested that IANA assign the valu= e 4."

We'll change it to say 'requested'.

>
> Note for future reference that if you feel an attachment for a specifi= c code point you really, really need to apply for an early allocation (RFC = 7120) because someone else might come along in the intervening time and use= your value for something else.

Yes, we know about that. I remember discussing it with Stig at one po= int, but since this was the only draft in the queue to request such value I= think the conclusion was that its not necessary to do early allocation, bu= t your right, we should really always do that to be safe.

Thx,

Ice.


>
> Adrian
>
> From: Javed Asghar [mailto:jasgha= r@cisco.com]
> Sent: 02 April 2014 09:26
> To: adrian@olddog.co.uk; dr= aft-ietf-pim-explicit-rpf-vector
> Subject: Re: AD review of draft-ietf-pim-explicit-rpf-vector
>
> Hi,
>
> Submitted updated draft: http://www.i= etf.org/internet-drafts/draft-ietf-pim-explicit-rpf-vector-04.txt
> Please see comments inline below.
>
> Cheers,
> -Javed.
>
>
> On 1/26/2014 3:22 AM, Adrian Farrel wrote:
> Hi,
>
> I have done my usual AD review of this document after receiving the > publication request. The purpose of the review is to catch and fix
> any issues that might otherwise show up in IETF last call or IESG
> review. This helps smooth the passage of the document later and also > increases the quality text.
>
> This seems like a good and simple proposal, and I don't want to bo= g
> it down. But there are a number of small editorial issues and a
> couple of technical questions included below.
>
> I have put the document into "Revised I-D Needed" state and = will
> wait to see an updated version before I start the IETF last call.
> But please feel free to debate any of these points with me.
>
> Thanks for the work.
>
> Adrian
>
> ---
>
> You need to fix the idnits before I can put this to IETF last call. >
> - Missing page breaks
> - 2119 boilerplate broken (you have "SHALL" "NOT")=
> - there is a line too long
> - missing reference for [draft-mofrr-karan]
>
> [Shepherd - Your write-up says no nits found. How come?]
>
> ---
>
> Conventionally we have used the term "strict" in counterpoin= t to
> "loose" to describe hops, and termed the whole path "ex= plicit". I
> don't suppose this matters: you are defining your own terms for a<= br> > new application in PIM.
>
> However, this has led to some confusion in the text because of the
> normal use of the English word "explicit". For example, the = Abstract
> says:
> =A0 =A0This document defines a new Reverse Path Forwarding (RPF) Vecto= r
> =A0 =A0TLV to build multicast trees via an explicit path sent in the P= IM
> =A0 =A0join.
> ...which doesn't give any clue to the distinction between this wor= k
> and RFC 5496. You might be better with something like:
> =A0 =A0The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC= 5496
> =A0 =A0can be included in a PIM Join Attribute to allow a leaf to appl= y
> =A0 =A0controls to the path of a multicast tree. This document defines= a
> =A0 =A0new Vector Attribute type so that an RPF Vector TLV can be used= to
> =A0 =A0indicate that the unicast address indicated in the TLV must be = used
> =A0 =A0as the next hop in the multicast tree.
>
> This kind of language could usefully be repeated throughout the
> document.
>
> JA>>> Updated
>
>
> ---
>
> Section 1
>
> =A0 =A0For some applications, it might be useful to have a way to spec= ify
> =A0 =A0the explicit path along which the PIM join is propagated.
>
> Could you possibly be a little less vague? :-)
> If this is the level of certainty you have for the utility of your wor= k
> then it shouldn't be on the Standards Track. Fortunately, you *do*= have
> a good use case later in the document.
>
> I suggest re-ordering paragraphs:
>
> 3, 4, 2
>
> ...and delete paragraph 1.
>
> ---
>
> JA>>> Updated.
>
>
> Suggest to rename Section 3 "Motivation"
>
> ---
>
> JA>>> Updated
>
>
> Section 3
>
> As noted above, you need to provide the reference for
> [draft-mofrr-karan]. But actually, I wonder whether you really need to=
> include the citation as the text in the paragraph seems to hold up wel= l
> without any further explanation.
>
> ---
>
> JA>>> Updated.
>
>
> Section 3
>
> =A0 =A0It might be useful to have a way to specify the explicit path > =A0 =A0along which the PIM join is propagated.
>
> I think you established that it *is* useful in the previous text.
>
> JA>>> Corrected.
>
>
> ---
>
> Section 3
>
> =A0 =A0How the Explicit RPF Vector list is determined is outside the > =A0 =A0scope of this document. It may either be manually configured by=
> =A0 =A0the network operator or procedures may be implemented on the > =A0 =A0egress router to dynamically calculate the vector list based on=
> =A0 =A0a link state database protocol, like OSPF or IS-IS.
>
> I agree that this should be out of scope and you should say so.
> However, having said it is out of scope, why do you go on to
> discuss it?
>
> JA>>> Ack. This is implementation specific. We have changed t= his discussion as example. This was feedback from previous reviews.
>
>
> ---
>
> You should give more clarity as to why an RPF list using 5496 list
> entries would not be good enough. In Figure 1 it would appear that the=
> list {R4, R3, R6, R5, R2, R1} would work just fine using 5496.
>
> JA>>> Added more clarity with a comparison between Explicit R= PF Vector and RFC5496 procedures.
>
>
> ---
>
> Section 5
>
> =A0 =A0This draft uses PIM join attribute type 4 for specifying an Exp= licit
> =A0 =A0RPF Vector.
>
> Please make this:
>
> =A0 =A0This draft uses PIM join attribute type TBD by IANA for specify= ing an
> =A0 =A0Explicit RPF Vector.
>
> ---
>
> JA>>> Updated.
>
>
> Section 7 is describing, for example, simple network with source S and=
> leafs R1 and R2...
>
> =A0 A =A0 R1
> =A0/ \ /
> S =A0 C
> =A0\ / \
> =A0 B =A0 R2
>
> ...where R1 sends explicit RPF TLVs {C, A} and that path is set up. > Then R2 sends explicit RPF TLVs {C, B}.
>
> Section 3.3.3 of RFC 5384 is cited as the tie-breaker.
> This is OK, but it appears to say that the Explicit RPF is not
> mandatory. It would be nice to make it very clear that a receiver has<= br> > no expectations that the explicit RPF list it supplies will actually b= e
> used.
>
> JA>>> There is no change in our draft with respect to this be= havior and its documented well in RFC 5384 section 3.3.3. Adding more text = could confuse the reader. We felt the current text is sufficient. Let us kn= ow if this is ok with you.
>
>
> ---
>
> Section 10
>
> This is important material to include, but I think it needs some work.=
>
> =A0 =A0The F bit MUST be set to 0 by a downstream router in the join t= hat
> =A0 =A0is sent to the upstream router that does not support Explicit R= PF
> =A0 =A0vector.
>
> But the downstream router doesn't know whether the upstream router=
> supports the new vector or not! So I think you need...
>
> =A0 =A0The F bit MUST be set to 0 in all Explicit RPF vectors in case = the
> =A0 =A0upstream router receiving the join does not support the TLV. As=
> =A0 =A0described in section 3.3.2 of [RFC5384], routers that do not > =A0 =A0understand the type of a particular attribute that has the F bi= t
> =A0 =A0clear will discard it and continue to process the join.
>
> =A0 =A0This processing is particularly important when the routers that=
> =A0 =A0do not support the Explicit RPF TLV are identified as hops in t= he
> =A0 =A0explicit RPF list, because failing to remove the RPF vectors co= uld
> =A0 =A0cause upstream routers to send the join back toward these route= rs
> =A0 =A0causing loops.
>
> JA>>> Updated. Thanks for the clarity. Its very precise.
>
>
>
> However, this doesn't seem to be the only way that loops can be ca= used
> (referring back to section 9).
> I don't see this mentioned in RFC 5496 either, but surely:
> - the RPF list could contain an explicit loop
> - the use of loose hops with poorly ordered list entries could create = a
> =A0 loop
>
> It is fine to note that this is caught by normal PIM processing, but > you should say so, and you should say what happens to the join. It
> seems to me that 3.3.4 of 5496 only catches the case where join is
> targeting the same upstream neighbor. But the sequential list nature > of the RPF list means that the loop might not be "endless" b= ut could
> still be a loop. How is this caught and handled?
>
>
> JA>>> Please note that the explicit or loose RPF vector list = at every hop will consume the RPF vector entry. If an explicit or loose RPF= vector list is constructed poorly (eg. mis-config) the processing of the R= PF vector is still as described in RFC 5496 and doesn't need to change.= We need to fix the user error.
>
>
> ---
>
> Section 11
>
> Please replace...
>
> OLD
> =A0 =A0Type
> =A0 =A0----
> =A0 =A0The Vector Attribute type is 4.
> NEW
> =A0 =A0Type
> =A0 =A0----
> =A0 =A0The Vector Attribute type is TBD by IANA.
> END
>
> ---
>
> JA>>> We would like to request type 4 attribute from IANA exp= licitly.
>
>
> Section 13 seems light!
>
> The RPF list (and especially the explicit RPF) provides a way to
> cause traffic to take different routes through the network. This
> could be used to cause traffic to take expensive paths, to be
> routed through hot parts of the network, or to be directed to
> snooping nodes.
>
> This means that the existence of the RPF TLV makes the use of
> security in PIM more important to prevent tampering with the RPF
> list.
> JA>>> Good point.
>
>
> But it also raises a question of policy and authorization. Clearly, > when a receiver seeks to join a multicast tree, it must be
> authenticated for that join. But additionally, you may want to note > that the inclusion of an RPF list by a receiver should be subject to > policy.
>
> JA>>> Updated.
>
>
> .
>
>

_______________________________________________
pim mailing list
pim@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pim

--001a11c2badac25e9a04f6232299-- From artem@kraft-s.ru Thu Apr 10 02:20:03 2014 Return-Path: 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 031181A0484 for ; Thu, 10 Apr 2014 02:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.27 X-Spam-Level: ** X-Spam-Status: No, score=2.27 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] autolearn=no 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 EfSsmiCDHYfF for ; Thu, 10 Apr 2014 02:20:02 -0700 (PDT) Received: from relay1.hippo.ru (relay1.hippo.ru [213.156.192.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4481A0481 for ; Thu, 10 Apr 2014 02:20:01 -0700 (PDT) Received: from [213.156.193.27] (artmc.kraft-s.ru [213.156.193.27]) by relay1.hippo.ru (8.14.8/8.14.7) with ESMTP id s3A9JtcA002960 for ; Thu, 10 Apr 2014 13:20:00 +0400 Message-ID: <53466238.3060100@kraft-s.ru> Date: Thu, 10 Apr 2014 13:19:52 +0400 From: Artem Tsyganov Organization: ISP Kraft-s User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: 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/sK-mKX3uCgaoMerwYuH_jOoFj2o Subject: [pim] pimd and mvr dont work X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 09:33:12 -0000 Hello. Can you please tell me whether PIMD works with MVR? The problem is I can't make it work on sample stand with MVR-support switch and router on Linux. In this scheme I have all client requests coming in separate vlan from ip-address that is not in this subnetwork , so PIMD do not see them. I guess that PIMD must know interface from which this request has come, but not the ip-address -- --- С уважением, Артём Цыганов From nobody Thu Apr 10 15:56:04 2014 Return-Path: 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 DF0491A02DF for ; Thu, 10 Apr 2014 15:56:02 -0700 (PDT) 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 Yk-uYwLpW_3b for ; Thu, 10 Apr 2014 15:56:01 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 09E781A02C6 for ; Thu, 10 Apr 2014 15:56:00 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so2903038lbj.3 for ; Thu, 10 Apr 2014 15:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Ybsk23mgyzg2dK9xeTCDAP8RQHuBoISuIZP5c2aJQhc=; b=t3yPGjPCiTmfurkWT0LFOgS6z2c1xM9e7skQ/Peg9bHfpc7WxPG17pnXl7yk41avEs eSPSExrWLKvqfzxpG2RUDA8meSK4mh+mtcjGE4SUh2uawkBxvzKJUpiRKYLrgeEJRKvJ f51GQOartBliZEA2ztNPgQ+Q9d4hBgOZSaiCydBHXrm0wT4ZitJcz/ACRoE9ZHSlY3FN lRnidda+MzbjHFF1WNErYKCCWcsSn6hcYZ2owfDIKbk9Ks0vZ6/PsuxfD3+uUmev68AH u02dXgsNKgh3N0NSzB9jjyZa/sBqCPJgre1Mvjw6GhhuqIYtPziOdLo4ER97ihp0vL6O 5JEA== MIME-Version: 1.0 X-Received: by 10.152.239.137 with SMTP id vs9mr22391lac.59.1397170559368; Thu, 10 Apr 2014 15:55:59 -0700 (PDT) Received: by 10.152.87.50 with HTTP; Thu, 10 Apr 2014 15:55:59 -0700 (PDT) Date: Fri, 11 Apr 2014 03:25:59 +0430 Message-ID: From: saeed sami To: pim Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/pim/6wYhak6UUeNbiNQGZ-VDjVMER0c Cc: pim-chairs Subject: [pim] New updated and edited version of draft-sami-pim-ng X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 22:56:03 -0000 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. -- sincerely yours MR.SAEED SAMI From nobody Thu Apr 24 14:25:14 2014 Return-Path: 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 17CA41A03F5 for ; Thu, 24 Apr 2014 14:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 JDS9-BA86V4n for ; Thu, 24 Apr 2014 14:25:07 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 24E151A03EF for ; Thu, 24 Apr 2014 14:25:07 -0700 (PDT) Received: from [IPv6:2001:420:301:1004:e0c4:5f1f:cd37:ea3f] (unknown [IPv6:2001:420:301:1004:e0c4:5f1f:cd37:ea3f]) by ufisa.uninett.no (Postfix) with ESMTPSA id 470E08030; Thu, 24 Apr 2014 23:24:59 +0200 (CEST) Message-ID: <53598128.1090107@venaas.com> Date: Thu, 24 Apr 2014 14:24:56 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saeed sami , pim References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pim/vEm_q4UodSdiehfn_yjlFEcJv1M Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 21:25:10 -0000 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 From nobody Thu Apr 24 16:46:34 2014 Return-Path: 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 2463C1A0450 for ; Thu, 24 Apr 2014 16:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.754 X-Spam-Level: X-Spam-Status: No, score=0.754 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, FRT_BELOW2=2.154, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no 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 2_yGCo59KSR0 for ; Thu, 24 Apr 2014 16:46:31 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id E7D871A0449 for ; Thu, 24 Apr 2014 16:46:30 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so225245wgg.0 for ; Thu, 24 Apr 2014 16:46:24 -0700 (PDT) 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=hLIcC0W4QWRc53WR+qTXKoMO3VcvaSph5PZ9271drjQ=; b=LtnG9RdmomRaYsGgksxzoE3HSotdRt1zKwhHIblU5NzcGaf1A0Yofa8bpRrLgSq7CS 1i+q0vxSnv1XAFC/DHO2xsOyBnPiLnCsxMCNP8Q/KoFw/D7WtkHk7lI6XJIjCFnxu1cJ A6JgyqAaBQuN8OZFr1oQ8WUBX/VntFRM7zAYTRropWwm5aYJnZ6rTmWfEVMkPFZ6WFNe rudTXtsnedQQVU/eUHtVwt8KXa/J2Ox9BFZrCEF2zeQ3152/nTDkKTBS8NIuKO0gyvjr itNsoEWa7QN2QOAWACqhp12GLTvVCpLVbo68+VwUU2MXtNOfUmozZiOWcNr+siDP4oGn Y+EQ== X-Received: by 10.180.39.175 with SMTP id q15mr1161505wik.4.1398383184248; Thu, 24 Apr 2014 16:46:24 -0700 (PDT) Received: from [192.168.1.5] ([178.253.53.220]) by mx.google.com with ESMTPSA id go20sm8353694wjc.18.2014.04.24.16.46.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Apr 2014 16:46:23 -0700 (PDT) Message-ID: <5359AF8C.6080405@gmail.com> Date: Fri, 25 Apr 2014 04:12:52 +0330 From: saeed sami User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stig Venaas , pim@ietf.org References: <53598128.1090107@venaas.com> In-Reply-To: <53598128.1090107@venaas.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/pim/wu3LuOm1TKcnESeke4FK9Yw3RLY Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 23:46:33 -0000 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. the answer to your questions are as follows which i hope will be satisfying: 1- Source register process in PIM-NG : 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 more clear: - 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). - due to the above PIM-NG does not need initial data packet. 2- How a last hop (a router which shows interest to receive multicast traffic destined fro (G) or needs to find the source for (G) )learns about active sources? : - 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 wont be a join to RPT for (*,G)). - after RP receives the request it will search the MMT or AMMT(Abriviated-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). - 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 wont be a problem due to the fact that there wont 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. 3- will there be a 30 second delay between the time a source becomes active and a last hop learns about it ? : - since as soon as a source becomes active and the register message is sent to RP the information related to it is saved in MMT or AMMT by the RP, as soon as a client (last hop) comes up with the need to find the source , it will only need to ask the RP. there will be no delay in finding the source. - since after receiving the address of the source there wont be any join to RPT rooted at the RP and the client(last hop) will immediately join the SPT for (G) using the unicast address of the source received from the RP, there wont be any delays and PIM-NG will be one cycle a head of PIM-SM since there is no switching from RPT to SPT . - the above being explained there wont be any delay. - also because in PIM-NG neighbor routers inform each other about the groups they are join the SPT for , if a neighboring PIM-NG router comes up later with the need to find (S) for the same (G) a neighbor is joined the SPT for , there wont be the need to send a request to RP and instead the client will send its join to its neighbor. I hope that the above explanations are satisfactory and i have been able to answer your questions and shed some light over the proposed questions and doubts. the above being explained, one of the advantages of PIM-NG is its source discovery process which at some point works faster than PIM-SM. since this email is getting long i will try to explain other advantages of PIM-NG in a separate email. thanks again and i hope to read the comments and thoughts of other WG members soon. On 04/25/2014 12:54 ق.ظ, Stig Venaas wrote: > 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 > > > > > > > > > From nobody Tue Apr 29 14:20:40 2014 Return-Path: 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 E6D781A0949 for ; Tue, 29 Apr 2014 14:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 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, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 UYQpkDkP_zGU for ; Tue, 29 Apr 2014 14:20:35 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E069C1A0792 for ; Tue, 29 Apr 2014 14:20:34 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id t10so715055eei.5 for ; Tue, 29 Apr 2014 14:20:32 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type; bh=9vbyrIHoOusEKceuIejUS8KhTefj+/LbNBlbqdu5NxA=; b=lb9pF7lbkhNjTBDaZAUHiTEpbZf3cT8SXmvNKpzcFfP7F0nmdVDAXPRB73FhfrLjhD St1TLcfVG0VXYMfAC1k3AA8XiWyYsv7yq+qQIvq3NXhYtbonyd5a0s0v8gdYSeCR9pvq zCjIm5k+ijHZeLnfVAPl69seVBIfDcGQ9gjU0IXNlPL/DmWzFDxoYR1IzwTGzWUjEfpO 6XhOMN1tVFOGp9eUNjSnUsfJq02n86nb69Je1pUn/S+5WC09uGa3yDcJf85ko2QwnpWz PLBr5PuxbEMmzX6Oz7pK/lQA7PF5Xe+Qh8JuNm09m09iXlIewkhg1hqHu+MrckmPR42g BbMg== X-Received: by 10.14.9.195 with SMTP id 43mr109277eet.89.1398806432875; Tue, 29 Apr 2014 14:20:32 -0700 (PDT) Received: from [192.168.1.5] ([178.253.63.174]) by mx.google.com with ESMTPSA id h47sm62271870eey.13.2014.04.29.14.20.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Apr 2014 14:20:32 -0700 (PDT) Message-ID: <536024CE.3000900@gmail.com> Date: Wed, 30 Apr 2014 01:46:46 +0330 From: saeed sami User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stig Venaas References: <53598128.1090107@venaas.com> In-Reply-To: <53598128.1090107@venaas.com> Content-Type: multipart/alternative; boundary="------------050000050706050605090408" Archived-At: http://mailarchive.ietf.org/arch/msg/pim/BCf729o2-VT67cCNzHgABoV0tRQ Cc: pim@ietf.org Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng(part 1) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 21:20:39 -0000 This is a multi-part message in MIME format. --------------050000050706050605090408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 can't be posted to PIM mailing list as a single email, I have to answer in separate parts. and this is part 1 of the series. 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 source discovery method used in PIM-NG in conjunction with other processes with regards to PIM-NG ANYCAST RP concept (many RPs inside the same domain for redundancy and high availability), inter-domain connectivity concepts and how the last hop (client) routers in different multicast domains will be able to find an active source, which provides a hierarchical design approach, seems to be necessary and more optimized. The new source discovery method used eliminates the need for first joining the RPT rooted at the RP and then switch from RPT to SPT by the last hop router (client) and works faster and more optimized and reduces the network resource consumption related to both bandwidth consumption due to RPT trees rooted at RP for each (*,G) or (S,G) , the need for the RP to save the state of RPT trees and also the need for the last hop switch over from RPT to SPT. And putting together all different processes and definitions specifically designed and defined for PIM-NG specifications will clarify the need for a new PIM protocol. These processes and specifications are what making PIM-NG a much more optimized, easily expandable and more secure PIM protocol. Also considering its compatibility with PIM-SM, PIM-NG might be a potential candidate for WG adoption which i hope it happens. I am going to explain about the domain concept in another email explaining some of the advantages of PIM-NG. End of part 1. On 04/25/2014 12:54 ?.?, Stig Venaas wrote: > 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 > > > > > > > > > --------------050000050706050605090408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

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 can't be posted to PIM mailing list as a single email, I have to answer in separate parts. and this is part 1 of the series. 

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 source discovery method used in PIM-NG in conjunction with other processes with regards to PIM-NG ANYCAST RP concept (many RPs inside the same domain for redundancy and high availability), inter-domain connectivity concepts and how the last hop (client) routers in different multicast domains will be able to find an active source, which provides a hierarchical design approach, seems to be necessary and more optimized. The new source discovery method used eliminates the need for first joining the RPT rooted at the RP and then switch from RPT to SPT by the last hop router (client) and works faster and more optimized and reduces the network resource consumption related to both bandwidth consumption due to RPT trees rooted at RP for each (*,G) or (S,G) , the need for the RP to save the state of RPT trees and also the need for the last hop switch over from RPT to SPT.

And putting together all different processes and definitions specifically designed and defined for PIM-NG specifications will clarify the need for a new PIM protocol. These processes and specifications are what making PIM-NG a much more optimized, easily expandable and more secure PIM protocol. Also considering its compatibility with PIM-SM, PIM-NG might be a potential candidate for WG adoption which i hope it happens.

I am going to explain about the domain concept in another email explaining some of the advantages of PIM-NG.

End of part 1.
On 04/25/2014 12:54 ق.ظ, Stig Venaas wrote:
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










--------------050000050706050605090408-- From nobody Tue Apr 29 14:24:44 2014 Return-Path: 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 4DFDD1A0950 for ; Tue, 29 Apr 2014 14:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 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, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 mKP3_uE0q9EQ for ; Tue, 29 Apr 2014 14:24:29 -0700 (PDT) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 218771A0792 for ; Tue, 29 Apr 2014 14:24:28 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id b15so728447eek.6 for ; Tue, 29 Apr 2014 14:24:27 -0700 (PDT) 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; bh=Idlg757kt/tbQZpUHvtfO3C4zG3vGfAmVaw596SgRd4=; b=Ujj9LbIcU6FvQtB3yr3r43lyDIZs8/MAygSPHk/Ss0itjLgm2ltO+f4bpyvfpV3AIu ezyGENfws1JZQ/k3+Hw6/6npcMVdK4Dk03S970B4Z+/F9rE8yTkt5qz5XNGGSuCHxLHy 1hwo+2pOBE/98WhPii61jfuRKxD/wd7rlMUCgDXzLhxlu1QJv+tPjk+544x6ZrDsgipU MQmZFdqDUsmpy4O74EAd3Pm5/ZzDzV3/E9Dzbnd0/NRYgq51ACwCZyaktP546zgRtI95 oyGg++JWzu3ywztSomJz+a3xKmNKMav73pUNzwaGEqRURkt50oCCWNGt3qtgc/FM9bjN IVzw== X-Received: by 10.14.221.2 with SMTP id q2mr239549eep.68.1398806667018; Tue, 29 Apr 2014 14:24:27 -0700 (PDT) Received: from [192.168.1.5] ([178.253.63.174]) by mx.google.com with ESMTPSA id q49sm62295743eem.34.2014.04.29.14.24.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Apr 2014 14:24:26 -0700 (PDT) Message-ID: <536025BA.30001@gmail.com> Date: Wed, 30 Apr 2014 01:50:42 +0330 From: saeed sami User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: pim@ietf.org References: <53598128.1090107@venaas.com> In-Reply-To: <53598128.1090107@venaas.com> Content-Type: multipart/alternative; boundary="------------010802060407000902040309" Archived-At: http://mailarchive.ietf.org/arch/msg/pim/_jBwWfg4rKPwG6-xEf2mDwX-Kao Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng(part1) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 21:24:34 -0000 This is a multi-part message in MIME format. --------------010802060407000902040309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 can't be posted to PIM mailing list as a single email, I have to answer in separate parts. and this is part 1 of the series. 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 source discovery method used in PIM-NG in conjunction with other processes with regards to PIM-NG ANYCAST RP concept (many RPs inside the same domain for redundancy and high availability), inter-domain connectivity concepts and how the last hop (client) routers in different multicast domains will be able to find an active source, which provides a hierarchical design approach, seems to be necessary and more optimized. The new source discovery method used eliminates the need for first joining the RPT rooted at the RP and then switch from RPT to SPT by the last hop router (client) and works faster and more optimized and reduces the network resource consumption related to both bandwidth consumption due to RPT trees rooted at RP for each (*,G) or (S,G) , the need for the RP to save the state of RPT trees and also the need for the last hop switch over from RPT to SPT. And putting together all different processes and definitions specifically designed and defined for PIM-NG specifications will clarify the need for a new PIM protocol. These processes and specifications are what making PIM-NG a much more optimized, easily expandable and more secure PIM protocol. Also considering its compatibility with PIM-SM, PIM-NG might be a potential candidate for WG adoption which i hope it happens. I am going to explain about the domain concept in another email explaining some of the advantages of PIM-NG. End of part 1. On 04/25/2014 12:54 ?.?, Stig Venaas wrote: > 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 > > > > > > > > > --------------010802060407000902040309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

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 can't be posted to PIM mailing list as a single email, I have to answer in separate parts. and this is part 1 of the series. 

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 source discovery method used in PIM-NG in conjunction with other processes with regards to PIM-NG ANYCAST RP concept (many RPs inside the same domain for redundancy and high availability), inter-domain connectivity concepts and how the last hop (client) routers in different multicast domains will be able to find an active source, which provides a hierarchical design approach, seems to be necessary and more optimized. The new source discovery method used eliminates the need for first joining the RPT rooted at the RP and then switch from RPT to SPT by the last hop router (client) and works faster and more optimized and reduces the network resource consumption related to both bandwidth consumption due to RPT trees rooted at RP for each (*,G) or (S,G) , the need for the RP to save the state of RPT trees and also the need for the last hop switch over from RPT to SPT.

And putting together all different processes and definitions specifically designed and defined for PIM-NG specifications will clarify the need for a new PIM protocol. These processes and specifications are what making PIM-NG a much more optimized, easily expandable and more secure PIM protocol. Also considering its compatibility with PIM-SM, PIM-NG might be a potential candidate for WG adoption which i hope it happens.

I am going to explain about the domain concept in another email explaining some of the advantages of PIM-NG.


End of part 1.
On 04/25/2014 12:54 ق.ظ, Stig Venaas wrote:
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










--------------010802060407000902040309-- From nobody Tue Apr 29 15:18:07 2014 Return-Path: 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 9C1471A0953 for ; Tue, 29 Apr 2014 15:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.054 X-Spam-Level: ** X-Spam-Status: No, score=2.054 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 tcbNsLI8tRVI for ; Tue, 29 Apr 2014 15:18:04 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 735E91A09F7 for ; Tue, 29 Apr 2014 15:18:04 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id hn18so946217igb.17 for ; Tue, 29 Apr 2014 15:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=L3d8b9il9WwSybyXhNPRGI626erFUz5RkkgKK8M1GfU=; b=QUoLUbtRUMf3Suc/7KQxcZEDM2PLrpy9yisAmKavdmNaoujfsozTLTtRWVvvZg5NWX BeFhBKRzIxgmqIo9nEky1mAsHqSCqYRTmsAm197wpZt+ctx08SCeWZY4BE1dHLSHyq3k hFhebqomPy+DUlWajQ4N9WSk/MFPy68Ccz+4FHBV4kmStt7stPXMR7c6vdEAjDR1sLbf Qt/hGWptDAiB5kFp69C7DtV6WqkhIiHCY3iJc3O7uMi1zx2QIqSS+7HHUOL0HsyvNllt hjDTpmfZDagM4plnuI1tHJKoyURE08LBxRPTYxFPZLjQ+8c5LPBtDBoK5tzRZpw4f2w1 4VDQ== MIME-Version: 1.0 X-Received: by 10.43.152.14 with SMTP id ku14mr519475icc.60.1398809883232; Tue, 29 Apr 2014 15:18:03 -0700 (PDT) Received: by 10.64.224.141 with HTTP; Tue, 29 Apr 2014 15:18:03 -0700 (PDT) Date: Wed, 30 Apr 2014 01:48:03 +0330 Message-ID: From: saeed sami To: pim Content-Type: multipart/alternative; boundary=001a11c2fdda32d28604f835ce2d Archived-At: http://mailarchive.ietf.org/arch/msg/pim/jlmiLe0v2u2xTyC9Ms-y-XV0ym0 Subject: [pim] draft-sami-pim-ng-02 PIM-NG advantages (part 1) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 22:18:05 -0000 --001a11c2fdda32d28604f835ce2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello. This email might be a little too long but it is worth reading since it is about some of the key advantages of the new proposed protocol, and I hope that it will be read by WG experts. It is related to some of the advantages of PIM-NG the new proposed PIM protocol. The draft can be find at: http://tools.ietf.org/html/draft-sami-pim-ng-02 since It was not possible to send the email at once I will have to send it to the mailing list in separate parts , and this is part 1 of the series. Some of the key advantages of PIM-NG that can make it a potential candidate for adoption by the WG are explained bellow: 1- Different concepts of PIM-NG with regards to RP discovery and other processes are designed in a way to provide an easy to implement (to some extents), automatic or intelligent routing protocol to some extents. This is achieved by introducing new processes and packet types which allow PIM-NG components such as C-RP's, C-MAPPER's and =E2=80=A6 to converge and = fin each other automatically and in the lowest time interval. 2- the definition and role of existing RP'(S) and BSR'(s) weren't clear at least to my eyes which guided me towards a little bit different definition with regards to how the exiting components of a PIM-NG multicast network are introduced to the PIM-NG population. 3- A PIM-NG MAPPER which can be considered as a BSR too, has a more vital role in PIM-NG which makes it possible to follow a hierarchical design pattern. 4- PIM-NG uses a new source register process which makes the size of register packets smaller due to the fact that there will be no need for data packet to be sent alongside the register message. This will reduce the bandwidth and resource consumption since no data packet is sent in a register message. 5- The source discovery method used by PIM-SM seemed a little un-optimized in parts mainly related to a last hop router joining the RPT rooted at the RP first and then switch to SPT. This process is not necessary and is network resource consuming. So a new process is defined in PIM-NG which eliminates the need for the (*, G) RPT tree to form first. The new source discovery method puts PIM-NG one cycle a head of PIM-SM in finding and communicating with a source. End of part 1. --=20 sincerely yours MR.SAEED SAMI --001a11c2fdda32d28604f835ce2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello.

This email might be a little too long but it is worth reading since it is about = some of the key advantages of the new proposed protocol, and I hope that it will be read by WG experts.=C2=A0 It is related to some of the advantages of PIM-NG the new proposed PIM protocol. = The draft can be find at:

=C2=A0http://tools.ietf.org/html/draft-sami= -pim-ng-02 =C2=A0

since It was not possible to send the email at once I will have to send it to the mailing list =C2=A0in separate parts , and this is part 1 of the series.

Some of the key advantages of PIM-NG that can make it a potential candidate for adoption by the WG are explained bellow:

1-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Different concepts of PIM-NG with regards to RP discovery and other processes are designed in a w= ay to provide an easy to implement (to some extents), automatic or intelligent= routing protocol to some extents. This is achieved by introducing new processes and= packet types which allow PIM-NG components such as C-RP's, C-MAPPER's and = =E2=80=A6 to converge and fin each other automatically and in the lowest time interval.<= /p>

2-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 the definition and role of existing RP'(S) and BSR'(s) weren't clear at least to my eyes w= hich guided me towards a little bit different definition with regards to how the exiting components of a PIM-NG multicast network are introduced to the PIM-NG population.

3-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 A PIM-NG MAPPER which can be considered as a BSR too, has a more vital role in PIM-NG which makes it possible to follow a hierarchical design pattern.

4-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 PIM-NG uses a new source register process which makes the size of register packets smaller due to th= e fact that there will be no need for data packet to be sent alongside the re= gister message.=C2=A0 This will reduce the bandwidth and resource consumption since no data packet is sent in a register message= .

5-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 The source discovery method used by PIM-SM seemed a little un-optimized in parts mainly related to a la= st hop router joining the RPT rooted at the RP first and then switch to SPT. T= his process is not necessary and is network resource consuming. So a new proces= s is defined in PIM-NG which eliminates the need for the (*, G) RPT tree to form first. The new source discovery method puts PIM-NG one cycle a head of PIM-= SM in finding and communicating with a source.

End of part 1.=C2=A0--
sincerely yours
MR.SAEED SAMI
--001a11c2fdda32d28604f835ce2d-- From nobody Tue Apr 29 15:22:34 2014 Return-Path: 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 C44D11A0997 for ; Tue, 29 Apr 2014 15:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 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, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 XpuFP-Lskr3s for ; Tue, 29 Apr 2014 15:22:32 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5432B1A0953 for ; Tue, 29 Apr 2014 15:22:32 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id rl12so1039234iec.14 for ; Tue, 29 Apr 2014 15:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=maO0sPHWHWHCXLPnxy3zDLGwMdi6DvaeQoGc0z2Ps8E=; b=VIiGu6pkQCFGTslrYkgaT2SGemX6fLD0spszqfSSOvKjmKA1bkx1fIeFZV/J9l3Vm1 smMmbQuj0IDd1GE4RLXjby6Ug9YXxs8jf+Gcy0DLak0HC51rBiI9LZa1LbZw9yMMAKgn sGsQmMAtvro2xf5iGOxQwelEnBNdQobj6+Zs/jMi/k4zH7eZCByA9vk6csieceNyjtzA UfoZX9C+hV05CHmFaSt9SuHo2YKwmhlBQAaO4v1mOuhQWryYoJnhVQzisB5DtjmxEfoO 0b4FsZksUthi44tqCXBeLjzcv4RTT6nyD+N5sxG0aRBATmYZUxmjsOCFAJ4dyICsLUCZ boGg== MIME-Version: 1.0 X-Received: by 10.43.59.82 with SMTP id wn18mr630134icb.6.1398810150993; Tue, 29 Apr 2014 15:22:30 -0700 (PDT) Received: by 10.64.224.141 with HTTP; Tue, 29 Apr 2014 15:22:30 -0700 (PDT) Date: Wed, 30 Apr 2014 01:52:30 +0330 Message-ID: From: saeed sami To: pim Content-Type: multipart/alternative; boundary=bcaec51961f128857e04f835dec5 Archived-At: http://mailarchive.ietf.org/arch/msg/pim/9tC-lCHy6l1mFazdum6dl-ZPo6I Subject: [pim] draft-sami-pim-ng-02 PIM-NG advantages (part 2) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 22:22:33 -0000 --bcaec51961f128857e04f835dec5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello. This email might be a little too long but it is worth reading and I hope that it will be read by WG experts. It is related to some of the advantages of PIM-NG the new proposed PIM protocol. The draft can be find at: http://tools.ietf.org/html/draft-sami-pim-ng-02 since It was not possible to send the email at once I will have to send it to the mailing list in separate parts , and this is part2 of the series. Some of the key advantages of PIM-NG that can make it a potential candidate for adoption by the WG are explained bellow: 6- Since the role of an RP is similar to an information station which only helps last hop routers (clients) find the source of a multicast traffic (G), large number of last hops won't cause any problem in a PIM-NG domain. This is achieved due to the fact that the RP doesn=E2=80=99t need t= o save the state of every (*, G) join it receives before a last hop switches to SPT and actually there is no RPT tree formations. 7- Since as soon as a source is registered with the RP, clients (last hop router) will only need to send a unicast-encapsulated request for source message to the RP and as soon as the unicast address of the source is received back from the RP they will join the SPT tree there will be no delay at all in communicating with a source and receiving the multicast traffic it represents. 8- PIM-NG uses a new ANYCAST RP and Mesh-Group concept, which if implemented correctly, allows for the existence of many RPs in a single multicast domain while reducing the network resource consumption by the multicast introduction messages sent by RPs and also reduces the amount of Active source advertisements within a domain. In a single multicast domain the number of existing RPs can be up to 255 RPs which if the PIM-NG Sub-Domain concept is implemented correctly , the number of existing RPs in a multicast domain can be increased to up to 254*255 conceptually , which will provide high availability in its maximum level. 9- Since the current multicast domain definition and RPF check method in use by PIM-SM and MSDP doesn=E2=80=99t allow the existence of transitory Autonomous System'(s) or multicast domains, PIM-NG introduces its unique multicast domain concept alongside a new RPF check method unique to PIM-NG specifications which allows the existence of transitory multicast domains. 10- The new RPF check method introduced in PIM-NG gives a higher level of control and security with regards to propagation and advertisement of the information regarding the active sources. Dou to its nature which allows the existence of transitory multicast domains and because the RPF check method and how different multicast domains are connected in PIM-NG, administrators will have a flexible and easy control over the Active sources advertisements. 11- Because of the new and unique multicast domain concept introduced, PIM-NG provides a higher level of control over multicast networks through the concept of Sub-Domain alongside a higher level of security which is indeed a positive factor for any protocol through the implementation of Stub-Domains. Both of the concepts are unique to PIM-NG. End of part 2. --=20 sincerely yours MR.SAEED SAMI --bcaec51961f128857e04f835dec5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello.

This email might be a little too long but it is worth reading and I hope that it will be read by WG experts.=C2=A0 It is related to some of the advantages of PIM-NG the new proposed PIM protocol. = The draft can be find at:

=C2=A0http://tools.ietf.org/html/draft-sami= -pim-ng-02 =C2=A0

since It was not possible to send the email at once I will have to send it to the mailing list =C2=A0in separate parts , and this is part2 of the series.

Some of the key advantages of PIM-NG that can make it a potential candidate for adoption by the WG are explained bellow:


6-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Since the role of an RP is similar to an information station which only helps last hop routers (client= s) find the source of a multicast traffic (G), large number of last hops won&#= 39;t cause any problem in a PIM-NG domain. This is achieved due to the fact that the R= P doesn=E2=80=99t need to save the state of every (*, G) join it receives bef= ore a last hop switches to SPT and actually there is no RPT tree formations.

7-=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Since as soon as a source is registered with the RP, clients (last hop router) will only need to send= a unicast-encapsulated request for source message to the RP and as soon as th= e unicast address of the source is received back from the RP they will join t= he SPT tree there will be no delay at all in communicating with a source and receiving the multicast traffic it represents.

8-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PIM-NG uses a new ANYCAST RP and Mesh-Group concept, which if implemented correctly, allows for the e= xistence of many RPs in a single multicast domain while reducing the network resourc= e consumption by the multicast introduction messages sent by RPs and also red= uces the amount of Active source advertisements within a domain. In a single multicast domain the number of existing RPs can be up to 255 RPs which if t= he PIM-NG Sub-Domain concept is implemented correctly , the number of existing= RPs in a multicast domain can be increased to up to 254*255 conceptually , whic= h will provide high availability in its maximum level.

9-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Since the current multicast domain definition and RPF check method in use by PIM-SM and MSDP doesn=E2= =80=99t allow the existence of transitory Autonomous System'(s) or multicast domains,= PIM-NG introduces its unique multicast domain concept alongside a new RPF check me= thod unique to PIM-NG specifications which allows the existence of transitory multicast domains.

10-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The new RPF check method introduced in PIM-NG gives a higher level of control and security with rega= rds to propagation and advertisement of the information regarding the active sources. Dou to its nature which allows the existence of transitory multica= st domains and because the RPF check method and how different multicast domain= s are connected in PIM-NG, administrators will have a flexible and easy contr= ol over the Active sources advertisements.

11-=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Because of the new and unique multicast domain concept introduced, PIM-NG provides a higher level = of control over multicast networks through the concept of Sub-Domain alongside= a higher level of security which is indeed a positive factor for any protocol through the implementation of Stub-Domains. Both of the concepts are unique= to PIM-NG.

End of part 2.
--
sincerely yours
MR.SAEED SAMI
--bcaec51961f128857e04f835dec5-- From nobody Tue Apr 29 15:25:06 2014 Return-Path: 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 E2A1A1A0953 for ; Tue, 29 Apr 2014 15:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 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, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 v-wilP5zhQ9T for ; Tue, 29 Apr 2014 15:25:03 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9E11A094B for ; Tue, 29 Apr 2014 15:25:03 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id tp5so989158ieb.27 for ; Tue, 29 Apr 2014 15:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=4/SpZA3BpHZu56l5dOdCqjHbHGxzYKKXgtO+INJEgAo=; b=qq9hW1KwSSSTOeJ1nDKWXk29zXAAAtzICZN05IkEMWbe59Ch65AU1Mclxu7sLRgmHw jFeJm3g2Wwc5jcKQxiSxrA3ftjQ8LjavKDTT38ECR9dHhRYOKk5lsJOSn8wzDb6s56O1 WM7ibhYj5D8Sl2tLGisA1OgvuZXYrs46x0EFnKaGY4J0kAVJ2bCZBumwAhPwuAaEHKae vgPbcLcr+Ja2suSDS8T4VvTdjxLqVNeDjK3XFRhrHD7uBErWtPSQNNVAkiAZSTQG7dHl I1vIlfbX01Q+hoSPAH1d1jQ/pg5V9otr+UhkGfAyXiinS51rCzit/AvSekJo9EhdhQ7P QOfw== MIME-Version: 1.0 X-Received: by 10.50.131.130 with SMTP id om2mr34089699igb.25.1398810301892; Tue, 29 Apr 2014 15:25:01 -0700 (PDT) Received: by 10.64.224.141 with HTTP; Tue, 29 Apr 2014 15:25:01 -0700 (PDT) Date: Wed, 30 Apr 2014 01:55:01 +0330 Message-ID: From: saeed sami To: pim Content-Type: multipart/alternative; boundary=047d7b2e10e7270e7d04f835e7be Archived-At: http://mailarchive.ietf.org/arch/msg/pim/FSc1SIa-KhkwwTmQF7U1zk3Fq1k Subject: [pim] draft-sami-pim-ng-02 PIM-NG advantages (part 3) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 22:25:05 -0000 --047d7b2e10e7270e7d04f835e7be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello. This email might be a little too long but it is worth reading and I hope that it will be read by WG experts. It is related to some of the advantages of PIM-NG the new proposed PIM protocol. The draft can be find at: http://tools.ietf.org/html/draft-sami-pim-ng-02 since It was not possible to send the email at once I will have to send it to the mailing list in separate parts , and this is part 3 of the series. Some of the key advantages of PIM-NG that can make it a potential candidate for adoption by the WG are explained bellow: 12- The last but not the least advantage of PIM-NG is providing more security and reducing network resource consumption in parts of multicast domain/networks connected to Multi-Access networks. This feature is beneficial specifically to Service Providers due to the fact that through implementing this feature, downstream last hop (client) within a connected Multi-Access network won't need to receive any vital information form Service Providers regarding the existing key components of service provider's multicast domain. Such behavior is indeed beneficial in scenarios in which a customer wishes to use the service provider's services for its multi-access network's multicast connectivity without the need to implement C-MAPPER'(s), C-RP'(s) and other key components. Since in PIM-SM RP or BSR introduction messages must propagate to downstream last hop routers within multi-access networks there will be an unwanted network resource consumption and also it can cause security issues to some extents. The above advantages alongside other features and definitions introduced by PIM-NG have the ability to make PIM-NG a potential candidate for adoption by the WG and I hope that the ID will be able to draw the attention of WG experts to itself. So I hope that this ID is given the chance by the WG. There is one issue with regards to the RPF check method: 1- A concept of Domain-set is introduced which is in fact a string of domain numbers or better to call Domain-Path string. The domain-set is used for the RPF-Check and can get long. If the length of the Domain-Set isn=E2= =80=99t an issue then there wont be a problem. But if the length can be an issue then a mechanism should be implemented so that the C-MAPPERs which are in charge of inter-Domain connectivity with regards to advertisement of Active multicast sources will automatically reduce the length of the string. - My proposed solution is to use a mechanism so that each 10 domain numbers in the domain-set of a received advertisement is replaced by a unique number at the time of advertising to neighbor domains. For instance considering that C-MAPPER-B receives an advertisement form C-MAPPER-A with domain-set (12,11,10,9,8,7,6,5,4,3 ,1) and needs to advertise it to C-MAPPER-C. so with the proposed solution C-MAPPER-B will send an advertisement with Domain-Set(X,1,2) which X represents those 10 domain numbers and 1 the domain in which C-MAPPER-A resides and 2 the domain in which C-MAPPER-B resides. The above issue and the proposed solution need a review from WG group experts. in case the length of Domain-Set is not a real issue it is better be left the way defined as it may be used for a new concept later if the ID is adopted . The above being said , I can say that PIM-NG works much more optimized than PIM-SM in many ways starting From reducing the time through which a last hope router(client) can join the SPT for (S,G) to providing the ability to implement transitory multicast domains and providing a higher level of security in multicast domains. At the end I hope the ID "draft-sami-pim-ng" will be seen worthy of being adopted by the working group END. --=20 sincerely yours MR.SAEED SAMI --047d7b2e10e7270e7d04f835e7be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello.

This email might be a little too long but it is worth reading and I hope that it will be read by WG experts.=C2=A0 It is related to some of the advantages of PIM-NG the new proposed PIM protocol. = The draft can be find at:

=C2=A0http://tools.ietf.org/html/draft-sami= -pim-ng-02 =C2=A0

since It was not possible to send the email at once I will have to send it to the mailing list =C2=A0in separate parts , and this is part 3 of the series.

Some of the key advantages of PIM-NG that can make it a potential candidate for adoption by the WG are explained bellow:


12-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 The last but not the least advantage of PIM-NG is providing more security and reducing network resourc= e consumption in parts of multicast domain/networks connected to Multi-Access networks. This feature is beneficial specifically to Service Providers due = to the fact that through implementing this feature, downstream last hop (clien= t) within a connected Multi-Access network won't need to receive any vital information form Service Providers regarding the existing key components of= service provider's multicast domain. Such behavior is indeed beneficial in scen= arios in which a customer wishes to use the service provider's services for its multi-access network's multicast connectivity without the need to imple= ment C-MAPPER'(s), C-RP'(s) and other key components. Since in PIM-SM RP= or BSR introduction messages must propagate to downstream last hop routers within multi-access networks there will be an unwanted network resource consumption and also it= can cause security issues to some extents.

=C2=A0

The above a= dvantages alongside other features and definitions introduced by PIM-NG have the ability to make PIM-NG a potentia= l candidate for adoption by the WG and I hope that the ID will be able to dra= w the attention of WG experts to itself. So I hope that this ID is given the chance by the WG.

=C2=A0

There is on= e issue with regards to the RPF check method:

1-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 A concept of Domain-set is introduced which is in fact a string of domain numbers or better to call Domain-Path string. The domain-set is used for the RPF-Check and can get lo= ng. If the length of the Domain-Set isn=E2=80=99t an issue then there wont be a= problem. But if the length can be an issue then a mechanism should be implemented so tha= t the C-MAPPERs which are in charge of inter-Domain connectivity with regards= to advertisement of Active multicast sources will automatically reduce the length of the str= ing.

=C2=A0 =C2= =A0 =C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 My proposed solution is to use a mechanism so that each 10 domain numbers in the domain-set of a recei= ved advertisement is replaced by a unique number at the time of advertising to = neighbor domains. For instance considering that C-MAPPER-B receives an advertisement form C-MAPPER-A with domain-set (12,11,10,9,8,7,6,5,4,3 ,1) and needs to advertise it to C-MAPPER-C. so with the proposed solution C-MAPPER-B will s= end an advertisement with Domain-Set(X,1,2) which X represents those 10 domain numbers and 1 the domain in which C-MAPPER-A resides and 2 the domain in wh= ich C-MAPPER-B resides.

The above i= ssue and the proposed solution need a review from WG group experts. in case the length of Domain-Set is not a real issue= it is better be left the way defined as it may be used for a new concept =C2= =A0later if the ID is adopted .

The above b= eing said , I can say that PIM-NG works much more optimized than PIM-SM in many ways starting From reducing the time thr= ough which a last hope router(client) can join the SPT for (S,G) to providing th= e ability to implement transitory multicast domains and =C2=A0providing a hig= her level of security in multicast domains.

At the end I hope the ID "draft-sami-pim-ng" will be seen worthy of being adopted by the working group
<= div>
END.
--
sincerely yours
MR.SAEED SAMI
--047d7b2e10e7270e7d04f835e7be-- From nobody Tue Apr 29 15:52:14 2014 Return-Path: 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 E08761A0953 for ; Tue, 29 Apr 2014 15:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 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, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 WtBOSYWBsavV for ; Tue, 29 Apr 2014 15:52:08 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id BC5A11A096B for ; Tue, 29 Apr 2014 15:52:08 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id c1so969909igq.7 for ; Tue, 29 Apr 2014 15:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YiwsLxJh+M7Wtwcr1XqdYoAraw0T3odVJHzlAIr16WE=; b=uR1kYnDnMIjALhaACyUJNK+rC20+5aobNepG1ZlsJi5heYg9UUd1L5q5EPomWlKt2G faEclhRUrY/UHWOfQAHY2fR8pThmpZ0wzVOnrr07qTenmI2qBiBmjhdc8P5vpkIe5UAW 5N37oIYSEBTQu96AzrO+zDQqJFHqrT6m6Jdrl0v6ndK4FZF51QyQLckFymrSnYMOFOJm SVwhhCR18lqHKlSclIxXfp036QgAlp4qiMUcjmzSSbOmTxxdxHbqx5izvJR1nFSWitN6 hS/8/HTo59BurviygqANU0UeIQrGkTXbXSAXGC/rBwVNdS4EGtQu5kr8iRroo4GahwX+ 9WQg== MIME-Version: 1.0 X-Received: by 10.43.140.144 with SMTP id ja16mr689549icc.46.1398811927436; Tue, 29 Apr 2014 15:52:07 -0700 (PDT) Received: by 10.64.224.141 with HTTP; Tue, 29 Apr 2014 15:52:07 -0700 (PDT) Date: Wed, 30 Apr 2014 02:22:07 +0330 Message-ID: From: saeed sami To: pim Content-Type: multipart/alternative; boundary=001a11c1e8c00ae30604f83648af Archived-At: http://mailarchive.ietf.org/arch/msg/pim/TbZGZZNVmSekSuO0SPVPdp_qjOg Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng (part 1) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 22:52:11 -0000 --001a11c1e8c00ae30604f83648af Content-Type: text/plain; charset=UTF-8 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 can't be posted to PIM mailing list as a single email, I have to answer in separate parts. and this is part1 of the series. 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 source discovery method used in PIM-NG in conjunction with other processes with regards to PIM-NG ANYCAST RP concept (many RPs inside the same domain for redundancy and high availability), inter-domain connectivity concepts and how the last hop (client) routers in different multicast domains will be able to find an active source, which provides a hierarchical design approach, seems to be necessary and more optimized. The new source discovery method used eliminates the need for first joining the RPT rooted at the RP and then switch from RPT to SPT by the last hop router (client) and works faster and more optimized and reduces the network resource consumption related to both bandwidth consumption due to RPT trees rooted at RP for each (*,G) or (S,G) , the need for the RP to save the state of RPT trees and also the need for the last hop switch over from RPT to SPT. And putting together all different processes and definitions specifically designed and defined for PIM-NG specifications will clarify the need for a new PIM protocol. These processes and specifications are what making PIM-NG a much more optimized, easily expandable and more secure PIM protocol. Also considering its compatibility with PIM-SM, PIM-NG might be a potential candidate for WG adoption which i hope it happens. I am going to explain about the domain concept in another email explaining some of the advantages of PIM-NG. End of part 1. On Fri, Apr 25, 2014 at 10:32 PM, wrote: > Send pim mailing list submissions to > pim@ietf.org > > 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 > pim-request@ietf.org > > You can reach the person managing the list at > pim-owner@ietf.org > > 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 > To: saeed sami , pim > Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng > Message-ID: <53598128.1090107@venaas.com> > 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 --001a11c1e8c00ae30604f83648af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear Mr.Venaas,=C2=A0Hello=C2=A0
First of all let me thank you for your review, comments and the time you ha= ve=C2=A0
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 can't be= posted to PIM mailing list as a single email, I have to answer in separate= parts. and this is part1 of the series.=C2=A0

Please kindly find the answers and explanations to your q= uestions and doubts bellow. i hope that as you mentioned in your email ther= e will be more comments from other members after this.=C2=A0=C2=A0


The source disc= overy method used in PIM-NG in conjunction with other processes with regard= s to PIM-NG ANYCAST RP concept (many RPs inside the same domain for redunda= ncy and high availability), inter-domain connectivity concepts and how the = last hop (client) routers in different multicast domains will be able to fi= nd an active source, which provides a hierarchical design approach, seems t= o be necessary and more optimized. The new source discovery method used eli= minates the need for first joining the RPT rooted at the RP and then switch= from RPT to SPT by the last hop router (client) and works faster and more = optimized and reduces the network resource consumption related to both band= width consumption due to RPT trees rooted at RP for each (*,G) or (S,G) , t= he need for the RP to save the state of RPT trees and also the need for the= last hop switch over from RPT to SPT.

And putting together all different processes and definitions specifically = designed and defined for PIM-NG specifications will clarify the need for a = new PIM protocol. These processes and specifications are what making PIM-NG= a much more optimized, easily expandable and more secure PIM protocol. Als= o considering its compatibility with PIM-SM, PIM-NG might be a potential ca= ndidate for WG adoption which i hope it happens.

I am going to explain about the domain concept in another email explaining= some of the advantages of PIM-NG.


End of part= 1.



On Fri, Apr 2= 5, 2014 at 10:32 PM, <pim-request@ietf.org> wrote:
Send pim mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pim@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/pim
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pim-req= uest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pim-owner= @ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of pim digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: New updated and edited version of draft-sami-pim-ng
=C2=A0 =C2=A0 =C2=A0 (Stig Venaas)
=C2=A0 =C2=A02. Re: New updated and edited version of draft-sami-pim-ng
=C2=A0 =C2=A0 =C2=A0 (saeed sami)


----------------------------------------------------------------------

Message: 1
Date: Thu, 24 Apr 2014 14:24:56 -0700
From: Stig Venaas <stig@venaas.com>
To: saeed sami <sami.biz.ema= il@gmail.com>, pim <pim@ietf.org<= /a>>
Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng
Message-ID: <53598128.109= 0107@venaas.com>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

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:
> =C2=A0 =C2=A0 This document specifies protocol independent multicast- = Next
> =C2=A0 =C2=A0 generation or simply called PIM-NG. like PIM-SM, PIM-NG = uses the
> =C2=A0 =C2=A0 underlying unicast routing information, but unlike PIM-S= M it doesn't
> =C2=A0 =C2=A0 necessarily need to build unidirectional shared trees ro= oted at a
> =C2=A0 =C2=A0 Rendezvous Point (RP) per group, due to the fact that th= e processes
> =C2=A0 =C2=A0 through which a source registers with the Rendezvous Poi= nt and a host
> =C2=A0 =C2=A0 finds the source of the multicast destination groups it = needs are
> =C2=A0 =C2=A0 done in a whole new way. So at some points PIM-NG works = faster than
> =C2=A0 =C2=A0 its predecessor. Also the new Domain concept, unique to = PIM-NG, along
> =C2=A0 =C2=A0 the RPF check method used in PIM-NG specifications provi= des many
> =C2=A0 =C2=A0 features along a robust and flexible control and adminis= tration over
> =C2=A0 =C2=A0 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
--001a11c1e8c00ae30604f83648af-- From nobody Tue Apr 29 15:55:04 2014 Return-Path: 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 7B1471A09BA for ; Tue, 29 Apr 2014 15:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 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, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 5g-aipJDEwH6 for ; Tue, 29 Apr 2014 15:54:59 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id E63AC1A09B0 for ; Tue, 29 Apr 2014 15:54:58 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id y20so948247ier.26 for ; Tue, 29 Apr 2014 15:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Xh2Z4HuZznpzNv3ZUmX9SfXARUJ19+NafMvyyEQ7Yjs=; b=aTa4Nk3/6QIxFCyiHJHcFNZAVw0gmMKIq4d8u5WCRccynlkeZqezGRSQGhTDXaKIto qUX86G8LkYN8fGilCtuNlP8XRZcQIhXyBe56UBPwlPplkQBCHuFimmk6RHwvpCc3vnYC QMKr1N1dg0PsHoQjOAP6ey2Sx+oBnPKvsHrKUDgeq6My+yPB9lPPnland9jLF/cBN2Ky miSUNKzNt2j4hHOfNipdj2gufYI1kh68rZQ7sh8I61rLWww8Jf5zN3yjwbteEBQi+/30 shxOcpt4gTMVGqNxBpKp4F7APGdfoEDNHVdJOwqucmgY1EvFq71ylKANiMz9MZ/K0BeM nFlQ== MIME-Version: 1.0 X-Received: by 10.50.25.136 with SMTP id c8mr34185667igg.26.1398812097568; Tue, 29 Apr 2014 15:54:57 -0700 (PDT) Received: by 10.64.224.141 with HTTP; Tue, 29 Apr 2014 15:54:57 -0700 (PDT) Date: Wed, 30 Apr 2014 02:24:57 +0330 Message-ID: From: saeed sami To: pim Content-Type: multipart/alternative; boundary=047d7bdc1bf42ee98204f8365232 Archived-At: http://mailarchive.ietf.org/arch/msg/pim/PL1KQWNOqsGle7U07IelNBD3klE Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng (part 2) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 22:55:01 -0000 --047d7bdc1bf42ee98204f8365232 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=E2=80=99t received any join messages for the (G) a so= urce 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, wrote: > Send pim mailing list submissions to > pim@ietf.org > > 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 > pim-request@ietf.org > > You can reach the person managing the list at > pim-owner@ietf.org > > 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 > To: saeed sami , pim > Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng > Message-ID: <53598128.1090107@venaas.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > 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 ho= st > > 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, alo= ng > > the RPF check method used in PIM-NG specifications provides many > > features along a robust and flexible control and administration ove= r > > 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 --047d7bdc1bf42ee98204f8365232 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear Mr.Venaas,=C2=A0Hello=C2=A0
First of all let me thank you for your review, comments and the time you ha= ve=C2=A0
dedicated to review my work "draft-sami-pim-ng-02".

<= p class=3D"MsoNormal" style=3D"font-family:arial,sans-serif;font-size:13px;= direction:ltr"> 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 separ= ate =C2=A0parts. and this is part 2.

Please kindly find the answers and ex= planations to your questions and doubts bellow. i hope that as you mentione= d in your email there will be more comments from other members after this.= =C2=A0

=C2=A0

The answer to y= our questions are as follows which I hope will be satisfying:=C2=A0

= 1- Source register process=C2=A0=C2=A0in PIM-NG and its similarity to PI= M-SM:


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

=


-=C2=A0=C2= =A0Source sends a unicast-encapsulated register message to the address of t= he=C2=A0
RP which only contains the unicast address of the source and mu= lticast group=C2=A0
(G) it represents. This register message does not contain data packet.


-=C2=A0=C2=A0RP receives the register message and saves the information wit= hin the register=C2=A0
message inside a table called Multicast Mapping T= able (MMT). The RP puts an entry=C2=A0
in MMT containing the unicast add= ress of the source and the multicast group (G)=C2=A0
it represents alongside other information related to the source for further= use.=C2=A0
-=C2=A0=C2=A0After puting an entry in MMT RP will send back = an acknowledge to the source=C2=A0
which indicates the successful regist= ration of the information sent by source.

=C2=A0
-=C2=A0=C2=A0after receiving the acknowledge from the RP source = will start sending keep-alive=C2=A0
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=E2=80=99t received any join messages for the (G) a so= urce 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)=C2=A0=C2=A0to accept=C2=A0 a register message or join the RPT for= (*,G) there will be only an acknowledge and a=C2=A0
keep-alive.


-=C2=A0 the initial data packet do= es not need to be sent=C2=A0 because the overall process through which a la= st hop router (client) finds a source differs completely from that of PIM-S= M.

2- How a last hop (a router which shows interest to receive multicas= t traffic=C2=A0
destined for (G) or needs to find the source for (G) )le= arns about active sources? Source-discovery:=C2=A0

- in PIM-NG a= nd 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 sa= ves the=C2=A0
information regarding active sources within the Domain in MMT, last hop (cl= ient)=C2=A0
doesnt need to know about all the active sources within the = Domain.


- consideri= ng the above, a client will contact the RP in case it needs to find the=C2= =A0
source of multicast traffic destined for (G) by sending a unicast-en= capsulated=C2=A0
request for source message to the RP indicating that it needs to find (S) f= or (G).=C2=A0
((there won't be a join to RPT for (*, G).))=

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

- If an entry i= s found in MMT or AMMT the RP will send a unicast-encapsulated=C2=A0
ack= nowledge back to the client using the client's unicast address. This ac= knowledge=C2=A0
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 t= he client.


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

-=C2=A0= =C2=A0A 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 sou= rce of a multicast traffic.=C2=A0

End of part 2.



On Fri, Apr 25, 2014 at 10:32 = PM, <pim-request@ietf.org> wrote:
Send pim mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pim@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/pim
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pim-req= uest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pim-owner= @ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of pim digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: New updated and edited version of draft-sami-pim-ng
=C2=A0 =C2=A0 =C2=A0 (Stig Venaas)
=C2=A0 =C2=A02. Re: New updated and edited version of draft-sami-pim-ng
=C2=A0 =C2=A0 =C2=A0 (saeed sami)


----------------------------------------------------------------------

Message: 1
Date: Thu, 24 Apr 2014 14:24:56 -0700
From: Stig Venaas <stig@venaas.com>
To: saeed sami <sami.biz.ema= il@gmail.com>, pim <pim@ietf.org<= /a>>
Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng
Message-ID: <53598128.109= 0107@venaas.com>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

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:
> =C2=A0 =C2=A0 This document specifies protocol independent multicast- = Next
> =C2=A0 =C2=A0 generation or simply called PIM-NG. like PIM-SM, PIM-NG = uses the
> =C2=A0 =C2=A0 underlying unicast routing information, but unlike PIM-S= M it doesn't
> =C2=A0 =C2=A0 necessarily need to build unidirectional shared trees ro= oted at a
> =C2=A0 =C2=A0 Rendezvous Point (RP) per group, due to the fact that th= e processes
> =C2=A0 =C2=A0 through which a source registers with the Rendezvous Poi= nt and a host
> =C2=A0 =C2=A0 finds the source of the multicast destination groups it = needs are
> =C2=A0 =C2=A0 done in a whole new way. So at some points PIM-NG works = faster than
> =C2=A0 =C2=A0 its predecessor. Also the new Domain concept, unique to = PIM-NG, along
> =C2=A0 =C2=A0 the RPF check method used in PIM-NG specifications provi= des many
> =C2=A0 =C2=A0 features along a robust and flexible control and adminis= tration over
> =C2=A0 =C2=A0 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
--047d7bdc1bf42ee98204f8365232-- From nobody Tue Apr 29 15:57:02 2014 Return-Path: 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 6CD5C1A09AD for ; Tue, 29 Apr 2014 15:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 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, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 k7QI9g3wg3PN for ; Tue, 29 Apr 2014 15:56:58 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC7B1A0992 for ; Tue, 29 Apr 2014 15:56:58 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id to1so1020558ieb.2 for ; Tue, 29 Apr 2014 15:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vGcXS1/q8OVEuwMzBZqYv7o1CBD+fFMa+IdHY0UY9qA=; b=I+jdTGpsF528zxduQ+hc5PVGuuVrAT1tPeS+tM8q+4kokL9Njiq3+AGtgu9jUgqhSk Sg6Tm1Vy384g5+JYuXnaL4p4KPib97PpzAVeXtxxxv402rXrgbTg08Xh8eWx4N1Spbo5 QlfYWE7bQYmuLLR/ZOibX5qorbJqgNmTvfxTHQQhJuYsvSVJNeRx11EpBllXKluteTAm WKW7hqKYtbjbMipLgwZLhOxzWR4GEzz+9omAmfepEJFnI3gEVUWpVETTGa20KJQYABPF glvIewq6knekAyM6yibEfsuCkGI9Pt1cpinWnksfaySc08Qu+qs4kMvagObB7TgSaj5Q 5ETw== MIME-Version: 1.0 X-Received: by 10.43.58.19 with SMTP id wi19mr554193icb.53.1398812216834; Tue, 29 Apr 2014 15:56:56 -0700 (PDT) Received: by 10.64.224.141 with HTTP; Tue, 29 Apr 2014 15:56:56 -0700 (PDT) Date: Wed, 30 Apr 2014 02:26:56 +0330 Message-ID: From: saeed sami To: pim Content-Type: multipart/alternative; boundary=bcaec51f96634acd0f04f83659d6 Archived-At: http://mailarchive.ietf.org/arch/msg/pim/Ar2JsHTpz2H1qCJB2gwGDKx0bNo Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng (part 3) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 22:57:00 -0000 --bcaec51f96634acd0f04f83659d6 Content-Type: text/plain; charset=UTF-8 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 can't be posted to PIM mailing list as a single email, I have to answer in separate parts. and this is part 3 of the series. 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: *3- Will there be a 30 second delay between the time a source becomes active and a last hop learns about it? : * - since as soon as a source becomes active and the register message is sent to RP the information related to it is saved in MMT or AMMT by the RP, as soon as a client (last hop) comes up with the need to find the source , it will only need to ask the RP. There will be no delay in finding the source. - since after receiving the address of the source there won't be any join to RPT rooted at the RP and the client (last hop) will immediately join the SPT for (G) using the unicast address of the source received from the RP, there won't be any delays and PIM-NG will be one cycle a head of PIM-SM since there is no switching from RPT to SPT. - The above being explained there won't be any delay. - Also because in PIM-NG neighbor routers inform each other about the groups they are join the SPT for, if a neighboring PIM-NG router comes up later with the need to find (S) for the same (G) a neighbor is joined the SPT for, there won't be the need to send a request to RP and instead the client will send its join to its neighbor. *4-* *What will be the impacts of avoiding data registers and shared Trees? * let us consider that a host behind a last hop (client) that needs to receive multicast traffic usable by the installed and active applications will need to send a request to the upstream client (last hop) , and after this the client (last hop) will be in charge of finding the source for that multicast traffic group by asking the existing RP. now what differs here from PIM-SM is that at this point a last hop in pim-sm will have to send a join towards the RP and join the RPT to receive the multicast traffic on RPT tree and after receiving first couple of data packets and understanding the unicast address of the source will switch to SPT and send a join towards the source itself. But in PIM-NG instead of joining the RPT for (G) the last hop (client) receives the unicast address of the source from the RP and directly sends a join towards the source and joins the SPT. the new process is much more optimized and actually one cycle ahead of PIM-SM causing the reduction in bandwidth and resource consumption due to elimination of RPT joins. also considering that if right after the RP sends a register stop to the source of (G), a last hop shows interest in receiving that traffic by joining the RPT, the RP will have to either forward the join towards the source so that the source will be able to join the RPT too or wait till the next time it receives the null register from the source, there will be a waste of valuable network resource and time. but in PIM-NG there is no need for this since the process is much more faster and at any time a last hop (client) needs to receive a traffic destined for (G) it will only need to ask the address of source and directly and if the source is active immediately join the SPT without the need for a switch over from RPT to SPT. I hope that the above explanations are satisfactory and I have been able to answer your questions and shed some light over the proposed questions and doubts. the above being explained, one of the advantages of PIM-NG is its source discovery process which at some point works faster than PIM-SM. since this email is getting long i will try to explain other advantages of PIM-NG in a separate email. Thanks again and I hope to read the comments and thoughts of other WG members soon. End On Fri, Apr 25, 2014 at 10:32 PM, wrote: > Send pim mailing list submissions to > pim@ietf.org > > 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 > pim-request@ietf.org > > You can reach the person managing the list at > pim-owner@ietf.org > > 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 > To: saeed sami , pim > Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng > Message-ID: <53598128.1090107@venaas.com> > 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 --bcaec51f96634acd0f04f83659d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear Mr.Venaas,=C2=A0Hello=C2=A0
First of all let me thank you for your review, comments and the time you ha= ve=C2=A0
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 can't be= posted to PIM mailing list as a single email, I have to answer in separate= parts. and this is part 3 of the series.=C2=A0

Please kindly find the answers and explanations to your q= uestions and doubts bellow. i hope that as you mentioned in your email ther= e will be more comments from other members after this.=C2=A0=C2=A0

The answer to y= our questions are as follows which I hope will be satisfying:

=C2=A03- Will there = be a 30 second delay between the time a source becomes active and a last ho= p learns about it? :=C2=A0

- since as soon as a source becomes active and the = register message is sent to RP=C2=A0
the information related to it is saved in MMT or AMMT by the RP, as soon as= a=C2=A0
client (last hop) comes up with the need to find the source , i= t will only need to=C2=A0
ask the RP. There will be no delay in finding = the source.

- since after receiving the address of the source there won= 9;t be any join to RPT=C2=A0
rooted at the RP and the client (last hop) will immediately join the SPT fo= r (G) using=C2=A0
the unicast address of the source received from the RP= , there won't be any delays=C2=A0
and PIM-NG will be one cycle a hea= d of PIM-SM since there is no switching from=C2=A0
RPT to SPT.

- The above being explaine= d there won't be any delay.

- Also because = in PIM-NG neighbor routers inform each other about the groups=C2=A0<= br style=3D"font-family:arial,sans-serif;font-size:13px">

they are join t= he SPT for, if a neighboring PIM-NG router comes up later with the=C2=A0need to find (S) for the same (G) a neighbor is joined the SPT for, there = won't be=C2=A0
the need to send a request to RP and instead the client will send its join = to its=C2=A0
neighbor.=C2=A0=C2=A0

4- What will =
be the impacts of avoiding data registers and shared Trees? <=
/b>
=C2=A0
let us consider= that a host behind a last hop (client) that needs to receive multicast tra= ffic usable by the installed and active applications will need to send a re= quest to the upstream client (last hop) , and after this the client (last h= op) will be in charge of finding=C2=A0=C2=A0the source for that multicast t= raffic group by asking the existing RP. now what differs here from PIM-SM i= s that at this point a last hop in pim-sm will have to send a join towards = the RP and join the RPT to receive the multicast traffic on RPT tree and af= ter receiving first couple of data packets and understanding the unicast ad= dress of the source will switch to SPT and send a join towards the source i= tself. But in PIM-NG instead of joining the RPT for (G) the last hop (clien= t) receives the unicast address of the source from the RP and directly send= s a join towards the source and joins the SPT. the new process is much more= optimized and actually one cycle ahead of PIM-SM causing the reduction in = bandwidth and resource consumption due to elimination of RPT joins.=C2=A0
also considering that if right after the RP sends a register stop to th= e source of (G), a last hop shows interest in receiving that traffic by joi= ning the RPT, the RP will have to either forward the join towards the sourc= e so that the source will be able to join the RPT too or wait till the next= time it receives the null register from the source, there will be a waste = of valuable network resource and time.=C2=A0 but in PIM-NG there is no need= for this since the process is much more faster and at any time a last hop = (client) needs to receive a traffic destined for (G) it will only need to a= sk the address of source and directly and if the source is active immediate= ly join the SPT without the need for a switch over from RPT to SPT.

I hope that the above explanations are satisfactory and I have been abl= e to answer your questions and shed some light over the proposed questions = and doubts.=C2=A0

the above being explained, one of the advantages o= f PIM-NG is its source discovery process which at some point works faster t= han PIM-SM.=C2=A0

since this email is getting long i will try to explain other advantages= of PIM-NG in a=C2=A0
separate email.=C2=A0

Thanks again and I ho= pe to read the comments and thoughts of other WG members=C2=A0
soon.

End

<= div class=3D"gmail_extra">

On Fri, Apr 25= , 2014 at 10:32 PM, <pim-request@ietf.org> wrote:
Send pim mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pim@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/pim
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pim-req= uest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pim-owner= @ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of pim digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: New updated and edited version of draft-sami-pim-ng
=C2=A0 =C2=A0 =C2=A0 (Stig Venaas)
=C2=A0 =C2=A02. Re: New updated and edited version of draft-sami-pim-ng
=C2=A0 =C2=A0 =C2=A0 (saeed sami)


----------------------------------------------------------------------

Message: 1
Date: Thu, 24 Apr 2014 14:24:56 -0700
From: Stig Venaas <stig@venaas.com>
To: saeed sami <sami.biz.ema= il@gmail.com>, pim <pim@ietf.org<= /a>>
Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng
Message-ID: <53598128.109= 0107@venaas.com>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

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:
> =C2=A0 =C2=A0 This document specifies protocol independent multicast- = Next
> =C2=A0 =C2=A0 generation or simply called PIM-NG. like PIM-SM, PIM-NG = uses the
> =C2=A0 =C2=A0 underlying unicast routing information, but unlike PIM-S= M it doesn't
> =C2=A0 =C2=A0 necessarily need to build unidirectional shared trees ro= oted at a
> =C2=A0 =C2=A0 Rendezvous Point (RP) per group, due to the fact that th= e processes
> =C2=A0 =C2=A0 through which a source registers with the Rendezvous Poi= nt and a host
> =C2=A0 =C2=A0 finds the source of the multicast destination groups it = needs are
> =C2=A0 =C2=A0 done in a whole new way. So at some points PIM-NG works = faster than
> =C2=A0 =C2=A0 its predecessor. Also the new Domain concept, unique to = PIM-NG, along
> =C2=A0 =C2=A0 the RPF check method used in PIM-NG specifications provi= des many
> =C2=A0 =C2=A0 features along a robust and flexible control and adminis= tration over
> =C2=A0 =C2=A0 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
--bcaec51f96634acd0f04f83659d6-- From nobody Tue Apr 29 16:22:03 2014 Return-Path: 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 842211A0A07 for ; Tue, 29 Apr 2014 16:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 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, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 44z6AO0rju2v for ; Tue, 29 Apr 2014 16:22:00 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DEEF01A0A06 for ; Tue, 29 Apr 2014 16:21:59 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rd18so1033498iec.15 for ; Tue, 29 Apr 2014 16:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=emsUahGmEeDukTiJLMit2SucqYKyRR3f3wJhCF2qQE4=; b=jsDWHbGUzQP88U78x+wGLcAhkWCHbJLEqe9q+fWt2dgxDVrODXn0nDzdHcRgOad+ZD NraPhArMsSsv881subVdvH2TPc66Vlr8lhL++G874UFBPIWjPWaNXaILssb1g6DBDPIf 2sDe5/NebDNlAYOGtRlX6z9U4zlw6o/Rpr6CsEqO11jyg1/smUpOEPZpw56pUa8b9KD2 u6Lr8TpIwr96aiJVAWujQ+HSNlzrdUuZMTi7Q1J9SffqM6nigYGpWn1M9V/5Iix0DWCd 8lOHFAAjG3e7F442x2Xk5/BXtqzkMiPMi15Dq7gA00yJYmpkEb7NFxEnlIl/ymMo4b07 fqNw== MIME-Version: 1.0 X-Received: by 10.42.253.130 with SMTP id na2mr69175icb.82.1398813718586; Tue, 29 Apr 2014 16:21:58 -0700 (PDT) Received: by 10.64.224.141 with HTTP; Tue, 29 Apr 2014 16:21:58 -0700 (PDT) Date: Wed, 30 Apr 2014 02:51:58 +0330 Message-ID: From: saeed sami To: pim Content-Type: multipart/alternative; boundary=bcaec50e5ea5cdac9b04f836b241 Archived-At: http://mailarchive.ietf.org/arch/msg/pim/zsWRtpAJx3esAsQUWMBSCu8s-jM Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng(part 3) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 23:22:02 -0000 --bcaec50e5ea5cdac9b04f836b241 Content-Type: text/plain; charset=UTF-8 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 can't be posted to PIM mailing list as a single email, I have to answer in separate parts. and this is part 3 of the series. 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. *3- Will there be a 30 second delay between the time a source becomes active and a last hop learns about it? : * - since as soon as a source becomes active and the register message is sent to RP the information related to it is saved in MMT or AMMT by the RP, as soon as a client (last hop) comes up with the need to find the source , it will only need to ask the RP. There will be no delay in finding the source. - since after receiving the address of the source there won't be any join to RPT rooted at the RP and the client (last hop) will immediately join the SPT for (G) using the unicast address of the source received from the RP, there won't be any delays and PIM-NG will be one cycle a head of PIM-SM since there is no switching from RPT to SPT. - The above being explained there won't be any delay. - Also because in PIM-NG neighbor routers inform each other about the groups they are join the SPT for, if a neighboring PIM-NG router comes up later with the need to find (S) for the same (G) a neighbor is joined the SPT for, there won't be the need to send a request to RP and instead the client will send its join to its neighbor. End of part 3. On Fri, Apr 25, 2014 at 10:32 PM, wrote: > Send pim mailing list submissions to > pim@ietf.org > > 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 > pim-request@ietf.org > > You can reach the person managing the list at > pim-owner@ietf.org > > 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 > To: saeed sami , pim > Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng > Message-ID: <53598128.1090107@venaas.com> > 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 --bcaec50e5ea5cdac9b04f836b241 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear Mr.Venaas,=C2=A0Hello=C2=A0
First of all let me thank you for your review, comments and the time you ha= ve=C2=A0
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 can't be= posted to PIM mailing list as a single email, I have to answer in separate= parts. and this is part 3 of the series.=C2=A0

Please kindly find the answers and explanations to your q= uestions and doubts bellow. i hope that as you mentioned in your email ther= e will be more comments from other members after this.=C2=A0=C2=A0

3- Will ther= e be a 30 second delay between the time a source becomes active and a last = hop learns about it? :=C2=A0
- since as soon as a source becomes active and the register message is sent= to RP=C2=A0the information related to it is saved in MMT or AMMT by the RP= , as soon as a=C2=A0client (last hop) comes up with the need to find the so= urce , it will only need to=C2=A0ask the RP. There will be no delay in find= ing the source.

- since after receiving the address of the source there won= 9;t be any join to RPT=C2=A0rooted at the RP and the client (last hop) will= immediately join the SPT for (G) using=C2=A0the unicast address of the sou= rce received from the RP, there won't be any delays=C2=A0and PIM-NG wil= l be one cycle a head of PIM-SM since there is no switching from=C2=A0RPT t= o SPT.

- The above being explained there won't be any delay.

- Also because in PIM-NG neighbor routers infor= m each other about the groups=C2=A0

they are join t= he SPT for, if a neighboring PIM-NG router comes up later with the=C2=A0nee= d to find (S) for the same (G) a neighbor is joined the SPT for, there won&= #39;t be=C2=A0the need to send a request to RP and instead the client will = send its join to its=C2=A0neighbor.=C2=A0

End of part 3.

On Fri, Apr 25, 2014 at 10:32 PM, <= span dir=3D"ltr"><pim-request@ietf.org> wrote:
Send pim mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pim@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/pim
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pim-req= uest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pim-owner= @ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of pim digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: New updated and edited version of draft-sami-pim-ng
=C2=A0 =C2=A0 =C2=A0 (Stig Venaas)
=C2=A0 =C2=A02. Re: New updated and edited version of draft-sami-pim-ng
=C2=A0 =C2=A0 =C2=A0 (saeed sami)


----------------------------------------------------------------------

Message: 1
Date: Thu, 24 Apr 2014 14:24:56 -0700
From: Stig Venaas <stig@venaas.com>
To: saeed sami <sami.biz.ema= il@gmail.com>, pim <pim@ietf.org<= /a>>
Subject: Re: [pim] New updated and edited version of draft-sami-pim-ng
Message-ID: <53598128.109= 0107@venaas.com>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

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:
> =C2=A0 =C2=A0 This document specifies protocol independent multicast- = Next
> =C2=A0 =C2=A0 generation or simply called PIM-NG. like PIM-SM, PIM-NG = uses the
> =C2=A0 =C2=A0 underlying unicast routing information, but unlike PIM-S= M it doesn't
> =C2=A0 =C2=A0 necessarily need to build unidirectional shared trees ro= oted at a
> =C2=A0 =C2=A0 Rendezvous Point (RP) per group, due to the fact that th= e processes
> =C2=A0 =C2=A0 through which a source registers with the Rendezvous Poi= nt and a host
> =C2=A0 =C2=A0 finds the source of the multicast destination groups it = needs are
> =C2=A0 =C2=A0 done in a whole new way. So at some points PIM-NG works = faster than
> =C2=A0 =C2=A0 its predecessor. Also the new Domain concept, unique to = PIM-NG, along
> =C2=A0 =C2=A0 the RPF check method used in PIM-NG specifications provi= des many
> =C2=A0 =C2=A0 features along a robust and flexible control and adminis= tration over
> =C2=A0 =C2=A0 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
--bcaec50e5ea5cdac9b04f836b241--