From danny@tcb.net  Wed Jun  3 16:11:35 2009
Return-Path: <danny@tcb.net>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F3C128C10E for <l3vpn@core3.amsl.com>; Wed,  3 Jun 2009 16:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.517
X-Spam-Level: 
X-Spam-Status: No, score=-0.517 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aFhkFNzNbrq for <l3vpn@core3.amsl.com>; Wed,  3 Jun 2009 16:11:34 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id B9ED33A6D69 for <l3vpn@ietf.org>; Wed,  3 Jun 2009 16:11:34 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id B07B52684EA; Wed,  3 Jun 2009 17:11:36 -0600 (MDT)
Received: from 10-1-15-22.aa.arbor.net (division.aa.arbor.net [204.181.64.3]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for l3vpn@ietf.org; Wed, 03 Jun 2009 17:11:36 -0600 (MDT) (envelope-from danny@tcb.net)
Message-Id: <E8A090BD-2419-473C-871C-944056EBF45D@tcb.net>
From: Danny McPherson <danny@tcb.net>
To: l3vpn@ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: WG Last Call: draft-ietf-l3vpn-mvpn-considerations-03
Date: Wed, 3 Jun 2009 17:10:45 -0600
X-Mailer: Apple Mail (2.935.3)
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2009 23:11:35 -0000

Folks,
Please consider today the start of a 2-week WG Last
Call for this document.  If you have comments please
provide them to the authors and/or l3vpn@ WG mailing
list ASAP.

<http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-considerations>

WG LC for this document ends on June 19, 2009.

Thanks!

-danny

Begin forwarded message:

> From: Internet-Drafts@ietf.org
> Date: April 29, 2009 7:00:02 AM MDT
> To: i-d-announce@ietf.org
> Cc: l3vpn@ietf.org
> Subject: I-D Action:draft-ietf-l3vpn-mvpn-considerations-03.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Layer 3 Virtual Private Networks  
> Working Group of the IETF.
>
>
> 	Title           : Mandatory Features in a Layer 3 Multicast BGP/ 
> MPLS VPN Solution
> 	Author(s)       : T. Morin, et al.
> 	Filename        : draft-ietf-l3vpn-mvpn-considerations-03.txt
> 	Pages           : 32
> 	Date            : 2009-04-29
>
> More that one set of mechanisms to support multicast in a layer 3
> BGP/MPLS VPN has been defined.  These are presented in the documents
> that define them as optional building blocks.
>
> To enable interoperability between implementations, this document
> defines a subset of features that is considered mandatory for a
> multicast BGP/MPLS VPN implementation.  This will help implementers
> and deployers understand which L3VPN multicast requirements are best
> satisfied by each option.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-considerations-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
Content-Type: text/plain<BR>Content-ID: &lt;2009-04-29055428.I-D@ietf.org 
&gt;<BR><BR>

From subinoy_das_82@yahoo.com  Thu Jun 11 03:38:51 2009
Return-Path: <subinoy_das_82@yahoo.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F94D28C175 for <l3vpn@core3.amsl.com>; Thu, 11 Jun 2009 03:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.739
X-Spam-Level: 
X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4nD3YHn+JEa for <l3vpn@core3.amsl.com>; Thu, 11 Jun 2009 03:38:50 -0700 (PDT)
Received: from n8-vm0.bullet.mail.in.yahoo.com (n8-vm0.bullet.mail.in.yahoo.com [202.86.4.189]) by core3.amsl.com (Postfix) with SMTP id D826F3A6D65 for <l3vpn@ietf.org>; Thu, 11 Jun 2009 03:38:49 -0700 (PDT)
Received: from [202.86.4.170] by n8.bullet.mail.in.yahoo.com with NNFMP; 11 Jun 2009 10:38:52 -0000
Received: from [203.104.18.52] by t1.bullet.in.yahoo.com with NNFMP; 11 Jun 2009 10:38:52 -0000
Received: from [127.0.0.1] by omp113.mail.in2.yahoo.com with NNFMP; 11 Jun 2009 10:38:52 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 548292.2911.bm@omp113.mail.in2.yahoo.com
Received: (qmail 95712 invoked by uid 60001); 11 Jun 2009 10:38:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1244716732; bh=cn+L5NiHKm5SfLg1Pa2018/FD8T4sKSae6p9UPMEeV0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=KdpNcb6MITgezKoNwn2jaqj4a72BH5bc0XPnVrYRrikHrdYkuEuD4Z4c2dPW6d53WyRo2Sz72HdmA15CiT8c/2p2bM6FC5zuEjRTfhYX/V6sSkDxKxQT2RXPBnslgkhsjVPwovq7icBHNU/YU94ifnxmIlfDVVZBEkQQw3Kz9dw=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=RRP8yoi3O+HCxmJ4tIDGj36dWxP06Ijt8h0Wem0Uop4UCgg5Q4mMSW51WaJ81Vwbu0Fblk9IXwiqlQvpOjY56rVTDic6K2ij1UsCiyLKrxUgjo6q90TYC5eA8blgPa4nXlDjdZGW99Bg4C08KukpZYtu+pafArzJmRKrpmHchy8=;
Message-ID: <393743.95417.qm@web94902.mail.in2.yahoo.com>
X-YMail-OSG: GZ4QUGkVM1nme5DOjYTqJPwC25Yka0upGVxY9tg6NAOmYOTRzxE753WpNkCG0B6TnOT.OisJ09dlni9h7SUup7AGZoomnFKpgMCC1Icvoryxq8cBPHrjpq.YDqmoAIov8OJpgOdVPYf3jum2W8daQDr1VIQPVX6ZXylm00MGUU3gEsX3lt49m0Ska8Z8GjpE_6WcPo1BDvZtmRhRaep84.s7efUESQO3iJqbemLrESEruP4x1kZzWRTU0Qd9_wepZA--
Received: from [121.242.14.67] by web94902.mail.in2.yahoo.com via HTTP; Thu, 11 Jun 2009 16:08:51 IST
X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15
Date: Thu, 11 Jun 2009 16:08:51 +0530 (IST)
From: Subinoy Das <subinoy_das_82@yahoo.com>
Subject: draft-ietf-l3vpn-2547bis-mcast-08.txt - Query about forwarding Register and Hello from customer network
To: L3VPN MAIL <l3vpn@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1064167497-1244716731=:95417"
Cc: Eric Rosen <erosen@cisco.com>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2009 10:38:51 -0000

--0-1064167497-1244716731=:95417
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi,=0A=0Adraft-ietf-l3vpn-2547bis-mcast-08.txt does not say anything about =
forwarding customer Hello, Register packets.=0ASuppose customer network is =
on running PIM-SM protocol and provider network support MVPN using RSVP P2M=
P PMSI. Then is Hello packet from PE C-Instance which also running PIM-SM n=
eed to be forwarded through provider network so PE C-Instance running as C-=
RP do not discard Register packet? If yes then please let me know how they =
are forwarded? If no then please let me know how Register packet from other=
 PE C-Instance will be accpeted by PE C-Instance running as C-RP?=0A=0ARega=
rds,=0ASubinoy=0A=0A=0A=0A      Explore and discover exciting holidays and =
getaways with Yahoo! India Travel http://in.travel.yahoo.com/
--0-1064167497-1244716731=:95417
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt"><div>Hi,<br><br>draft-ietf-l3vpn-2547bis-mcast-08.txt does not=
 say anything about forwarding customer Hello, Register packets.<br>Suppose=
 customer network is on running PIM-SM protocol and provider network suppor=
t MVPN using RSVP P2MP PMSI. Then is Hello packet from PE C-Instance which =
also running PIM-SM need to be forwarded through provider network so PE C-I=
nstance running as C-RP do not discard Register packet? If yes then please =
let me know how they are forwarded? If no then please let me know how Regis=
ter packet from other PE C-Instance will be accpeted by PE C-Instance runni=
ng as C-RP?<br><br>Regards,<br>Subinoy<br></div></div><br>=0A=0A=0A      <!=
--1--><hr size=3D1></hr> Bollywood news, movie reviews, film trailers and m=
ore! <a href=3D"http://in.rd.yahoo.com/tagline_movies_1/*http://in.movies.y=
ahoo.com/?wm=3Dn/"> Click here.</a></body></html>
--0-1064167497-1244716731=:95417--


From erosen@cisco.com  Thu Jun 11 08:52:08 2009
Return-Path: <erosen@cisco.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD10E3A6D07 for <l3vpn@core3.amsl.com>; Thu, 11 Jun 2009 08:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xt8UreFdOI12 for <l3vpn@core3.amsl.com>; Thu, 11 Jun 2009 08:52:07 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1C3A83A68E8 for <l3vpn@ietf.org>; Thu, 11 Jun 2009 08:52:07 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,203,1243814400"; d="scan'208";a="46949039"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 11 Jun 2009 15:52:14 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5BFqDWi024478 for <l3vpn@ietf.org>; Thu, 11 Jun 2009 11:52:13 -0400
Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5BFqDPU027174 for <l3vpn@ietf.org>; Thu, 11 Jun 2009 15:52:13 GMT
Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n5BFqDMU024995 for <l3vpn@ietf.org>; Thu, 11 Jun 2009 11:52:13 -0400
To: l3vpn@ietf.org
Subject: LC Comments on "considerations" scaling analysis
In-reply-to: Your message of Wed, 03 Jun 2009 17:10:45 -0600. <E8A090BD-2419-473C-871C-944056EBF45D@tcb.net> 
Date: Thu, 11 Jun 2009 11:52:13 -0400
Message-ID: <24994.1244735533@erosen-linux>
From: Eric Rosen <erosen@cisco.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9269; t=1244735533; x=1245599533; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20<erosen@cisco.com> |Subject:=20LC=20Comments=20on=20=22considerations=22=20sca ling=20analysis |Sender:=20 |To:=20l3vpn@ietf.org; bh=9Y+xe696La9FSMGCMnIeeGFMW87u5SkZ27BMZ9Nfesw=; b=FkDegsqchbBuY9SwXVm/M8tXbOWz4NJV9dup7qXptejvqXnA5NHhrCHnbX detWNl7yhsxkCOHBylblFdt5FftVEMT+Ihn2xXvSsxhogL7s/gxukyfctv5c 2M3HrngJ4t;
Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); 
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: erosen@cisco.com
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2009 15:52:08 -0000

Appendix A  of the  "considerations" draft purports  to provide  an analysis
showing that BGP C-multicast routing provides a much more efficient solution
for PE-PE communication  that does PE-PE PIM.  The analysis  is not based on
the "hard  state vs.  soft  state" issues, but  on the amount of  state that
needs to be  maintained, and the number of control messages  that need to be
sent and/or received, in order to join or leave a tree.

The analysis does not seem correct to me.

Let's look at a particular VPN, which  is attached to n PE routers, PE1, ..,
PEn.   Suppose PE1, is  attached to  a site  containing multicast  source S.
Let's also suppose  that each other PE has received  a PIM Join(S,G) message
over at least one VRF interface.

Using PE-PE PIM over an MI-PMSI,  how many control messages over the MI-PMSI
are needed to enable PE2, ..., PEn  to join the (S,G) tree via PE1?  Answer:
1.  PE2,  say, sends a  PIM Join(S,G) over  the MI-PMSI.  PE1  receives this
message,  and as  a result  may send  a  PIM Join(S,G)  out one  of its  VRF
interfaces.  PE3,  ..., PEn also received  PE2's Join(S,G), and  as a result
they do not send Joins themselves.

Appendix A  says that the messaging  cost of additional PEs  after the first
joining an (S,G)  tree is the same as  the cost of the first  PE joining the
tree.  This is false.  The messaging  cost of each additional PE to join the
tree is 0.

Appendix A, noting the fact that the first Join must be received by every PE
in the  VPN, states that the message  processing overhead is O(#  PEs in the
VPN).  That is  not really a meaningful measure  of anything.  The messaging
itself is O(1), and there is no router whose processing increases as O(# PEs
in the  VPN).  In each  PE router, the  message processing per tree  per VPN
that is due to PE-PE interactions is O(1).

It would be more illuminating to take the PE-CE interactions into account as
well.   In PIM,  whether a  given interface  is p2p  or multiaccess,  only a
single  Join(S,G)  message is  needed  to enable  all  the  PEs (except  the
upstream PE,  of course)  on that interface  to join  the (S,G) tree.   At a
given node, the PIM messaging  overhead per tree is actually proportional to
the number of interfaces, not  to the number of PIM adjacencies.  (Excluding
Hellos, of course, just as Appendix  A does.)  That's why the PE-PE overhead
per VPN tends to be dwarfed by the PE-CE overhead; for a given VPN, a PE may
have lots of  VRF interfaces, but it only has one  PE-PE interface.  In many
cases, the PE-PE overhead is just in the noise.

Anyway, let's look  at the case where BGP C-multicast  routing is used.  Now
each PE  joining an (S,G) tree must  send a C-multicast Source  Tree Join to
each  RR.  If n-1  PEs want  to join  the tree  (with the  nth PE  being the
upstream PE),  the number of C-multicast  Source Tree Joins sent  is n times
the number of RRs (most likely 2*n).  In PIM, this would have been done with
only  one message;  it  is BGP  that  makes the  number  of messages  needed
proportional to the number  of PEs in the VPN.  The reason  is that there is
no way in BGP to prevent each PE from issuing a Join.

PIM Join  Suppression is a big  savings when receivers  are widely dispersed
among the sites; if  each PE is attached to a site  with receivers, the need
to process someone  else's Join is a good tradeoff against  the need to send
your own Join.  If receivers are  concentrated in a few sites, this tradeoff
is not  so good.  But  many multicast applications  have the model of  a few
sources with a lot of widely dispersed receivers.

Appendix A  is also incorrect about  the overhead related  to PIM Prune(S,G)
messages.

>      By default when PIM LAN procedures are used, when a PE Prunes
>      itself from a multicast tree, all other PEs check their own state
>      to known if they are on the tree, in which case they send a PIM
>      Join message to override the Prune.  The "did the last receiver
>      leave?" question is thus implicitly replied to by all PE routers,
>      for each PIM Prune message.
>
>   We can see that answering the "last receiver leaves" question is a
>   significant proportion of the work that the C-multicast routing
>   building block has to make

I don't see  how this conclusion follows.  If a PE  has "Upstream Join (S,G)
state" for  the logical interface connecting  the PEs, then it  always has a
timer that  it uses to refresh  the Join.  If  the PE sees a  Join(S,G) from
another PE,  it restarts  the timer (causing  Join Suppression).  If  the PE
sees  a  Prune(S,G)  from  another  PE,  it sets  the  timer  to  a  shorter
pre-computed randomized  value.  If,  before that timer  expires, it  sees a
Join(S,G) from another PE, it resets the timer and sets it back to its usual
value.  Appendix A  would lead one to believe  that a Prune(S,G) immediately
causes lots of Join(S,G) messages to be sent; this is not true.  

It takes only one message to do a Prune, and one message to override it.

In BGP, if PE2  decides to prune itself from the (S,G)  tree, it has to send
each of the RRs a message withdrawing its Source Tree Join C-multicast route
for (S,G).   Then the RR  has to use  its BGP decision process  to determine
whether there  is another  Source Tree Join  C-multicast route for  the same
(S,G).   Then the  RR has  to distribute  the latter  route.  The  number of
messages is no fewer.

I think the  distinction that Appendix A  is really trying to get  at is the
following.

Consider a given interface of  a given node.  Suppose that interface appears
either as  the upstream interface or  as a downstream interface  of n trees.
Then let's  say that interface contains  n "branches".  The  total amount of
state that  that PIM needs to  maintain is roughly proportional  to the sum,
over all the node's interfaces, of the number of branches.

Suppose that in a given PE, for a given VPN, there are i VRF interfaces, and
that the average number of branches per interface is m.  For each VPN, there
is also a  single PE-PE interface (a multiaccess interface  to which all the
PEs of the  VPN belong).  Let's suppose that this  link contains k branches,
where j of  these branches belong to trees  that the PE is a  member of, and
k-j belong to other trees in the VPN.

If PE-PE PIM is used, the amount  of state is proportional to i*m+k.  If BGP
C-multicast routing is  used, the amount of state  is proportional to i*m+j.
The incremental  state needed by PIM  is thus proportional to  k-j.  For the
state savings  to be significant,  one must assume  not only that k  is much
larger  than j,  but also  that k-j  is significiant  when compared  to i*m.
Basically this means that you need  to assume that each PE has receivers for
only a  small number  of the  VPN's trees, or  else that  there are  a small
number  of VRF interfaces  per VPN.   Whether or  not these  assumptions are
accurate depends of  course on the set of  multicast applications being used
by the customers.

There are also a couple of important factors which Appendix A has omitted:

- If you are using two different protocols to maintain each multicast state,
  then  the  total  amount  of  state is  effectively  doubled.   This  will
  generally result in  both a memory cost  and a CPU cost.  While  this is a
  "mere factor of  two," perhaps it deserves a mention  in any document that
  compares a control plane that uses two protocols (e.g.  PIM for PE-CE, BGP
  for PE-PE) to a control plane that uses only one.

- For sparse mode, which is the type of multicast most commonly found in the
  enterprises that buy  the VPN service, there is quite  a bit of additional
  messaging in BGP that has not been considered.

  When PE1 receives a C-multicast Source  Tree Join for a sparse mode group,
  it has  to generate a  Source Active  A-D Route.  It  needs to send  a BGP
  update for  this route to each  RR.  Each RR needs  to send it  to each of
  PE2, ..., PE3.   So we have more messaging  which is O( # of  PEs in VPN).
  Needless  to say,  PIM also  has sparse  mode overhead  which  hasn't been
  considered, but the point is that BGP overhead is not O(1).

- One might get  the impression that the BGP scheme  eliminates any need for
  the C-PIM state machine to maintain  states for the PMSIs that connect the
  PEs over the backbone.  This is not true; PEs must maintain Prune(S,G,rpt)
  for the PMSIs.  PEs receiving multicast  data over a PMSI must also do the
  RPF interface  check for  the arriving data,  considering the PMSI  as the
  "input interface".  The backbone does  not become transparent to the C-PIM
  interfaces just because PIM control packets do not flow over the PMSIs.

Since  some of  the  conclusions of  the  draft depend  on  the analysis  in
Appendix  A,  I  think  those  conclusions  need to  be  removed  until  the
underlying analysis is corrected.

If and when  a corrected version of the analysis is  available, it should be
last called by the PIM WG, which  is where one might expect to find the most
expertise in PIM.









  


From erosen@cisco.com  Fri Jun 12 12:02:21 2009
Return-Path: <erosen@cisco.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8986C3A6BC8 for <l3vpn@core3.amsl.com>; Fri, 12 Jun 2009 12:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.399
X-Spam-Level: 
X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huXqlnKmFy8d for <l3vpn@core3.amsl.com>; Fri, 12 Jun 2009 12:02:20 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6880B3A69D0 for <l3vpn@ietf.org>; Fri, 12 Jun 2009 12:02:20 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,211,1243814400"; d="scan'208";a="47185497"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Jun 2009 19:02:28 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5CJ2R6m023360;  Fri, 12 Jun 2009 15:02:27 -0400
Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5CJ2Rhx016455; Fri, 12 Jun 2009 19:02:27 GMT
Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n5CJ2R5a021955;  Fri, 12 Jun 2009 15:02:27 -0400
To: l3vpn@ietf.org
Subject: LC comments on considerations extranet section
X-Mailer: MH-E 8.0.3; nmh 1.2; GNU Emacs 22.1.1
Date: Fri, 12 Jun 2009 15:02:27 -0400
Message-ID: <21954.1244833347@erosen-linux>
From: Eric Rosen <erosen@cisco.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1061; t=1244833347; x=1245697347; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20<erosen@cisco.com> |Subject:=20LC=20comments=20on=20considerations=20extranet= 20section |Sender:=20 |To:=20l3vpn@ietf.org; bh=2nlU4s9rr8Qq94/MGVOpaGUDeDl9P6w3TUQIhMrw1V8=; b=kD+AmgrgrBSVSBf5gESJ3sv7xU1cp/TjIMQC4dC0aOaACGwLsImBL3Obe0 5z2euGPPu7vCj6+HkiImBp+kxMXO7zQE47qWI7jfpj+QXc9tjye25FGVQACK cWrxNIZtzb;
Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); 
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: erosen@cisco.com
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2009 19:02:21 -0000

The section on extranet 3.3.6 is not accurate.

It suggests  that it  is not  known how extranet  could be  achieved without
using BGP-based C-multicast routing.  This is odd considering (a) a solution
providing this feature has been shipping  for years, and (b) the solution is
written up in draft-rosen-l3vpn-mvpn-mspmsi-02.txt.

It  also suggests  that all  it takes  to do  extranet with  BGP C-multicast
routing  is to  reuse the  "already defined  and well  understood  BGP route
target import/export  semantics".  In  fact, this is  not true.   To support
extranet you also  have to know which C-streams in which  PMSIs are the ones
you need to receive.  In the  PIM control plane, you make this determination
by associating each PMSI with a particular PIM interface.  I don't think the
corresponding functionality is specified for the BGP control plane.

I think it  is premature to make a recommendation  based upon which extranet
scheme  works best  until we  have  both extranet  schemes written  up in  a
standards track document.

From subinoy_das_82@yahoo.com  Mon Jun 15 02:26:11 2009
Return-Path: <subinoy_das_82@yahoo.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB373A680E for <l3vpn@core3.amsl.com>; Mon, 15 Jun 2009 02:26:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.259
X-Spam-Level: 
X-Spam-Status: No, score=0.259 tagged_above=-999 required=5 tests=[AWL=-0.998,  BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05OG2yMTPRlx for <l3vpn@core3.amsl.com>; Mon, 15 Jun 2009 02:26:10 -0700 (PDT)
Received: from n5-vm1.bullet.mail.in.yahoo.com (n5-vm1.bullet.mail.in.yahoo.com [202.86.4.130]) by core3.amsl.com (Postfix) with SMTP id 091CE28C103 for <l3vpn@ietf.org>; Mon, 15 Jun 2009 02:26:08 -0700 (PDT)
Received: from [202.86.4.170] by n5.bullet.mail.in.yahoo.com with NNFMP; 15 Jun 2009 09:14:53 -0000
Received: from [203.104.18.53] by t1.bullet.in.yahoo.com with NNFMP; 15 Jun 2009 09:14:52 -0000
Received: from [127.0.0.1] by omp105.mail.in2.yahoo.com with NNFMP; 15 Jun 2009 09:14:52 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 830344.81376.bm@omp105.mail.in2.yahoo.com
Received: (qmail 84501 invoked by uid 60001); 15 Jun 2009 09:14:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245057292; bh=7qy5vIH2Z1yLY4WWNDfrxfKZZRdvlnkLMUlT88o9Z+o=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=erLcS8juNHKvWzA8HuH1WTohiLz2iI+fq+RDJJqvspxsnPItE9RJPWdZmarq9KE04c5doU6C+jpIlTqZ0FnFx3RrHn17L+g9jwZPNF2HGM0E6PaWThYVMn92Z/3Pm/7jjIM2U7C67BHKzvr6G0wyNOGs4zREt8XaNQYZXwtYs0c=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=tG2eIr9yNWdCukcpKjH0udmGBpuSBZvWuD0ptJbObxn9fSkAfiKRCMjBpvEnMCG6tNc5LbUPfiLes5fWOm76mDQnilxLExGk5anw0XJ0HPjsIyLayOx/HNsANiTnn+dN28ufxplb305uoVO0nyE+oyk/zuEAP4EgXYEVWci3O6o=;
Message-ID: <555670.84358.qm@web94906.mail.in2.yahoo.com>
X-YMail-OSG: npr59XIVM1lMyGzK1aI5jBN7NnTxDPmErVxXbICHkbx6Wb4fZzKZRI.1XKmHGIFfR0iism.ftJKwD99qzP7vv2Yy1vTW.kfrD8zRV_f2uRGJK3yqbtwhxWn32kR7PpLC8SUHsR7UDI3sP73juWxfCVSWvcf4.uVt3TqcTkeLMIDSRR57n.a8DaGCDFWtLEE7SXRPyfDrg.5ym8coiZRqxQUXo1MFkG_VKw--
Received: from [121.242.14.67] by web94906.mail.in2.yahoo.com via HTTP; Mon, 15 Jun 2009 14:44:52 IST
X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15
Date: Mon, 15 Jun 2009 14:44:52 +0530 (IST)
From: Subinoy Das <subinoy_das_82@yahoo.com>
Subject: Re: draft-ietf-l3vpn-2547bis-mcast-08.txt - Query about forwarding Register and Hello from customer network
To: L3VPN MAIL <l3vpn@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1009443797-1245057292=:84358"
Cc: Eric Rosen <erosen@cisco.com>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2009 09:26:11 -0000

--0-1009443797-1245057292=:84358
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi,=0A=0APlease let me know how PIM Hello messages from PIM C-Instance of P=
E router are transmitted through provider network to PIM C-Instance of othe=
r PE routers when provider network is using RSVP P2MP PMSI.=0A=0ARegards,=
=0ASubinoy=0A=0A=0A=0A=0A________________________________=0AFrom: Subinoy D=
as <subinoy_das_82@yahoo.com>=0ATo: L3VPN MAIL <l3vpn@ietf.org>=0ACc: Eric =
Rosen <erosen@cisco.com>=0ASent: Thursday, 11 June, 2009 4:08:51 PM=0ASubje=
ct: draft-ietf-l3vpn-2547bis-mcast-08.txt - Query about forwarding Register=
 and Hello from customer network=0A=0A=0AHi,=0A=0Adraft-ietf-l3vpn-2547bis-=
mcast-08.txt does not say anything about forwarding customer Hello, Registe=
r packets.=0ASuppose customer network is on running PIM-SM protocol and pro=
vider network support MVPN using RSVP P2MP PMSI. Then is Hello packet from =
PE C-Instance which also running PIM-SM need to be forwarded through provid=
er network so PE C-Instance running as C-RP do not discard Register packet?=
 If yes then please let me know how they are forwarded? If no then please l=
et me know how Register packet from other PE C-Instance will be accpeted by=
 PE C-Instance running as C-RP?=0A=0ARegards,=0ASubinoy=0A=0A______________=
__________________=0A Bollywood news, movie reviews, film trailers and more=
! Click here.=0A=0A=0A      Share files, take polls, and make new friends -=
 all under one roof. Go to http://in.promos.yahoo.com/groups/
--0-1009443797-1245057292=:84358
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt"><div>Hi,<br><br>Please let me know how PIM Hello messages from=
 PIM C-Instance of PE router are transmitted through provider network to PI=
M C-Instance of other PE routers when provider network is using RSVP P2MP P=
MSI.<br><br>Regards,<br>Subinoy<br></div><div style=3D"font-family: times n=
ew roman,new york,times,serif; font-size: 12pt;"><br><div style=3D"font-fam=
ily: times new roman,new york,times,serif; font-size: 12pt;"><font size=3D"=
2" face=3D"Tahoma"><hr size=3D"1"><b><span style=3D"font-weight: bold;">Fro=
m:</span></b> Subinoy Das &lt;subinoy_das_82@yahoo.com&gt;<br><b><span styl=
e=3D"font-weight: bold;">To:</span></b> L3VPN MAIL &lt;l3vpn@ietf.org&gt;<b=
r><b><span style=3D"font-weight: bold;">Cc:</span></b> Eric Rosen &lt;erose=
n@cisco.com&gt;<br><b><span style=3D"font-weight: bold;">Sent:</span></b> T=
hursday, 11
 June, 2009 4:08:51 PM<br><b><span style=3D"font-weight: bold;">Subject:</s=
pan></b> draft-ietf-l3vpn-2547bis-mcast-08.txt - Query about forwarding Reg=
ister and Hello from customer network<br></font><br><div style=3D"font-fami=
ly: times new roman,new york,times,serif; font-size: 12pt;"><div>Hi,<br><br=
>draft-ietf-l3vpn-2547bis-mcast-08.txt does not say anything about forwardi=
ng customer Hello, Register packets.<br>Suppose customer network is on runn=
ing PIM-SM protocol and provider network support MVPN using RSVP P2MP PMSI.=
 Then is Hello packet from PE C-Instance which also running PIM-SM need to =
be forwarded through provider network so PE C-Instance running as C-RP do n=
ot discard Register packet? If yes then please let me know how they are for=
warded? If no then please let me know how Register packet from other PE C-I=
nstance will be accpeted by PE C-Instance running as C-RP?<br><br>Regards,<=
br>Subinoy<br></div></div><br>=0A=0A=0A      <hr size=3D"1"> Bollywood news=
, movie reviews, film trailers and more! <a rel=3D"nofollow" target=3D"_bla=
nk" href=3D"http://in.rd.yahoo.com/tagline_movies_1/*http://in.movies.yahoo=
..com/?wm=3Dn/"> Click here.</a></div></div></div><br>=0A=0A=0A      <!--3--=
><hr size=3D1></hr> Explore and discover exciting holidays and getaways wit=
h Yahoo! India Travel <a href=3D"http://in.rd.yahoo.com/tagline_Travel_1/*h=
ttp://in.travel.yahoo.com/"> Click here!</a></body></html>
--0-1009443797-1245057292=:84358--


From erosen@cisco.com  Mon Jun 15 07:36:59 2009
Return-Path: <erosen@cisco.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125E228C128 for <l3vpn@core3.amsl.com>; Mon, 15 Jun 2009 07:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gjo3cpiNcPMr for <l3vpn@core3.amsl.com>; Mon, 15 Jun 2009 07:36:58 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E4B9D3A67E7 for <l3vpn@ietf.org>; Mon, 15 Jun 2009 07:36:57 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,222,1243814400"; d="scan'208";a="47401082"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Jun 2009 14:36:15 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5FEaF26028309;  Mon, 15 Jun 2009 10:36:15 -0400
Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5FEaFpm002889; Mon, 15 Jun 2009 14:36:15 GMT
Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n5FEaFAh006573;  Mon, 15 Jun 2009 10:36:15 -0400
To: l3vpn@ietf.org
Subject: LC comment on "considerations" inter-AS section
Date: Mon, 15 Jun 2009 10:36:15 -0400
Message-ID: <6572.1245076575@erosen-linux>
From: Eric Rosen <erosen@cisco.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1138; t=1245076575; x=1245940575; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20<erosen@cisco.com> |Subject:=20LC=20comment=20on=20=22considerations=22=20inte r-AS=20section |Sender:=20 |To:=20l3vpn@ietf.org; bh=lIF4wP5y163xRArXz6ThzLCLih9Lmfn4Y3vfsSpu7Vw=; b=ReyadxnxhsGtrJcagMgbwvIZsySUV2N4t7xWmGFqfvxE0lu4zzia6jOh1u fQkxpLeTx0Hv0/jgnaPgPxKKOtLCYrWbCAI/7M+vqf1Y8zpT0fjQxWV5+suW vT9CUfo97F;
Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); 
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: erosen@cisco.com
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2009 14:36:59 -0000

In  the  discussion  of inter-AS,  I  think  the  draft should  discuss  the
following issues:

- In  order to  use the  segmented inter-AS  procedures, each  ASBR  must be
  pre-configured with the  MVPNs whose trees pass through  it.  (See section
  8.2.1.1 of draft-ietf-l3vpn-2547bis-mcast.)

- One of the most important scaling properties, that of making the number of
  P-tunnels be independent  of the number of PEs in other  ASes, may be more
  theoretical than real,  at least in the shorter  term.  A segmented S-PMSI
  carries traffic from only one PE, so the number of S-PMSIs used by an MVPN
  is still limited only by the total number of PEs in the MVPN.

  To get  the desired  scaling improvement, one  must aggregate a  number of
  intra-AS segments of inter-AS tunnels  into a single intra-AS P-tunnel.  I
  don't believe there  is a specification of the method for  doing this in a
  fully  automated fashion.  Also,  this type  of aggregation  requires MPLS
  upstream-assigned labels.

These issues  seem relevant  to a discussion  of whether  segmented inter-AS
P-tunnels should be mandatory.  











From root@core3.amsl.com  Thu Jun 18 13:45:01 2009
Return-Path: <root@core3.amsl.com>
X-Original-To: l3vpn@ietf.org
Delivered-To: l3vpn@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id EB1353A6B8F; Thu, 18 Jun 2009 13:45:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action:draft-ietf-l3vpn-acceptown-community-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090618204501.EB1353A6B8F@core3.amsl.com>
Date: Thu, 18 Jun 2009 13:45:01 -0700 (PDT)
Cc: l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 20:45:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF.


	Title           : BGP ACCEPT_OWN Standards Action Community Attribute
	Author(s)       : J. Uttaro, et al.
	Filename        : draft-ietf-l3vpn-acceptown-community-01.txt
	Pages           : 9
	Date            : 2009-06-18

Under certain conditions it is desirable for a BGP route reflector to
be able to modify the Route Target list of a VPN route that is
distributed by the route reflector, enabling the route reflector to
control how a route originated within one VRF is imported into other
VRFs.  This technique works effectively as long as the VRF that
exports the route is not on the same PE as the VRF(s) that import the
route.  However, due to the constraints of the BGP protocol, it does
not work if the two are on the same PE.  This document describes a
modification to the BGP protocol allowing this technique to work when
the VRFs are on the same PE, allowing the technique to be used in a
standard manner throughout an autonomous system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-acceptown-community-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-l3vpn-acceptown-community-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-06-18133408.I-D@ietf.org>


--NextPart--

From thomas.morin@orange-ftgroup.com  Fri Jun 19 09:02:18 2009
Return-Path: <thomas.morin@orange-ftgroup.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26DC03A6A0B for <l3vpn@core3.amsl.com>; Fri, 19 Jun 2009 09:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.049
X-Spam-Level: 
X-Spam-Status: No, score=-0.049 tagged_above=-999 required=5 tests=[AWL=2.200,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3olLcNtkt+tc for <l3vpn@core3.amsl.com>; Fri, 19 Jun 2009 09:02:17 -0700 (PDT)
Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id D14CA3A6981 for <l3vpn@ietf.org>; Fri, 19 Jun 2009 09:02:16 -0700 (PDT)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 19 Jun 2009 18:01:59 +0200
Received: from [10.193.15.230] ([10.193.15.230]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 19 Jun 2009 18:01:59 +0200
Message-ID: <4A3BB676.502@orange-ftgroup.com>
Date: Fri, 19 Jun 2009 18:01:58 +0200
From: Thomas Morin <thomas.morin@orange-ftgroup.com>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: erosen@cisco.com, L3VPN <l3vpn@ietf.org>
Subject: Re: LC comment on "considerations" inter-AS section
References: <6572.1245076575@erosen-linux>
In-Reply-To: <6572.1245076575@erosen-linux>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Jun 2009 16:01:59.0110 (UTC) FILETIME=[46BC3E60:01C9F0F7]
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2009 16:02:18 -0000

Hi Eric, folks,

15/06/2009 16:36, Eric Rosen:
> In  the  discussion  of inter-AS,  I  think  the  draft should  discuss  the
> following issues:
>
> - In  order to  use the  segmented inter-AS  procedures, each  ASBR  must be
>   pre-configured with the  MVPNs whose trees pass through  it.  (See section
>   8.2.1.1 of draft-ietf-l3vpn-2547bis-mcast.)
If this is true that it has to be pre-configured and that 
auto-configuration is precluded for some reason, we can mention this 
point in the comparison.

(I don't think that would cancel the advantages of the segmented 
approach, though)

> - One of the most important scaling properties, that of making the number of
>   P-tunnels be independent  of the number of PEs in other  ASes, may be more
>   theoretical than real,  at least in the shorter  term.   A segmented S-PMSI
>   carries traffic from only one PE, so the number of S-PMSIs used by an MVPN
>   is still limited only by the total number of PEs in the MVPN.
>   
I don't get your point:
- without considering S-PMSIs, there is already a big scaling advantage 
compared to the non-segmented approach (number of I-PMSI tunnels in an 
AS independent of the number of PEs in the remote ASes)
- your sentence about S-PMSI is strange : since when "the number of 
S-PMSIs used by an MVPN"
would be limited "by the total number of PEs in the MVPN" ? Whatever the 
choice of segmented vs non-segmented, and even in intra-AS, there is no 
such limitation, the only limit is virtually the number of C-multicast 
streams... (???)
>   To get  the desired  scaling improvement, one  must aggregate a  number of
>   intra-AS segments of inter-AS tunnels  into a single intra-AS P-tunnel.  I
>   don't believe there  is a specification of the method for  doing this in a
>   fully  automated fashion.  Also,  this type  of aggregation  requires MPLS
>   upstream-assigned labels.
>   
I think that these are two bogus claims:
- aggregation of multiple tunnels into one tunnel does not require 
upstream assigned labels, except possibly if the tunnels are shared 
between distinct VPNs, but in that case you need upstream assigned 
labels even in intra-AS, without even considering 
segmented/non-segmented or aggregation
- it doesn't seem to me that something would preclude automation of the 
merging, this is a purely local decision matter   (you could also say 
that there is no spec of a method for deciding to put traffic on an 
S-PMSI; but that wouldn't be relevant, even though strictly speaking true)

-Thomas

From thomas.morin@orange-ftgroup.com  Fri Jun 19 09:02:26 2009
Return-Path: <thomas.morin@orange-ftgroup.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6497B3A6AD8 for <l3vpn@core3.amsl.com>; Fri, 19 Jun 2009 09:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.149
X-Spam-Level: 
X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=1.100,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uv4v8RFAxM62 for <l3vpn@core3.amsl.com>; Fri, 19 Jun 2009 09:02:25 -0700 (PDT)
Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 1A6863A659B for <l3vpn@ietf.org>; Fri, 19 Jun 2009 09:02:24 -0700 (PDT)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 19 Jun 2009 18:02:04 +0200
Received: from [10.193.15.230] ([10.193.15.230]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 19 Jun 2009 18:02:03 +0200
Message-ID: <4A3BB67A.3060002@orange-ftgroup.com>
Date: Fri, 19 Jun 2009 18:02:02 +0200
From: Thomas Morin <thomas.morin@orange-ftgroup.com>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: erosen@cisco.com, L3VPN <l3vpn@ietf.org>
Subject: Re: LC comments on considerations extranet section
References: <21954.1244833347@erosen-linux>
In-Reply-To: <21954.1244833347@erosen-linux>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Jun 2009 16:02:03.0859 (UTC) FILETIME=[4990E230:01C9F0F7]
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2009 16:02:26 -0000

Hi Eric, folks,

12/06/2009 21:02, Eric Rosen:
> The section on extranet 3.3.6 is not accurate.
>
> It suggests  that it  is not  known how extranet  could be  achieved without
> using BGP-based C-multicast routing.  This is odd considering (a) a solution
> providing this feature has been shipping  for years, and (b) the solution is
> written up in draft-rosen-l3vpn-mvpn-mspmsi-02.txt.
>   
One could point out that :
- the section you quote does not say "not known" just "not specified"
- that a feature shipping is not a spec (!)
- that draft-rosen-l3vpn-mvpn-mspmsi-02 is not a WG doc, and that the 
scope of the draft is only WG docs
- (also, that draft-rosen-l3vpn-mvpn-mspmsi was not even talking about 
extranet when the paragraph in question was written one year ago)

So, nothing "odd" really.

> It  also suggests  that all  it takes  to do  extranet with  BGP C-multicast
> routing  is to  reuse the  "already defined  and well  understood  BGP route
> target import/export  semantics".  In  fact, this is  not true.   To support
> extranet you also  have to know which C-streams in which  PMSIs are the ones
> you need to receive.  In the  PIM control plane, you make this determination
> by associating each PMSI with a particular PIM interface.  I don't think the
> corresponding functionality is specified for the BGP control plane.
>   
With PIM, the fact that the dataplane and control plane are so tied, is 
a double-edged sword, which happens to impact how extranet can be done.

> I think it  is premature to make a recommendation  based upon which extranet
> scheme  works best  until we  have  both extranet  schemes written  up in  a
> standards track document.
>   
The (not) funny thing is that, if there had been an agreement to include 
Extranet in the base specs, for both PIM and BGP, consistently with mVPN 
requirements (RFC4834), we would have an interesting comparison to do.

But I have to agree with you that, since draft-ietf-l3vpn-2547bis-mcast 
has unfortunately finally not included Extranet, this section 3.3.6 is 
in a delicate position.  I don't mind removing it.

And I hope further work will be done soon on the Extranet subject.

Cheers,

-Thomas

From thomas.morin@orange-ftgroup.com  Fri Jun 19 09:01:51 2009
Return-Path: <thomas.morin@orange-ftgroup.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D2C3A659B for <l3vpn@core3.amsl.com>; Fri, 19 Jun 2009 09:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.152
X-Spam-Level: **
X-Spam-Status: No, score=2.152 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQCpm36iHMf8 for <l3vpn@core3.amsl.com>; Fri, 19 Jun 2009 09:01:48 -0700 (PDT)
Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 6382A3A6981 for <l3vpn@ietf.org>; Fri, 19 Jun 2009 09:01:47 -0700 (PDT)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 19 Jun 2009 18:01:54 +0200
Received: from [10.193.15.230] ([10.193.15.230]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 19 Jun 2009 18:01:53 +0200
Message-ID: <4A3BB670.9040407@orange-ftgroup.com>
Date: Fri, 19 Jun 2009 18:01:52 +0200
From: Thomas Morin <thomas.morin@orange-ftgroup.com>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: L3VPN <l3vpn@ietf.org>, Eric Rosen <erosen@cisco.com>
Subject: Re: LC Comments on "considerations" scaling analysis
References: <24994.1244735533@erosen-linux>
In-Reply-To: <24994.1244735533@erosen-linux>
Content-Type: multipart/alternative; boundary="------------050702020106070403000704"
X-OriginalArrivalTime: 19 Jun 2009 16:01:53.0485 (UTC) FILETIME=[4361EFD0:01C9F0F7]
X-Mailman-Approved-At: Fri, 19 Jun 2009 09:16:58 -0700
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2009 16:01:51 -0000

This is a multi-part message in MIME format.
--------------050702020106070403000704
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Eric, working group,

In your comments, there is only *one* of them backed with a precise 
quote (it is which is discussed below, and I happen to agree that a 
better formulation can be found, though it doesn't show the analysis as 
incorrect).

But, on the other (numerous) comments, you don't make any quotes, which 
makes it hard to identify what exactly would be incorrect in Appendix A 
in your opinion. This makes your claim that the analysis is incorrect 
very weakly founded.

These other comments are discussed below, but let me highlight the 
following:
* some comments are just plain wrong or misleading, possibly due to a 
misunderstanding on the hypothesis made and what is counted (see below)
* some comments are not related to what is looked at in Appendix A (such 
as CE-PE scaling)
* some comments relate to more complex stuff, and are debatable, but as 
far as I can tell they don't challenge the conclusions in Appendix A, 
not the conclusions drawn elsewhere in the document

Reading in between the lines of your comment, it seems to me that you 
may just disagree with how the counting of the amount of processing is 
done.  You seem to prefer counting in "number of messages" rather than 
in "how many times a message is processed", which is what we do in this 
analysis.  Merely counting the number of message would certainly be very 
favorable to PIM in the considered scenario, since PIM uses messages 
that are processed by all the PEs in the mVPN, but it would not reflect 
the load due to multicast routing on the different equipments, for the 
considered options.    What is funny is that, for BGP S-A A-D routes, 
you'd seem to prefer counting "how many times a message is processed" 
rather than the "number of messages".

What we can do is insist on why we count "how many times a message is 
processed", to make sure that the reader doesn't miss that point. And we 
can make sure that in the different places we get the wording right to 
avoid misunderstandings (e.g. I've spotted a table legend which is unclear).

In any case, in all of your comments, I don't find anything solid that 
questions the conclusions or the correctness of the analysis in Appendix 
A, and none of the few changes suggested appear to me as changing the 
conclusions reused elsewhere in the document.

Please find below more detailed answers...



11/06/2009 17:52, Eric Rosen:
> [..]
>   
> The analysis does not seem correct to me.

I'm not saying that there is not a single mistake, there might be. This 
document was written by humans.
But if you think you found an incorrectness, please do a precise quote 
and explain.

> Using PE-PE PIM over an MI-PMSI,  how many control messages over the MI-PMSI
> are needed to enable PE2, ..., PEn  to join the (S,G) tree via PE1?  Answer:
> 1.  PE2,  say, sends a  PIM Join(S,G) over  the MI-PMSI.  PE1  receives this
> message,  and as  a result  may send  a  PIM Join(S,G)  out one  of its  VRF
> interfaces.  PE3,  ..., PEn also received  PE2's Join(S,G), and  as a result
> they do not send Joins themselves.
>   
You are here just re-explaining us what Join suppression is. I don't 
know if it is useful.
You insist a lot in all your comment on how Join suppression is great. 
Join suppression is certainly a useful mechanism, and the analysis in 
Appendix A does not forget to take it into account. So I don't think 
that this comment puts into question the analysis.



> Appendix A  says that the messaging  cost of additional PEs  after the first
> joining an (S,G)  tree is the same as  the cost of the first  PE joining the
> tree.  This is false.  The messaging  cost of each additional PE to join the
> tree is 0.
>   
No, when a PE Joins the tree it sends a Join(S,G).  There is no "join 
suppression" effect for the first Join (no suppression for the first 
join, just read p.55 of RFC4601). This is true for each PE. The first 
Join of each additional PE is received by all the PEs in the mVPN. Thus 
all the PEs of the mVPN process one Join for each PE joined to (S,G).

So, If you increase the number of PEs joined to (S,G) by one, the number 
of messages processed by each PE increases by *one*.

And it is the same if you count the number of Join(S,G) that have been 
sent: also increased by *one*, not by zero.

Sorry, no free beer. ;-)




> Appendix A, noting the fact that the first Join must be received by every PE
> in the  VPN, states that the message  processing overhead is O(#  PEs in the
> VPN). 
>   That is  not really a meaningful measure  of anything.  The messaging
> itself is O(1), and 
"messaging" is vague, do you talk about "how many times a messages is 
sent" or "how many times a messages is processed"  ?

You possibly challenge the fact we count the total number of messages 
processed on all equipments of a kind, and not merely look at one 
equipement. If so, refer to my comment on this in the introduction of 
this me.

> there is no router whose processing increases as O(# PEs
> in the  VPN). 
No, and we don't assert this, AFAIK.
What is true, is that the total number of message processed by each PE 
in the mVPN increases as O(#R_PEs), the number of PEs that join to the 
considered stream.


>  In each  PE router, the  message processing per tree  per VPN
> that is due to PE-PE interactions is O(1).
>   

That statement is bogus.   Because, for each PE that joins a stream and 
leaves it later, the first Join and the Prune is always sent, and 
because both are processed by each PE in the mVPN, it is obvious that 
each PE processes 2 message for each PE that joins and leaves the stream 
(ignoring refreshes) in that case.

The amount of processing depends on the number of PEs joined to a stream 
and is not in O(1).





> It would be more illuminating to take the PE-CE interactions into account as
> well.   In PIM,  whether a  given interface  is p2p  or multiaccess,  only a
> single  Join(S,G)  message is  needed  to enable  all  the  PEs (except  the
> upstream PE,  of course)  on that interface  to join  the (S,G) tree.   At a
> given node, the PIM messaging  overhead per tree is actually proportional to
> the number of interfaces, not  to the number of PIM adjacencies.  (Excluding
> Hellos, of course, just as Appendix  A does.)  That's why the PE-PE overhead
> per VPN tends to be dwarfed by the PE-CE overhead; for a given VPN, a PE may
> have lots of  VRF interfaces, but it only has one  PE-PE interface.  In many
> cases, the PE-PE overhead is just in the noise.  
This statement related to PE-CE is nowhere related to Appendix A, AFAICT.

(and again, you do not take into account that the first join is always 
sent (RFC4601) and that a Prune is always sent by a PE that leaves the 
stream, thus the amount of processing is certainly not independent of 
the amount of neighbors  on  an interface, as soon as they join a stream.)



> Anyway, let's look  at the case where BGP C-multicast  routing is used.  Now
> each PE  joining an (S,G) tree must  send a C-multicast Source  Tree Join to
> each  RR.  If n-1  PEs want  to join  the tree  (with the  nth PE  being the
> upstream PE),  the number of C-multicast  Source Tree Joins sent  is n times
> the number of RRs (most likely 2*n).  In PIM, this would have been done with
> only  one message;  it  is BGP  that  makes the  number  of messages  needed
> proportional to the number  of PEs in the VPN.  The reason  is that there is
> no way in BGP to prevent each PE from issuing a Join.
>   
You can chose count the "number of messages" instead of the number of 
times "some message is processed by a node". But Appendix A counts the 
number of times "some message is processed by a node" (see comment in 
intro of this mail).  See comment in the intro of this mail. You are not 
challenging here the correctness of the analysis in Appendix A.


> PIM Join  Suppression is a big  savings when receivers  are widely dispersed
> among the sites; if  each PE is attached to a site  with receivers, the need
> to process someone  else's Join is a good tradeoff against  the need to send
> your own Join.  If receivers are  concentrated in a few sites, this tradeoff
> is not  so good.  But  many multicast applications  have the model of  a few
> sources with a lot of widely dispersed receivers.
>   
As said above, Join suppression effects are accounted for in the analysis.

Let's get to the point: how does the statement above is supposed to 
challenge Appendix A ?
(please quote the exact paragraph/line/counting that you disagree with)


> Appendix A  is also incorrect about  the overhead related  to PIM Prune(S,G)
> messages.
>   

Given what I already read, I feel that you just can't get away with such 
a blunt affirmation.

The basic scenario considered, for what matters to Prunes, is that n 
PEs, that had joined a stream, not leave a stream, one by one.
- each joined PE, when it leave the stream (because JoinDesired became 
false because the last CE left), sends a Prune
- each Prune is processed by each PE of the VPN
So, just considering the above, how many times did we had "a Prune is 
processed" ?
Answer: #PEs x #R_PEs

The conclusion are just drawn from such basic arithmetic. The numbers 
for the amount of processing for Prunes are nothing surprising, and are 
(in order of magnitude) similar to numbers for Joins.




>>      By default when PIM LAN procedures are used, when a PE Prunes
>>      itself from a multicast tree, all other PEs check their own state
>>      to known if they are on the tree, in which case they send a PIM
>>      Join message to override the Prune.  The "did the last receiver
>>      leave?" question is thus implicitly replied to by all PE routers,
>>      for each PIM Prune message.
>>
>>   We can see that answering the "last receiver leaves" question is a
>>   significant proportion of the work that the C-multicast routing
>>   building block has to make
>>     
>
> I don't see  how this conclusion follows.  If a PE  has "Upstream Join (S,G)
> state" for  the logical interface connecting  the PEs, then it  always has a
> timer that  it uses to refresh  the Join.  If  the PE sees a  Join(S,G) from
> another PE,  it restarts  the timer (causing  Join Suppression).  If  the PE
> sees  a  Prune(S,G)  from  another  PE,  it sets  the  timer  to  a  shorter
> pre-computed randomized  value.  If,  before that timer  expires, it  sees a
> Join(S,G) from another PE, it resets the timer and sets it back to its usual
> value.  
>   
> It takes only one message to do a Prune, and one message to override it.
>   
True, but everyone knows this.   Everyone also knows that this PIM Prune 
message is processed by all the PEs: they all have to parse it, and 
lookup if they have a corresponding state, and reset a timer.  If none 
of the PEs has state, nobody sends a Join to override ; this "non 
response" is the result of the collective work of all PEs, that have 
checked that they didn't had matching state.

Only two routers did send a message, but every PE worked !

This is what Appendix A refers to by saying :
 
     The "did the last receiver leave?" question is thus *implicitly* 
replied to
     by all PE routers, for each PIM Prune message.

> Appendix A  would lead one to believe  that a Prune(S,G) immediately
> causes lots of Join(S,G) messages to be sent; this is not true.  


We'll try and improve the sentence to avoid the misunderstanding, 
insisting on the collective work to produce a non-response in due time, 
letting the upstream node deduce that it can prune traffic.


> In BGP, if PE2  decides to prune itself from the (S,G)  tree, it has to send
> each of the RRs a message withdrawing its Source Tree Join C-multicast route
> for (S,G).   Then the RR  has to use  its BGP decision process  to determine
> whether there  is another  Source Tree Join  C-multicast route for  the same
> (S,G).   Then the  RR has  to distribute  the latter  route.  The  number of
> messages is no fewer.
>   

What is counted in Appendix A is the amount of routing processing done 
by the routing equipments, not the number of messages. And in the 
example you take, in PIM case the amount of times there was "some 
message processed by some equipment" is higher than in BGP. This comment 
does not expose an incorrectness in Appendix A.



> I think the  distinction that Appendix A  is really trying to get  at is the
> following.
>
> Consider a given interface of  a given node.  Suppose that interface appears
> either as  the upstream interface or  as a downstream interface  of n trees.
> Then let's  say that interface contains  n "branches".  The  total amount of
> state that  that PIM needs to  maintain is roughly proportional  to the sum,
> over all the node's interfaces, of the number of branches.
>   

(you omit the processing of prunes and first joins on each branch! )


> Suppose that in a given PE, for a given VPN, there are i VRF interfaces, and
> that the average number of branches per interface is m.  For each VPN, there
> is also a  single PE-PE interface (a multiaccess interface  to which all the
> PEs of the  VPN belong).  Let's suppose that this  link contains k branches,
> where j of  these branches belong to trees  that the PE is a  member of, and
> k-j belong to other trees in the VPN.
>
> If PE-PE PIM is used, the amount  of state is proportional to i*m+k.  If BGP
> C-multicast routing is  used, the amount of state  is proportional to i*m+j.
> The incremental  state needed by PIM  is thus proportional to  k-j.  For the
> state savings  to be significant,  one must assume  not only that k  is much
> larger  than j,  but also  that k-j  is significiant  when compared  to i*m.
> Basically this means that you need  to assume that each PE has receivers for
> only a  small number  of the  VPN's trees, or  else that  there are  a small
> number  of VRF interfaces  per VPN.   Whether or  not these  assumptions are
> accurate depends of  course on the set of  multicast applications being used
> by the customers.
>   

I don't get your point and I don't see why with PE-PE PIM "the amount of 
state is proportional to i*m+k", since a PIM PE has to maintain state 
only for streams it is joined to, thus rather i*m+j (it has to process 
messages for joins for streams it is not joined to, but no state to 
maintain, afaik).

But anyway, the conclusion on state maintenance in Appendix A are that, 
in order of magnitude, the amount of state is the same for all 
approaches. This does not goes against the conclusion above, right ?

(please be more explicit on what in Appendix A you challenge as "incorrect")

> There are also a couple of important factors which Appendix A has omitted:
>
> - If you are using two different protocols to maintain each multicast state,
>   then  the  total  amount  of  state is  effectively  doubled.   This  will
>   generally result in  both a memory cost  and a CPU cost.  While  this is a
>   "mere factor of  two," perhaps it deserves a mention  in any document that
>   compares a control plane that uses two protocols (e.g.  PIM for PE-CE, BGP
>   for PE-PE) to a control plane that uses only one.
>  
This was pointed out by Maria and already fixed in -03.
(state maintenance in A.3, multiplied by 2; it is a linear factor not 
changing the conclusions of Appendix A in O(x))


> - For sparse mode, which is the type of multicast most commonly found in the
>   enterprises that buy  the VPN service, there is quite  a bit of additional
>   messaging in BGP that has not been considered.
>
>   
>  When PE1 receives a C-multicast Source  Tree Join for a sparse mode
>  group,it has  to generate a  Source Active  A-D Route.  It  needs to
>  send  a BGP update for  this route to each  RR.  Each RR needs  to
>  send it  to each of PE2, ..., PE3.   So we have more messaging which
>  is O( # of  PEs in VPN). Needless  to say,  PIM also  has sparse
>  mode overhead  which  hasn't been considered, but the point is that
>  BGP overhead is not O(1).

A few comments:
- let me remind, that due to the complexity in comparing for a non-SSM 
scenario, because the PIM and BGP procedures are significantly 
different, it just wasn't done ; the SPT/SSM part is common, and seems 
to me as enough to guide the comparison
- let me highlight that, this time, you choose to count the number of 
times a message is processed, not how many messages are sent ; you seem 
to change what you like to count depending on what you want to show :)
- you highlight above a scenario with a total amount of processing 
across all nodes in O(#mVPN_PE) and say that "the  BGP overhead is not 
O(1)" : this is correct, but not significantly different from what we 
have in the base scenario of Appendix A, for which the  total amount of 
processing across all nodes is O(#R_PE) for BGP, and  O(#mVPN_PE x 
#R_PE) for PIM

So, while it could be conceivable to complement the analysis with a 
non-SSM scenario in the line of the SSM scenario already considered, we 
don't have yet seen a compelling argument to do it, since the change 
wouldn't seem to fundamentally affect the comparison between PIM and BGP.


Now, there is another thing briefly looked at at the very end of 
Appendix A:  the case of a more dynamic situation where PEs join and 
leave many times. In the non-SSM case, as you mention, BGP would have 
to  also produce the S-A A-D routes, and they would have to be processed 
by all PEs.  But for one said downsteam PE joining the steam, the 
upstream PE will advertises a new S-A A-D routes only if there was no PE 
already joined to the stream. The impact on BGP thus depends a lot on 
the Join/Prune dynamics...  As you say, the overhead of BGP for the 
total amount of processing is not O(1) in that case, but will depend on 
the number of PEs. But this is true to for PIM too, except that for PIM 
we don't need to make strong hypothesis on the dynamics to know the 
number of times a message is processed  (in the dynamic case, PIM loses 
the gains of join suppression, and pays the full price of having each 
message being processed by every PE in the mVPN).

So well, if you can explain that such a case would expose conclusions 
impacting what is in the document today, then it could be worth including.


> - One might get  the impression that the BGP scheme  eliminates any need for
>   the C-PIM state machine to maintain  states for the PMSIs that connect the
>   PEs over the backbone.  This is not true; 
We don't state anything contradictory with the above, AFAIK.
Taking the exact amount/volume of state information would be doable, but 
as far as I can tell it doesn't seem to change the orders of magnitude.

>   PEs must maintain Prune(S,G,rpt)
>   for the PMSIs.  PEs receiving multicast  data over a PMSI must also do the
>   RPF interface  check for  the arriving data,  considering the PMSI  as the
>   "input interface".  The backbone does  not become transparent to the C-PIM
>   interfaces just because PIM control packets do not flow over the PMSIs.
>   
The above is not related to the routing/processing load, hence not to 
Appendix A.

> Since  some of  the  conclusions of  the  draft depend  on  the analysis  in
> Appendix  A,  I  think  those  conclusions  need to  be  removed  until  the
> underlying analysis is corrected.
>   

Your comments will be useful to improve some points in  Appendix A 
(thank you), but nothing that changes the conclusions significantly 
enough to remove stuff elsewhere in the document. Or if you really have 
such a claim, I think that to take a decision we would need you to make 
it more explicit what you would remove.

> If and when  a corrected version of the analysis is  available, it should be
> last called by the PIM WG, which  is where one might expect to find the most
> expertise in PIM.  
And a last call by IDR too for the BGP part ?

Let's be serious: first, let's see if a "correction" is needed, and 
delay the question until you really show in how the analysis would be 
incorrect !

Cheers,

-Thomas

--------------050702020106070403000704
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Eric, working group,<br>
<br>
In your comments, there is only *one* of them backed with a precise
quote (it is which is discussed below,
and I happen to agree that a better formulation can be found, though it
doesn't show the analysis as incorrect). <br>
<br>
But, on the other (numerous) comments, you don't make any quotes, which
makes it hard to identify what exactly would be incorrect in Appendix A
in your opinion. This makes your claim that the analysis is incorrect
very weakly founded.<br>
<br>
These other comments are discussed below, but let me highlight the
following:<br>
* some comments are just plain wrong or misleading, possibly due to a
misunderstanding on the hypothesis made and what is counted (see below)<br>
* some comments are not related to what is looked at in Appendix A
(such as CE-PE scaling)<br>
* some comments relate to more complex stuff, and are debatable, but as
far as I can tell they don't challenge the conclusions in Appendix A,
not the conclusions drawn elsewhere in the document<br>
<br>
Reading in between the lines of your comment, it seems to me that you
may just disagree with how the counting of the amount of processing is
done.  You seem to prefer counting in "number of messages" rather than
in "how many times a message is processed", which is what we do in this
analysis.  Merely counting the number of message would certainly be
very favorable to PIM in the considered scenario, since PIM uses
messages that are processed by all the PEs in the mVPN, but it would
not reflect the load due to multicast routing on the different
equipments, for the considered options.    What is funny is that, for
BGP S-A A-D routes, you'd seem to prefer counting "how many times a
message is processed" rather than the "number of messages".<br>
<br>
What we can do is insist on why we count "how many times a message is
processed", to make sure that the reader doesn't miss that point. And
we can make sure that in the different places we get the wording right
to avoid misunderstandings (e.g. I've spotted a table legend which is
unclear).<br>
<br>
In any case, in all of your comments, I don't find anything solid that
questions the conclusions or the correctness of the analysis in
Appendix A, and none of the few changes suggested appear to me as
changing the conclusions reused elsewhere in
the document.<br>
<br>
Please find below more detailed answers...<br>
<br>
<br>
<br>
11/06/2009 17:52, Eric Rosen:
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">[..]
  </pre>
</blockquote>
<blockquote type="cite">
  <pre wrap="">The analysis does not seem correct to me.</pre>
</blockquote>
<br>
I'm not saying that there is not a single mistake, there might be. This
document was written by humans.<br>
But if you think you found an incorrectness, please do a precise quote
and explain.<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">Using PE-PE PIM over an MI-PMSI,  how many control messages over the MI-PMSI
are needed to enable PE2, ..., PEn  to join the (S,G) tree via PE1?  Answer:
1.  PE2,  say, sends a  PIM Join(S,G) over  the MI-PMSI.  PE1  receives this
message,  and as  a result  may send  a  PIM Join(S,G)  out one  of its  VRF
interfaces.  PE3,  ..., PEn also received  PE2's Join(S,G), and  as a result
they do not send Joins themselves.
  </pre>
</blockquote>
You are here just re-explaining us what Join suppression is. I don't
know if it is useful.<br>
You insist a lot in all your comment on how Join suppression is great.
Join suppression is certainly a useful mechanism, and the analysis in
Appendix A does not forget to take it into account. So I don't think
that this comment puts into question the analysis.<br>
<br>
<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">Appendix A  says that the messaging  cost of additional PEs  after the first
joining an (S,G)  tree is the same as  the cost of the first  PE joining the
tree.  This is false.  The messaging  cost of each additional PE to join the
tree is 0.
  </pre>
</blockquote>
No, when a PE Joins the tree it sends a Join(S,G).  There is no "join
suppression" effect for the first Join (no suppression for the first
join, just read p.55 of RFC4601). This is true for each PE. The first
Join of each additional PE is received by all the PEs in the mVPN. Thus
all the
PEs of the mVPN process one Join for each PE joined to (S,G). <br>
<br>
So, If you increase the number of PEs joined to (S,G) by one, the
number of messages processed by each PE increases by *one*.<br>
<br>
And it is the same if you count the number of Join(S,G) that have been
sent: also increased by *one*, not by zero.<br>
<br>
Sorry, no free beer. ;-)<br>
<br>
<br>
<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">Appendix A, noting the fact that the first Join must be received by every PE
in the  VPN, states that the message  processing overhead is O(#  PEs in the
VPN). </pre>
</blockquote>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">  That is  not really a meaningful measure  of anything.  The messaging
itself is O(1), and </pre>
</blockquote>
"messaging" is vague, do you talk about "how many times a messages is
sent" or "how many times a messages is processed"  ?<br>
<br>
You possibly challenge the fact we count the total number of messages
processed on all equipments of a kind, and not merely look at one
equipement. If so, refer to my comment on this in the introduction of
this me.<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">there is no router whose processing increases as O(# PEs
in the  VPN). </pre>
</blockquote>
No, and we don't assert this, AFAIK.<br>
What is true, is that the total number of message processed by each PE
in the mVPN increases as
O(#R_PEs), the number of PEs that join to the considered stream.<br>
<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap=""> In each  PE router, the  message processing per tree  per VPN</pre>
</blockquote>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">that is due to PE-PE interactions is O(1).
  </pre>
</blockquote>
<br>
That statement is bogus.   Because, for each PE that joins a stream and
leaves it later, the first Join and the Prune is always sent, and
because both are processed by each PE in the mVPN, it is obvious that
each PE processes 2 message for each PE that joins and leaves the
stream (ignoring refreshes) in that case. <br>
<br>
The amount of processing depends on the number of PEs joined to a
stream and is not in O(1).<br>
<br>
<br>
<br>
<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">It would be more illuminating to take the PE-CE interactions into account as
well.   In PIM,  whether a  given interface  is p2p  or multiaccess,  only a
single  Join(S,G)  message is  needed  to enable  all  the  PEs (except  the
upstream PE,  of course)  on that interface  to join  the (S,G) tree.   At a
given node, the PIM messaging  overhead per tree is actually proportional to
the number of interfaces, not  to the number of PIM adjacencies.  (Excluding
Hellos, of course, just as Appendix  A does.)  That's why the PE-PE overhead
per VPN tends to be dwarfed by the PE-CE overhead; for a given VPN, a PE may
have lots of  VRF interfaces, but it only has one  PE-PE interface.  In many
cases, the PE-PE overhead is just in the noise.  </pre>
</blockquote>
This statement related to PE-CE is nowhere related to Appendix A,
AFAICT.<br>
<br>
(and again, you do not take into account that the first join is always
sent
(RFC4601) and that a Prune is always sent by a PE that leaves the
stream, thus the amount of
processing is certainly not independent of the amount of neighbors  on 
an
interface, as soon as they join a stream.)<br>
<br>
<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">Anyway, let's look  at the case where BGP C-multicast  routing is used.  Now
each PE  joining an (S,G) tree must  send a C-multicast Source  Tree Join to
each  RR.  If n-1  PEs want  to join  the tree  (with the  nth PE  being the
upstream PE),  the number of C-multicast  Source Tree Joins sent  is n times
the number of RRs (most likely 2*n).  In PIM, this would have been done with
only  one message;  it  is BGP  that  makes the  number  of messages  needed
proportional to the number  of PEs in the VPN.  The reason  is that there is
no way in BGP to prevent each PE from issuing a Join.
  </pre>
</blockquote>
You can chose count the "number of messages" instead of the number of
times
"some message is processed by a node". But Appendix A counts the number
of times "some message is processed by
a node" (see comment in intro of this mail).  See comment in the intro
of this mail. You are not challenging here the correctness of the
analysis in Appendix
A.<br>
<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">PIM Join  Suppression is a big  savings when receivers  are widely dispersed
among the sites; if  each PE is attached to a site  with receivers, the need
to process someone  else's Join is a good tradeoff against  the need to send
your own Join.  If receivers are  concentrated in a few sites, this tradeoff
is not  so good.  But  many multicast applications  have the model of  a few
sources with a lot of widely dispersed receivers.
  </pre>
</blockquote>
As said above, Join suppression effects are accounted for in the
analysis.<br>
<br>
Let's get to the point: how does the statement above is supposed to
challenge
Appendix A ?<br>
(please quote the exact paragraph/line/counting that you disagree with)<br>
<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">Appendix A  is also incorrect about  the overhead related  to PIM Prune(S,G)
messages.
  </pre>
</blockquote>
<br>
Given what I already read, I feel that you just can't get away with
such a
blunt affirmation.<br>
<br>
The basic scenario considered, for what matters to Prunes, is that n
PEs, that had joined a stream, not leave a stream, one by one.<br>
- each joined PE, when it leave the stream (because JoinDesired became
false because the last CE left), sends a Prune<br>
- each Prune is processed by each PE of the VPN<br>
So, just considering the above, how many times did we had "a Prune is
processed" ?<br>
Answer: #PEs x #R_PEs<br>
<br>
The conclusion are just drawn from such basic arithmetic. The numbers
for the amount of processing for Prunes are nothing surprising, and are
(in order of
magnitude) similar to numbers for Joins.<br>
<br>
<br>
<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <blockquote type="cite">
    <pre wrap="">     By default when PIM LAN procedures are used, when a PE Prunes
     itself from a multicast tree, all other PEs check their own state
     to known if they are on the tree, in which case they send a PIM
     Join message to override the Prune.  The "did the last receiver
     leave?" question is thus implicitly replied to by all PE routers,
     for each PIM Prune message.

  We can see that answering the "last receiver leaves" question is a
  significant proportion of the work that the C-multicast routing
  building block has to make
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I don't see  how this conclusion follows.  If a PE  has "Upstream Join (S,G)
state" for  the logical interface connecting  the PEs, then it  always has a
timer that  it uses to refresh  the Join.  If  the PE sees a  Join(S,G) from
another PE,  it restarts  the timer (causing  Join Suppression).  If  the PE
sees  a  Prune(S,G)  from  another  PE,  it sets  the  timer  to  a  shorter
pre-computed randomized  value.  If,  before that timer  expires, it  sees a
Join(S,G) from another PE, it resets the timer and sets it back to its usual
value.  
  </pre>
</blockquote>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">It takes only one message to do a Prune, and one message to override it.
  </pre>
</blockquote>
True, but everyone knows this.   Everyone also knows that this PIM
Prune message is processed by all the
PEs: they all have to parse it, and lookup if they have a corresponding
state, and reset a timer.  If none of the PEs has state, nobody sends a
Join to override ; this "non response" is the result of the collective
work of all PEs, that have checked that they didn't had matching state.<br>
<br>
Only two routers did send a message, but every PE worked !<br>
<br>
This is what Appendix A refers to by saying : <br>
 <br>
     The "did the last
receiver leave?" question is thus *implicitly* replied to <br>
     by all PE
routers, for each PIM Prune message.<br>
<br>
<pre wrap="">&gt; Appendix A  would lead one to believe  that a Prune(S,G) immediately
&gt; causes lots of Join(S,G) messages to be sent; this is not true.  </pre>
<br>
We'll try and improve the sentence to avoid the misunderstanding,
insisting on the collective work to produce a non-response in due time,
letting the upstream node deduce that it can
prune traffic.<br>
<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">In BGP, if PE2  decides to prune itself from the (S,G)  tree, it has to send
each of the RRs a message withdrawing its Source Tree Join C-multicast route
for (S,G).   Then the RR  has to use  its BGP decision process  to determine
whether there  is another  Source Tree Join  C-multicast route for  the same
(S,G).   Then the  RR has  to distribute  the latter  route.  The  number of
messages is no fewer.
  </pre>
</blockquote>
<br>
What is counted in Appendix A is the amount of routing processing done
by the routing equipments, not the number of messages. And in the
example you take, in PIM case the amount of times there was
"some message processed by some equipment" is higher than in BGP. This
comment does not expose an incorrectness in Appendix A.<br>
<br>
<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">I think the  distinction that Appendix A  is really trying to get  at is the
following.

Consider a given interface of  a given node.  Suppose that interface appears
either as  the upstream interface or  as a downstream interface  of n trees.
Then let's  say that interface contains  n "branches".  The  total amount of
state that  that PIM needs to  maintain is roughly proportional  to the sum,
over all the node's interfaces, of the number of branches.
  </pre>
</blockquote>
<br>
(you omit the processing of prunes and first joins on each branch! )<br>
<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">Suppose that in a given PE, for a given VPN, there are i VRF interfaces, and
that the average number of branches per interface is m.  For each VPN, there
is also a  single PE-PE interface (a multiaccess interface  to which all the
PEs of the  VPN belong).  Let's suppose that this  link contains k branches,
where j of  these branches belong to trees  that the PE is a  member of, and
k-j belong to other trees in the VPN.

If PE-PE PIM is used, the amount  of state is proportional to i*m+k.  If BGP
C-multicast routing is  used, the amount of state  is proportional to i*m+j.
The incremental  state needed by PIM  is thus proportional to  k-j.  For the
state savings  to be significant,  one must assume  not only that k  is much
larger  than j,  but also  that k-j  is significiant  when compared  to i*m.
Basically this means that you need  to assume that each PE has receivers for
only a  small number  of the  VPN's trees, or  else that  there are  a small
number  of VRF interfaces  per VPN.   Whether or  not these  assumptions are
accurate depends of  course on the set of  multicast applications being used
by the customers.
  </pre>
</blockquote>
<br>
I don't get your point and I don't see why with PE-PE PIM "the amount
of state is proportional to i*m+k", since a PIM PE has to maintain
state only for streams it is joined to, thus rather i*m+j (it has to
process messages for joins for streams it is not joined to, but no
state to maintain, afaik).<br>
<br>
But anyway, the conclusion on state maintenance in Appendix A are that,
in order of magnitude, the amount of state is the same for all
approaches. This does not goes against the conclusion above, right ?<br>
<br>
(please be more explicit on what in Appendix A you challenge as
"incorrect")<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">There are also a couple of important factors which Appendix A has omitted:

- If you are using two different protocols to maintain each multicast state,
  then  the  total  amount  of  state is  effectively  doubled.   This  will
  generally result in  both a memory cost  and a CPU cost.  While  this is a
  "mere factor of  two," perhaps it deserves a mention  in any document that
  compares a control plane that uses two protocols (e.g.  PIM for PE-CE, BGP
  for PE-PE) to a control plane that uses only one.
 </pre>
</blockquote>
This was pointed out by Maria and already fixed in -03.<br>
(state maintenance in A.3, multiplied by 2; it is a linear factor not
changing the conclusions of Appendix A in O(x))<br>
<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">- For sparse mode, which is the type of multicast most commonly found in the
  enterprises that buy  the VPN service, there is quite  a bit of additional
  messaging in BGP that has not been considered.

  </pre>
</blockquote>
<span style="white-space: pre;">&gt; When PE1 receives a C-multicast
Source  Tree Join for a sparse mode<br>
&gt; group,it has  to generate a  Source Active  A-D Route.  It  needs
to<br>
&gt; send  a BGP update for  this route to each  RR.  Each RR needs  to<br>
&gt; send it  to each of PE2, ..., PE3.   So we have more messaging
which<br>
&gt; is O( # of  PEs in VPN). Needless  to say,  PIM also  has sparse<br>
&gt; mode overhead  which  hasn't been considered, but the point is that<br>
&gt; BGP overhead is not O(1).</span><br>
<br>
A few comments:<br>
- let me remind, that due to the complexity in comparing for a non-SSM
scenario, because the PIM and BGP procedures are significantly
different,
it just wasn't done ; the SPT/SSM part is common, and seems to me as
enough to guide the comparison<br>
- let me highlight that, this time, you choose to count the number of
times a message is processed, not how many messages are sent ; you seem
to change what you like to count depending on what you want to show :)<br>
- you highlight above a scenario with a total amount of processing
across all nodes in O(#mVPN_PE) and say that "the  <span
 style="white-space: pre;">BGP overhead is not O(1)" : this is correct,
but not significantly different from what we have in the base scenario
of Appendix A, for which </span>the  total amount of processing across
all nodes is O(#R_PE) for BGP, and  O(#mVPN_PE x #R_PE) for PIM<br>
<br>
So, while it could be conceivable to complement the analysis with a
non-SSM scenario in the line of the SSM scenario already considered, we
don't have yet seen a compelling argument to do it, since the change
wouldn't seem to fundamentally affect the comparison between PIM and
BGP.<br>
<br>
<br>
Now, there is another thing briefly looked at at the very end of
Appendix A:  the case of a more dynamic situation where PEs join and
leave many times. In the non-SSM case, as you mention, BGP would have
to  also produce the S-A A-D routes, and they would have to be
processed by all PEs.  But for one said downsteam PE joining the steam,
the upstream PE will advertises a new S-A A-D routes only if there was
no PE already joined to the stream. The impact on BGP thus depends a
lot on the Join/Prune dynamics...  As you say, the overhead of BGP for
the total amount of processing is not O(1) in that case, but will
depend on the number of PEs. But this is true to for PIM too, except
that for PIM we don't need to make strong hypothesis on the dynamics to
know the number of times a message is processed  (in the dynamic case,
PIM loses
the gains of join
suppression, and pays the full price of having each message being
processed by every PE in the mVPN). <br>
<br>
So well, if you can explain that such a case would expose conclusions
impacting what is in the document today, then it could be worth
including.<br>
<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">- One might get  the impression that the BGP scheme  eliminates any need for
  the C-PIM state machine to maintain  states for the PMSIs that connect the
  PEs over the backbone.  This is not true; </pre>
</blockquote>
We don't state anything contradictory with the above, AFAIK.<br>
Taking the exact amount/volume of state information would be doable,
but as far as I can tell it doesn't seem to change the orders of
magnitude.<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">  PEs must maintain Prune(S,G,rpt)
  for the PMSIs.  PEs receiving multicast  data over a PMSI must also do the
  RPF interface  check for  the arriving data,  considering the PMSI  as the
  "input interface".  The backbone does  not become transparent to the C-PIM
  interfaces just because PIM control packets do not flow over the PMSIs.
  </pre>
</blockquote>
The above is not related to the routing/processing load, hence not to
Appendix A.<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">Since  some of  the  conclusions of  the  draft depend  on  the analysis  in
Appendix  A,  I  think  those  conclusions  need to  be  removed  until  the
underlying analysis is corrected.
  </pre>
</blockquote>
<br>
Your comments will be useful to improve some points in  Appendix A
(thank you), but
nothing that changes the conclusions significantly enough to remove
stuff elsewhere in the document. Or if you really have such a claim, I
think that to take a decision we would need you to make it more
explicit what you would remove.<br>
<br>
<blockquote cite="mid:24994.1244735533@erosen-linux" type="cite">
  <pre wrap="">If and when  a corrected version of the analysis is  available, it should be
last called by the PIM WG, which  is where one might expect to find the most
expertise in PIM.  </pre>
</blockquote>
And a last call by IDR too for the BGP part ?<br>
<br>
Let's be serious: first, let's see if a "correction" is needed, and
delay the question until you really show in how the analysis would be
incorrect !<br>
<br>
Cheers,<br>
<br>
-Thomas<br>
</body>
</html>

--------------050702020106070403000704--

From raszuk@cisco.com  Fri Jun 19 09:55:14 2009
Return-Path: <raszuk@cisco.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27ABF3A6ACD for <l3vpn@core3.amsl.com>; Fri, 19 Jun 2009 09:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LegAHWOqpmx6 for <l3vpn@core3.amsl.com>; Fri, 19 Jun 2009 09:55:13 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 28E9A3A6A9C for <l3vpn@ietf.org>; Fri, 19 Jun 2009 09:55:13 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,254,1243814400"; d="scan'208";a="327489402"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2009 16:55:26 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5JGtQ3e016827;  Fri, 19 Jun 2009 09:55:26 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5JGtQbq019327; Fri, 19 Jun 2009 16:55:26 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 19 Jun 2009 09:55:26 -0700
Received: from [10.21.150.78] ([10.21.150.78]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 19 Jun 2009 09:55:25 -0700
Message-ID: <4A3BC2F6.9020403@cisco.com>
Date: Fri, 19 Jun 2009 09:55:18 -0700
From: Robert Raszuk <raszuk@cisco.com>
Organization: Cisco Systems
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Thomas Morin <thomas.morin@orange-ftgroup.com>
Subject: Re: LC Comments on "considerations" scaling analysis
References: <24994.1244735533@erosen-linux> <4A3BB670.9040407@orange-ftgroup.com>
In-Reply-To: <4A3BB670.9040407@orange-ftgroup.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Jun 2009 16:55:26.0184 (UTC) FILETIME=[BE4CE680:01C9F0FE]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1295; t=1245430526; x=1246294526; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raszuk@cisco.com; z=From:=20Robert=20Raszuk=20<raszuk@cisco.com> |Subject:=20Re=3A=20LC=20Comments=20on=20=22considerations= 22=20scaling=20analysis |Sender:=20; bh=3ghYbPNtYoFYDFzBcznwk85nxwlKLmpGqtuXm3NhLoI=; b=jb0da2zIYdGHsu77ujN5XeNeh6jVemaShuV7+0P2KyHJ4MJiOSjoqx+WjZ pmFVCt1LywcHzjVB8PfThfSF7O9RXDy1dI/kLD9eRXSn3EwKBcBPhBja8WW5 mbw7ypfRIW;
Authentication-Results: sj-dkim-4; header.From=raszuk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: Eric Rosen <erosen@cisco.com>, L3VPN <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: raszuk@cisco.com
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2009 16:55:14 -0000

Hi Thomas,

> And a last call by IDR too for the BGP part ?

As a matter of fact that would be indeed a great suggestion.

There are changes defined in the spec which silently modify the route 
reflection behaviour as specified in RFC4456. Those need to be clarified.

Example from draft-ietf-l3vpn-mvpn-considerations-03:

       "Using plain BGP route selection procedures,
       the route reflector will withdraw a C-multicast Source Tree Join
       for a said (C-S,C-G) when there is no PE advertising one anymore."

Quote from RFC4456:

    "When an RR receives a route from an IBGP peer, it selects the best
    path based on its path selection rule.  After the best path is
    selected, it must do the following depending on the type of peer it
    is receiving the best path from

       1) A route from a Non-Client IBGP peer:

          Reflect to all the Clients.

       2) A route from a Client peer:

          Reflect to all the Non-Client peers and also to the Client
          peers."

Therefor in "plain BGP" we advertise best path and withdraw best paths 
or replace them with implicit withdraw. And you may have changes to 
C-multicast best path each time you receive one from any PE or best path 
owner PE withdraws one.

Cheers,
R.







From tme@americafree.tv  Sat Jun 20 13:40:41 2009
Return-Path: <tme@americafree.tv>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6674F3A6955 for <l3vpn@core3.amsl.com>; Sat, 20 Jun 2009 13:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.309
X-Spam-Level: 
X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOwouh1sgicQ for <l3vpn@core3.amsl.com>; Sat, 20 Jun 2009 13:40:40 -0700 (PDT)
Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 9992528C13D for <l3vpn@ietf.org>; Sat, 20 Jun 2009 13:40:40 -0700 (PDT)
Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 908C240F0061 for <l3vpn@ietf.org>; Sat, 20 Jun 2009 16:40:54 -0400 (EDT)
Message-Id: <A12DF6CA-0DA0-4C3E-9322-F4E8F8CB108B@americafree.tv>
From: Marshall Eubanks <tme@americafree.tv>
To: l3vpn@ietf.org
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: L3VPN Schedule
Date: Sat, 20 Jun 2009 16:40:52 -0400
X-Mailer: Apple Mail (2.935.3)
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jun 2009 20:40:41 -0000

The draft IETF schedule is out, and L3VPN is scheduled for Monday =20
afternoon :

http://www.ietf.org/meetings/75/75-Draft-Agenda.pdf

1520-1720 Afternoon Session II =96 2 hour
  APP vcarddav vCard and CardDAV WG
  INT autoconf Ad-Hoc Network Autoconfiguration WG
  OPS ipfix IP Flow Information Export WG
  OPS grow Global Routing Operations WG
  RAI drinks Data for Reachability of Inter/tra-NetworK SIP WG
  RTG idr Inter-Domain Routing WG
  RTG l3vpn Layer 3 Virtual Private Networks WG
  SEC hokey Handover Keying WG

1.) If you see any unsupportable conflicts here, please speak up.

2.) Please send us proposals for presentations.

3.) Don't forget the schedule :

July 6, Monday - Internet Draft Cut-off for initial document (-00) =20
submission by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID =20
Submission Tool.
July 13, Monday - Internet Draft final submission cut-off by 17:00 PDT =20=

(24:00 UTC/GMT), upload using IETF ID Submission Tool.
July 15, Wednesday - Draft Working Group agendas due by 17:00 PDT =20
(24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool.
July 17, Friday - Early-Bird registration and payment cut-off at 17:00 =20=

PDT (24:00 UTC/GMT).

Regards
Marshall=

From raszuk@cisco.com  Sat Jun 20 13:50:29 2009
Return-Path: <raszuk@cisco.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE53A28C13D for <l3vpn@core3.amsl.com>; Sat, 20 Jun 2009 13:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co79XnsWkKnM for <l3vpn@core3.amsl.com>; Sat, 20 Jun 2009 13:50:29 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 16E4F3A6B38 for <l3vpn@ietf.org>; Sat, 20 Jun 2009 13:50:29 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,260,1243814400"; d="scan'208";a="328360410"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 20 Jun 2009 20:50:43 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5KKohIK010900;  Sat, 20 Jun 2009 13:50:43 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n5KKoh03004014; Sat, 20 Jun 2009 20:50:43 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Sat, 20 Jun 2009 13:50:43 -0700
Received: from [10.21.67.90] ([10.21.67.90]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Sat, 20 Jun 2009 13:50:42 -0700
Message-ID: <4A3D4B9B.9010303@cisco.com>
Date: Sat, 20 Jun 2009 13:50:35 -0700
From: Robert Raszuk <raszuk@cisco.com>
Organization: Cisco Systems
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Marshall Eubanks <tme@americafree.tv>
Subject: Re: L3VPN Schedule
References: <A12DF6CA-0DA0-4C3E-9322-F4E8F8CB108B@americafree.tv>
In-Reply-To: <A12DF6CA-0DA0-4C3E-9322-F4E8F8CB108B@americafree.tv>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 20 Jun 2009 20:50:42.0774 (UTC) FILETIME=[C6DB5760:01C9F1E8]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1505; t=1245531043; x=1246395043; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raszuk@cisco.com; z=From:=20Robert=20Raszuk=20<raszuk@cisco.com> |Subject:=20Re=3A=20L3VPN=20Schedule |Sender:=20; bh=/tQtd6JsS2EW3F8vaGEWiNS90GXe3rfXgoW0yywOZnM=; b=ZheSI4umqg4H3/vK/PjSfP98dWBC+2nZxdkIsVLCDTEAaChZjEfHY3I+DF 7SwccAIDiHNnJz8prdNs7xVGgOptNzIJfOmNx39wzoERsYSW8tbgv4GJmikm 9NnA/sJm//;
Authentication-Results: sj-dkim-4; header.From=raszuk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: raszuk@cisco.com
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jun 2009 20:50:29 -0000

 > 1.) If you see any unsupportable conflicts here, please speak up.

What a brilliant arrangement to have GROW & IDR & L3VPN to run in 
parallel. I don't recall any IETF with such great overlap.

Cheers,
R.


> The draft IETF schedule is out, and L3VPN is scheduled for Monday 
> afternoon :
> 
> http://www.ietf.org/meetings/75/75-Draft-Agenda.pdf
> 
> 1520-1720 Afternoon Session II – 2 hour
>  APP vcarddav vCard and CardDAV WG
>  INT autoconf Ad-Hoc Network Autoconfiguration WG
>  OPS ipfix IP Flow Information Export WG
>  OPS grow Global Routing Operations WG
>  RAI drinks Data for Reachability of Inter/tra-NetworK SIP WG
>  RTG idr Inter-Domain Routing WG
>  RTG l3vpn Layer 3 Virtual Private Networks WG
>  SEC hokey Handover Keying WG
> 
> 1.) If you see any unsupportable conflicts here, please speak up.
> 
> 2.) Please send us proposals for presentations.
> 
> 3.) Don't forget the schedule :
> 
> July 6, Monday - Internet Draft Cut-off for initial document (-00) 
> submission by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission 
> Tool.
> July 13, Monday - Internet Draft final submission cut-off by 17:00 PDT 
> (24:00 UTC/GMT), upload using IETF ID Submission Tool.
> July 15, Wednesday - Draft Working Group agendas due by 17:00 PDT (24:00 
> UTC/GMT), upload using IETF Meeting Materials Management Tool.
> July 17, Friday - Early-Bird registration and payment cut-off at 17:00 
> PDT (24:00 UTC/GMT).
> 
> Regards
> Marshall


From yakov@juniper.net  Tue Jun 23 06:19:15 2009
Return-Path: <yakov@juniper.net>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2568C3A6A3C for <l3vpn@core3.amsl.com>; Tue, 23 Jun 2009 06:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60A91z6gmxYq for <l3vpn@core3.amsl.com>; Tue, 23 Jun 2009 06:19:14 -0700 (PDT)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 1D2863A6A2C for <l3vpn@ietf.org>; Tue, 23 Jun 2009 06:19:14 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSkDWTVR37isZ84RroIot3pGJY3o3tov0@postini.com; Tue, 23 Jun 2009 06:19:30 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 23 Jun 2009 05:59:09 -0700
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 05:59:09 -0700
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 05:59:09 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 05:59:08 -0700
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n5NCx8L40418; Tue, 23 Jun 2009 05:59:08 -0700 (PDT)	(envelope-from yakov@juniper.net)
Message-ID: <200906231259.n5NCx8L40418@magenta.juniper.net>
To: erosen@cisco.com
Subject: Re: LC comment on "considerations" inter-AS section 
In-Reply-To: <6572.1245076575@erosen-linux> 
References: <6572.1245076575@erosen-linux>
X-MH-In-Reply-To: Eric Rosen <erosen@cisco.com> message dated "Mon, 15 Jun 2009 10:36:15 -0400."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <71041.1245761948.1@juniper.net>
Date: Tue, 23 Jun 2009 05:59:08 -0700
From: Yakov Rekhter <yakov@juniper.net>
X-OriginalArrivalTime: 23 Jun 2009 12:59:08.0630 (UTC) FILETIME=[6578D760:01C9F402]
Cc: l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2009 13:19:15 -0000

Eric,

> In  the  discussion  of inter-AS,  I  think  the  draft should  discuss  the
> following issues:
> 
> - In  order to  use the  segmented inter-AS  procedures, each  ASBR  must be
>  pre-configured with the  MVPNs whose trees pass through  it.  (See section
>  8.2.1.1 of draft-ietf-l3vpn-2547bis-mcast.)

Let's examine your claim that "in order to use the segmented inter-AS
procedures, each ASBR must be preconfigured with the MVPNs whose
trees pass through it".

Here are the relevant quotes:

>From  8.2.1.1 of draft-ietf-l3vpn-2547bis-mcast-08.txt:

      a. A Route Distinguisher for the MVPN. For a given MVPN each ASBR
         in the AS must use the same RD when advertising this
         information to other ASBRs. To accomplish this all the ASBRs
         within that AS, that are configured to support the MVPN, MUST
         be configured with the same RD for that MVPN. This RD MUST be
         of Type 0, MUST embed the autonomous system number of the AS.

>From 9.2.1 of draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt:

     + The route carries a single MCAST-VPN NLRI with the RD set to the
       RD configured for that MVPN on the ASBR, and the Source AS set to
       the Autonomous System number of the ASBR.

>From 9.2 of draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt:

     + If the ASBR originates an Inter-AS I-PMSI A-D route for a
       particular MVPN present on some of the PEs within its own AS, the
       ASBR MUST be (auto-)configured with an RD for that MVPN. It is
       RECOMMENDED that one of the following two options be used:

       (1) To allow more aggregation of Inter-AS I-PMSI A-D routes it is
       recommended that all the ASBRs within an AS that are configured
       to originate an Inter-AS I-PMSI A-D route for a particular MVPN
       be configured with the same RD (although for a given MVPN each AS
       may assign this RD on its own, without coordination with other
       ASes).

       (2) To allow more control over spreading MVPN traffic among
       multiple ASBRs within a given AS it is recommended for each ASBR
       to have a distinct RD per each MVPN, in which case such an RD
       SHOULD be auto-configured.

With all the above in mind it is clear that the only item that
involves configuration on ASBRs is the RD. With this in mind let's
look at the issue of configuring RDs on ASBRs.

>From the above quotes it should be clear that section 8.2.1.1 of
draft-ietf-l3vpn-2547bis-mcast-08.txt that you referred to in your
e-mail is at best incomplete (and at worse incorrect), as it only
covers option (1) from 9.2 of draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt,
but does *NOT* cover option (2). While option (1) does involve
configuring RDs, option (2) explicitly states that RDs "SHOULD be
auto-configured."

Thus, your claim above that "ASBR  must be pre-configured with the
MVPNs whose trees pass through it" totally ignores the fact that
it applies only to one particular option (option (1) above). Your
claim is *incorrect* in the context of option (2). What is correct
though is that section 8.2.1.1 that you refers to is incomplete/incorrect.

Yakov.

From thomas.morin@orange-ftgroup.com  Tue Jun 23 08:53:34 2009
Return-Path: <thomas.morin@orange-ftgroup.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3D9428C36B for <l3vpn@core3.amsl.com>; Tue, 23 Jun 2009 08:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.516
X-Spam-Level: 
X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=0.734,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLWtA-mXTHVm for <l3vpn@core3.amsl.com>; Tue, 23 Jun 2009 08:53:33 -0700 (PDT)
Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id B0C1528C38B for <l3vpn@ietf.org>; Tue, 23 Jun 2009 08:53:31 -0700 (PDT)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 23 Jun 2009 17:53:46 +0200
Received: from [10.193.15.230] ([10.193.15.230]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 23 Jun 2009 17:53:45 +0200
Message-ID: <4A40FA87.6040404@orange-ftgroup.com>
Date: Tue, 23 Jun 2009 17:53:43 +0200
From: Thomas Morin <thomas.morin@orange-ftgroup.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090623 Shredder/3.0b3pre
MIME-Version: 1.0
To: l3vpn@ietf.org
Subject: Re: LC comment on "considerations" inter-AS section
References: <6572.1245076575@erosen-linux> <200906231259.n5NCx8L40418@magenta.juniper.net>
In-Reply-To: <200906231259.n5NCx8L40418@magenta.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Jun 2009 15:53:45.0505 (UTC) FILETIME=[CA2D1910:01C9F41A]
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2009 15:53:34 -0000

Yakov, Eric, folks,

Ok, so if I understand correctly, with for inter-AS segmented approach 
we have:
- option (1), which requires pre-configuration, and allows the highest 
level of aggregation (one tunnel per source AS per mVPN)
- option (2), that does not require pre-configuration (and in fact for 
which autoconfig is recommended), and that allows aggregation to some 
degree (one tunnel per mVPN per ASBR per source AS)
And for the non-segmented approach: no pre-configuration is required in 
any case, and no aggregation is possible (one tunnel per source PE  per 
mVPN).

My take would be as follows:
- we can certainly add the requested precision into the draft on how 
pre-config is needed to have the maximum level of aggregation
- since pre-config is not needed for option (2) which still allows a 
level of aggregation of an order of magnitude higher than the 
non-segmented approach, I don't think that we have rationale to change 
the conclusions of the section (the weight of the updated point is still 
significant in the comparison, and its only one among others)

Feedback is welcome,

-Thomas

(PS: is there some way section 8.2.1.1 of draft-ietf-l3vpn-2547bis-mcast 
can be updated ?)


Yakov Rekhter wrote:
> Eric,
>
>    
>> In  the  discussion  of inter-AS,  I  think  the  draft should  discuss  the
>> following issues:
>>
>> - In  order to  use the  segmented inter-AS  procedures, each  ASBR  must be
>>   pre-configured with the  MVPNs whose trees pass through  it.  (See section
>>   8.2.1.1 of draft-ietf-l3vpn-2547bis-mcast.)
>>      
> Let's examine your claim that "in order to use the segmented inter-AS
> procedures, each ASBR must be preconfigured with the MVPNs whose
> trees pass through it".
>
> Here are the relevant quotes:
>
>  From  8.2.1.1 of draft-ietf-l3vpn-2547bis-mcast-08.txt:
>
>        a. A Route Distinguisher for the MVPN. For a given MVPN each ASBR
>           in the AS must use the same RD when advertising this
>           information to other ASBRs. To accomplish this all the ASBRs
>           within that AS, that are configured to support the MVPN, MUST
>           be configured with the same RD for that MVPN. This RD MUST be
>           of Type 0, MUST embed the autonomous system number of the AS.
>
>  From 9.2.1 of draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt:
>
>       + The route carries a single MCAST-VPN NLRI with the RD set to the
>         RD configured for that MVPN on the ASBR, and the Source AS set to
>         the Autonomous System number of the ASBR.
>
>  From 9.2 of draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt:
>
>       + If the ASBR originates an Inter-AS I-PMSI A-D route for a
>         particular MVPN present on some of the PEs within its own AS, the
>         ASBR MUST be (auto-)configured with an RD for that MVPN. It is
>         RECOMMENDED that one of the following two options be used:
>
>         (1) To allow more aggregation of Inter-AS I-PMSI A-D routes it is
>         recommended that all the ASBRs within an AS that are configured
>         to originate an Inter-AS I-PMSI A-D route for a particular MVPN
>         be configured with the same RD (although for a given MVPN each AS
>         may assign this RD on its own, without coordination with other
>         ASes).
>
>         (2) To allow more control over spreading MVPN traffic among
>         multiple ASBRs within a given AS it is recommended for each ASBR
>         to have a distinct RD per each MVPN, in which case such an RD
>         SHOULD be auto-configured.
>
> With all the above in mind it is clear that the only item that
> involves configuration on ASBRs is the RD. With this in mind let's
> look at the issue of configuring RDs on ASBRs.
>
>  From the above quotes it should be clear that section 8.2.1.1 of
> draft-ietf-l3vpn-2547bis-mcast-08.txt that you referred to in your
> e-mail is at best incomplete (and at worse incorrect), as it only
> covers option (1) from 9.2 of draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt,
> but does *NOT* cover option (2). While option (1) does involve
> configuring RDs, option (2) explicitly states that RDs "SHOULD be
> auto-configured."
>
> Thus, your claim above that "ASBR  must be pre-configured with the
> MVPNs whose trees pass through it" totally ignores the fact that
> it applies only to one particular option (option (1) above). Your
> claim is *incorrect* in the context of option (2). What is correct
> though is that section 8.2.1.1 that you refers to is incomplete/incorrect.
>
> Yakov.
>    

From wwwrun@core3.amsl.com  Tue Jun 23 10:35:41 2009
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: l3vpn@ietf.org
Delivered-To: l3vpn@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 4CC0A3A6EE4; Tue, 23 Jun 2009 10:35:40 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <ietf-announce@ietf.org> 
From: The IESG <iesg-secretary@ietf.org>
Subject: Last Call: draft-ietf-l3vpn-as4octet-ext-community (Four-octet  AS Specific BGP Extended Community) to Proposed Standard 
Message-Id: <20090623173541.4CC0A3A6EE4@core3.amsl.com>
Date: Tue, 23 Jun 2009 10:35:41 -0700 (PDT)
Cc: l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ietf@ietf.org
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2009 17:35:41 -0000

The IESG has received a request from the Layer 3 Virtual Private 
Networks WG (l3vpn) to consider the following document:

- 'Four-octet AS Specific BGP Extended Community '
   <draft-ietf-l3vpn-as4octet-ext-community-03.txt> as a Proposed 
   Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2009-07-07. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-as4octet-ext-community-03.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17731&rfc_flag=0


From wwwrun@core3.amsl.com  Tue Jun 23 12:27:00 2009
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: l3vpn@ietf.org
Delivered-To: l3vpn@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 33D8F3A6ED6; Tue, 23 Jun 2009 12:26:59 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <ietf-announce@ietf.org> 
From: The IESG <iesg-secretary@ietf.org>
Subject: Last Call: draft-ietf-l3vpn-v6-ext-communities (IPv6 Address  Specific BGP Extended Communities Attribute) to Proposed Standard 
Message-Id: <20090623192700.33D8F3A6ED6@core3.amsl.com>
Date: Tue, 23 Jun 2009 12:27:00 -0700 (PDT)
Cc: l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ietf@ietf.org
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2009 19:27:00 -0000

The IESG has received a request from the Layer 3 Virtual Private 
Networks WG (l3vpn) to consider the following document:

- 'IPv6 Address Specific BGP Extended Communities Attribute '
   <draft-ietf-l3vpn-v6-ext-communities-02.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2009-07-07. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-v6-ext-communities-02.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17732&rfc_flag=0


From shane@castlepoint.net  Wed Jun 24 19:59:44 2009
Return-Path: <shane@castlepoint.net>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B7C3A6F91; Wed, 24 Jun 2009 19:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.117
X-Spam-Level: 
X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPPNbfm8Dq7i; Wed, 24 Jun 2009 19:59:43 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 7D6F028C407; Wed, 24 Jun 2009 19:59:39 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id E2C0E2684EA; Wed, 24 Jun 2009 20:59:26 -0600 (MDT)
Received: from mbpw.castlepoint.net (71-215-80-228.hlrn.qwest.net [71.215.80.228]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 24 Jun 2009 20:59:26 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.80.228; client-port=4790; syn-fingerprint=65535:55:1:64:M1452,N,W3,N,N,T,S; data-bytes=0
Message-Id: <F2B65E38-9D4D-4A6D-B949-B684092881A4@castlepoint.net>
From: Shane Amante <shane@castlepoint.net>
To: l3vpn@ietf.org, l2vpn@ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Results of Poll on BGP IPv4 Address Specific Extended Community
Date: Wed, 24 Jun 2009 20:59:11 -0600
X-Mailer: Apple Mail (2.935.3)
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2009 02:59:44 -0000

Hello,

The following are the results and recommendation regarding the  
conflicting assignment for the BGP IPv4 Address Specific Extended  
Community, as per the following e-mail: <http://www.ietf.org/mail-archive/web/l2vpn/current/msg02123.html 
 >.

The following are the results of the survey and subsequent questions  
I've asked of the respondents:
1)  We received a total of 4 responses.
2)  There are a total of 4 implementations, two for /each/ draft:
  + draft-ietf-l2vpn-signaling: 2 implementations
  + draft-ietf-l3vpn-2547bis-mcast-bgp: 2 implementations
3)  I've confirmed with all respondents that all of the above  
implementations have implemented the 0x010A BGP IPv4 Address Specific  
Extended Community.
4)  Finally, I've asked the implementers to list the date their  
implementations were "Generally Available", as a 'proxy' toward  
answering how long deployments have existed in the field, (responses  
anonymized as per the respondents request):
  a)  draft-ietf-l2vpn-signaling:
      - Implementation X: 1Q/2007 -- 2.5 years ago
      - Implementation Y: 1Q/2008 -- 1.5 years ago
      ============================================
      Average Age of Above Implementations: ~2 years old
  b)  draft-ietf-l3vpn-2547bis-mcast-bgp:
      - Implementation M: 3Q/2007 -- 2 years ago
      - Implementation N: 2Q/2009 -- 0 months ago
      ============================================
      Average Age of Above Implementations: ~1 years old

In summary:
- The "average age" of the implementations of draft-ietf-l2vpn- 
signaling is 1 year greater than draft-ietf-l3vpn-2547bis-mcast-bgp;  
and,
- draft-ietf-l2vpn-signaling was developed and released approximately  
6 months prior to draft-ietf-l3vpn-2547bis-mcast-bgp

Given the above, it is our recommendation that IANA should assign the  
0x010A BGP IPv4 Address Specific Extended Community to draft-ietf- 
l2vpn-signaling.  Furthermore, IANA should then allocate a new BGP  
IPv4 Address Specific Extended Community to draft-ietf-l3vpn-2547bis- 
mcast-bgp.

Finally, FWIW, we have informed the AD's of both WG's of the results  
of the survey and our recommendation contained above, as well, and  
have not heard any feedback that they disagree with the survey or our  
recommendation.

-shane

From jgs@juniper.net  Thu Jun 25 12:04:38 2009
Return-Path: <jgs@juniper.net>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27EF73A67D9 for <l3vpn@core3.amsl.com>; Thu, 25 Jun 2009 12:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SboYPZVH5NT5 for <l3vpn@core3.amsl.com>; Thu, 25 Jun 2009 12:04:37 -0700 (PDT)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 1D1723A6FA5 for <l3vpn@ietf.org>; Thu, 25 Jun 2009 12:04:29 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSkPKCTgx6DZm8wfWcDdrslWZjTWGnPuH@postini.com; Thu, 25 Jun 2009 12:04:47 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 25 Jun 2009 11:36:15 -0700
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 11:36:15 -0700
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 11:36:15 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jun 2009 11:36:14 -0700
Received: from [172.16.13.201] ([172.16.13.201])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n5PIaEL69846	for <l3vpn@ietf.org>; Thu, 25 Jun 2009 11:36:14 -0700 (PDT)	(envelope-from jgs@juniper.net)
Message-ID: <8D483AA4-4BCE-4A52-BC4A-C8D64166701F@juniper.net>
From: "John G. Scudder" <jgs@juniper.net>
To: l3vpn@ietf.org
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Apple Message framework v935.3)
Subject: Fwd: New Version Notification for draft-scudder-idr-rt-constrain-lite-00 
Date: Thu, 25 Jun 2009 14:36:11 -0400
References: <20090625183020.9B10F3A69E1@core3.amsl.com>
X-Mailer: Apple Mail (2.935.3)
X-OriginalArrivalTime: 25 Jun 2009 18:36:14.0891 (UTC) FILETIME=[D216D7B0:01C9F5C3]
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2009 19:04:38 -0000

FYI.

--John

Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission@ietf.org>
> Date: June 25, 2009 2:30:20 PM GMT-04:00
> To: John Scudder <jgs@juniper.net>
> Cc: "uttaro@att.com" <uttaro@att.com>, "pmohapat@cisco.com" <pmohapat@cisco.com 
> >
> Subject: New Version Notification for draft-scudder-idr-rt-constrain- 
> lite-00
>
>
> A new version of I-D, draft-scudder-idr-rt-constrain-lite-00.txt has  
> been successfuly submitted by John Scudder and posted to the IETF  
> repository.
>
> Filename:	 draft-scudder-idr-rt-constrain-lite
> Revision:	 00
> Title:		 RT-Constrain Lite for Provider Edge Routers
> Creation_date:	 2009-06-25
> WG ID:		 Independent Submission
> Number_of_pages: 5
>
> Abstract:
> RFC 4684, "Constrained Route Distribution for Border Gateway
> Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol
> (IP) Virtual Private Networks (VPNs)" provides a powerful and general
> means for BGP speakers to exchange and propagate Route Target
> reachability information which is used for cooperative route
> filtering.  However, the complexity of implementing the entire
> specification may have impeded its widespread deployment.  This
> document specifies the subset of functionality which is required for
> a provider edge router ("PE") to originate Route Target NLRI.  Such
> PEs need not implement any filtering functionality.
>
>
>
> The IETF Secretariat.
>
>


From raszuk@cisco.com  Sat Jun 27 08:29:34 2009
Return-Path: <raszuk@cisco.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54433A6C87; Sat, 27 Jun 2009 08:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.908
X-Spam-Level: 
X-Spam-Status: No, score=-5.908 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng18LZyFi+a2; Sat, 27 Jun 2009 08:29:33 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5C5F228C218; Sat, 27 Jun 2009 08:29:14 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,301,1243814400"; d="scan'208";a="333038847"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Jun 2009 15:29:33 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5RFTXuQ012674;  Sat, 27 Jun 2009 08:29:33 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5RFTXfe007338; Sat, 27 Jun 2009 15:29:33 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Sat, 27 Jun 2009 08:29:33 -0700
Received: from [10.21.70.167] ([10.21.70.167]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Sat, 27 Jun 2009 08:29:32 -0700
Message-ID: <4A463ADA.1030503@cisco.com>
Date: Sat, 27 Jun 2009 08:29:30 -0700
From: Robert Raszuk <raszuk@cisco.com>
Organization: Cisco Systems
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "John G. Scudder" <jgs@juniper.net>
Subject: Re: [Idr] Fwd: New Version Notification for	draft-scudder-idr-rt-constrain-lite-00
References: <20090625183020.9B10F3A69E1@core3.amsl.com> <06AB6078-835E-437B-AB13-F64AD78E4C35@juniper.net>
In-Reply-To: <06AB6078-835E-437B-AB13-F64AD78E4C35@juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Jun 2009 15:29:33.0153 (UTC) FILETIME=[1228C510:01C9F73C]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3502; t=1246116573; x=1246980573; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raszuk@cisco.com; z=From:=20Robert=20Raszuk=20<raszuk@cisco.com> |Subject:=20Re=3A=20[Idr]=20Fwd=3A=20New=20Version=20Notifi cation=20for=09draft-scudder-idr-rt-constrain-lite-00 |Sender:=20; bh=G4bxr19TJdHhgxMPDE1JBr1M3Ppr0oybTFiokDCunz4=; b=tznrHbWJbEf/DkGSOO7bN0YhQ3LOq22KNNze8ZrOU/wEpdZlbZRbEzW9C3 kOiv578MHRdT3uMDcdzWHs4qlu2hJqDmzA6t6Lif5LozN2SQUVM9k/kfhdqd W6lr845ftx;
Authentication-Results: sj-dkim-3; header.From=raszuk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
Cc: idr List <idr@ietf.org>, L3VPN <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: raszuk@cisco.com
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2009 15:29:34 -0000

Hello John,

Let me share with you two observations:

Observation #1:

Let's notice that original RFC4684 already well defines rt-constrain 
lite in it's published text:

    "A BGP speaker MAY participate in the distribution of Route Target
    information without using the learned information for purposes of VPN
    NLRI output route filtering, although this is discouraged."

As RT-constrain lite draft does exactly the above paragraph it is at 
least redundant.

Observation #2:

The original RFC4684 says:

    "A VPN NLRI route should be advertised to a peer that participates in
    the exchange of Route Target membership information if that peer has
    advertised either the default Route Target membership NLRI or a Route
    Target membership NLRI containing any of the targets contained in the
    extended communities attribute of the VPN route in question."

RT-C lite says:

    "Specifically, the PE need only implement the ability to send Route
    Target Membership NLRI; it need not have the ability to receive,
    store and filter upon such information."

That directly violates RFC4684 as quoted above. After exchanged the 4684 
capabilities the PE should wait for the default rt filter or atomic one 
before it starts any VPN route advertisement.

The same for the RR side ... RR may expect after negotiating RFC4684 
capability not to receive any routes from a peer until it has send 
default rt NLRI or an atomic one. That may be used for peer 
prioritization as an example.

Conclusion of the observation #2 above leads me to believe that 
reception and parsing of at least default rt-filter by RT-Constrain lite 
is required.

But I am more interested to find out what is missing today in RFC4684 in 
the light of the first observation.

Cheers,
R.


> FYI.
> 
> --John
> 
> Begin forwarded message:
> 
>> From: IETF I-D Submission Tool <idsubmission@ietf.org>
>> Date: June 25, 2009 2:30:20 PM GMT-04:00
>> To: John Scudder <jgs@juniper.net>
>> Cc: "uttaro@att.com" <uttaro@att.com>, "pmohapat@cisco.com" 
>> <pmohapat@cisco.com>
>> Subject: New Version Notification for 
>> draft-scudder-idr-rt-constrain-lite-00
>>
>>
>> A new version of I-D, draft-scudder-idr-rt-constrain-lite-00.txt has 
>> been successfuly submitted by John Scudder and posted to the IETF 
>> repository.
>>
>> Filename:     draft-scudder-idr-rt-constrain-lite
>> Revision:     00
>> Title:         RT-Constrain Lite for Provider Edge Routers
>> Creation_date:     2009-06-25
>> WG ID:         Independent Submission
>> Number_of_pages: 5
>>
>> Abstract:
>> RFC 4684, "Constrained Route Distribution for Border Gateway
>> Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol
>> (IP) Virtual Private Networks (VPNs)" provides a powerful and general
>> means for BGP speakers to exchange and propagate Route Target
>> reachability information which is used for cooperative route
>> filtering.  However, the complexity of implementing the entire
>> specification may have impeded its widespread deployment.  This
>> document specifies the subset of functionality which is required for
>> a provider edge router ("PE") to originate Route Target NLRI.  Such
>> PEs need not implement any filtering functionality.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 


From jgs@juniper.net  Sat Jun 27 11:19:09 2009
Return-Path: <jgs@juniper.net>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BAAB3A6883; Sat, 27 Jun 2009 11:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucTvgJyYBS5K; Sat, 27 Jun 2009 11:19:08 -0700 (PDT)
Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 204F03A6870; Sat, 27 Jun 2009 11:19:00 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSkZip343Yo8FNz7QJFHZz8p2ykPP7ktE@postini.com; Sat, 27 Jun 2009 11:19:26 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sat, 27 Jun 2009 11:17:13 -0700
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Jun 2009 11:17:13 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Jun 2009 11:17:13 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Jun 2009 11:17:12 -0700
Received: from [172.16.13.201] ([172.16.13.201])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n5RIHBL98818; Sat, 27 Jun 2009 11:17:11 -0700 (PDT)	(envelope-from jgs@juniper.net)
Message-ID: <9AE4DF10-F7F6-4976-A779-929D47478CB3@juniper.net>
From: "John G. Scudder" <jgs@juniper.net>
To: "raszuk@cisco.com" <raszuk@cisco.com>
In-Reply-To: <4A463ADA.1030503@cisco.com>
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-rt-constrain-lite-00
Date: Sat, 27 Jun 2009 14:17:10 -0400
References: <20090625183020.9B10F3A69E1@core3.amsl.com> <06AB6078-835E-437B-AB13-F64AD78E4C35@juniper.net> <4A463ADA.1030503@cisco.com>
X-Mailer: Apple Mail (2.935.3)
X-OriginalArrivalTime: 27 Jun 2009 18:17:12.0859 (UTC) FILETIME=[7E3616B0:01C9F753]
Cc: idr List <idr@ietf.org>, L3VPN <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2009 18:19:09 -0000

Robert, thanks for your comments.

Your main question is essentially what the contribution of rt- 
constrain-lite is.  Fair enough.  There are two contributions, to my  
way of thinking.  The first and more important is that (as I will  
explain below) there are normative changes between rt-contrain-lite  
and rt-constrain.  The two are interoperable, but not identical.  The  
second is that for many deployment scenarios (specifically PE routers)  
full-on rt-constrain is more than is needed.  The rt-constrain-lite  
document would provide a single document that could be cited in  
procurements, rather than either citing full rt-constrain (even though  
it provides more than is required) or citing full rt-constrain with  
caveats (which is a messy way of doing it).

As for the normative changes: you actually identify this yourself, in  
your message.  As you point out, rt-constrain-lite specifically  
exempts the PE from having to honor filtering for received rt- 
constrain routes.  This is an interoperable difference between the two.

As an aside, you've also inadvertently pointed out a bug in the rt- 
constrain specification.  The first paragraph you quote:

>    "A BGP speaker MAY participate in the distribution of Route Target
>    information without using the learned information for purposes of  
> VPN
>    NLRI output route filtering, although this is discouraged."

would not seem to be compatible with the second one you quote:

>    "A VPN NLRI route should be advertised to a peer that  
> participates in
>    the exchange of Route Target membership information if that peer  
> has
>    advertised either the default Route Target membership NLRI or a  
> Route
>    Target membership NLRI containing any of the targets contained in  
> the
>    extended communities attribute of the VPN route in question."

although I guess you can observe that the latter paragraph is a  
"should" and not a "must".  (If you take this point of view you would  
also have to agree that rt-constrain-lite does not "directly violate"  
RFC4684.)

Regarding your secondary question about the PE honoring, or not, rt- 
constrain route filtering -- if the PE were required to do this, that  
is the same as requiring it to do a full RFC4684 implementation, which  
would defeat the point of a "lite" flavor.  I don't think it's  
reasonable to say "just parse default but nothing else" since it's  
perfectly permissible for the RR to never send a default, which would  
leave the PE stuck forever.

However, this does lead me to consider that you could ask the PE to  
wait until it has received any rt-constrain route at all from the RR  
before advertising VPN routes.  This heuristic would seem to be almost  
the same as waiting for the default route without having the same  
failure mode if the default is never sent.

Regards,

--John

On Jun 27, 2009, at 11:29 AM, Robert Raszuk wrote:
> Observation #1:
>
> Let's notice that original RFC4684 already well defines rt-constrain
> lite in it's published text:
>
>    "A BGP speaker MAY participate in the distribution of Route Target
>    information without using the learned information for purposes of  
> VPN
>    NLRI output route filtering, although this is discouraged."
>
> As RT-constrain lite draft does exactly the above paragraph it is at
> least redundant.
>
> Observation #2:
>
> The original RFC4684 says:
>
>    "A VPN NLRI route should be advertised to a peer that  
> participates in
>    the exchange of Route Target membership information if that peer  
> has
>    advertised either the default Route Target membership NLRI or a  
> Route
>    Target membership NLRI containing any of the targets contained in  
> the
>    extended communities attribute of the VPN route in question."
>
> RT-C lite says:
>
>    "Specifically, the PE need only implement the ability to send Route
>    Target Membership NLRI; it need not have the ability to receive,
>    store and filter upon such information."
>
> That directly violates RFC4684 as quoted above. After exchanged the  
> 4684
> capabilities the PE should wait for the default rt filter or atomic  
> one
> before it starts any VPN route advertisement.
>
> The same for the RR side ... RR may expect after negotiating RFC4684
> capability not to receive any routes from a peer until it has send
> default rt NLRI or an atomic one. That may be used for peer
> prioritization as an example.
>
> Conclusion of the observation #2 above leads me to believe that
> reception and parsing of at least default rt-filter by RT-Constrain  
> lite
> is required.
>
> But I am more interested to find out what is missing today in  
> RFC4684 in
> the light of the first observation.


From raszuk@cisco.com  Sat Jun 27 13:32:17 2009
Return-Path: <raszuk@cisco.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6FFB3A6CF4; Sat, 27 Jun 2009 13:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.019
X-Spam-Level: 
X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-2MMtLTGNAo; Sat, 27 Jun 2009 13:32:12 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CA55A3A6CC4; Sat, 27 Jun 2009 13:32:12 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,301,1243814400"; d="scan'208";a="333130801"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Jun 2009 20:32:32 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5RKWWnF031380;  Sat, 27 Jun 2009 13:32:32 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5RKWWgI014275; Sat, 27 Jun 2009 20:32:32 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Sat, 27 Jun 2009 13:32:32 -0700
Received: from [10.21.71.134] ([10.21.71.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Sat, 27 Jun 2009 13:32:31 -0700
Message-ID: <4A4681DD.8090207@cisco.com>
Date: Sat, 27 Jun 2009 13:32:29 -0700
From: Robert Raszuk <raszuk@cisco.com>
Organization: Cisco Systems
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "John G. Scudder" <jgs@juniper.net>
Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-rt-constrain-lite-00
References: <20090625183020.9B10F3A69E1@core3.amsl.com> <06AB6078-835E-437B-AB13-F64AD78E4C35@juniper.net> <4A463ADA.1030503@cisco.com> <9AE4DF10-F7F6-4976-A779-929D47478CB3@juniper.net>
In-Reply-To: <9AE4DF10-F7F6-4976-A779-929D47478CB3@juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Jun 2009 20:32:31.0734 (UTC) FILETIME=[65701960:01C9F766]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6146; t=1246134752; x=1246998752; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raszuk@cisco.com; z=From:=20Robert=20Raszuk=20<raszuk@cisco.com> |Subject:=20Re=3A=20[Idr]=20Fwd=3A=20New=20Version=20Notifi cation=20for=20draft-scudder-idr-rt-constrain-lite-00 |Sender:=20; bh=kwq34NzxScZrC284AY5Dd9V7Dy5IMlFoehgVQxFcl90=; b=EpWbxQTLVZma6AOGLwbpuIpZjopy4tbLakanHafQUlSzGRwuMrqsuba+vY FKdTsZFCFhc4EevMqABdoSMGpbFc2c0ZjX0KTbJ7R8DVq0yFtq5tvRml7MAS M/oPLUVsGu;
Authentication-Results: sj-dkim-4; header.From=raszuk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: idr List <idr@ietf.org>, L3VPN <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: raszuk@cisco.com
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2009 20:32:17 -0000

Hi John,

I am completely not convinced that what is proposed in RTC-lite draft is 
not already covered and can be implemented by supporting mandatory 
protocol extension contained in the main RFC4684 specification without 
violating it.

WFIW I can easily see the full RFC4684 implementation allowing to drop 
incoming filters (with exceptions or not) on inbound reducing it's 
further processing and storing by BGP. Such exceptions may include 
allowing to accept default filter in order not to be subject of delayed 
advertisement of VPN routes due to a required otherwise timeout mechanism.

My quote provided below seems to be proving my point of view.

Perhaps others co-authors of RFC4684 as well as implementors can comment 
  on it.

On the practical note I seriously doubt that any commercial 
implementation of L3VPN would choose to only support RTC-lite and not 
full RFC4684 in it's operating system.

Would you agree that this draft should be progressed only if we would be 
able to find an implementation that supports it and not full RFC4684 ?

And as soon as such implementation would gain full RFC4684 support we 
either find another one supporting only RTC-lite or move RTC-lite to 
historical ?

Cheers,
R.


> Robert, thanks for your comments.
> 
> Your main question is essentially what the contribution of 
> rt-constrain-lite is.  Fair enough.  There are two contributions, to my 
> way of thinking.  The first and more important is that (as I will 
> explain below) there are normative changes between rt-contrain-lite and 
> rt-constrain.  The two are interoperable, but not identical.  The second 
> is that for many deployment scenarios (specifically PE routers) full-on 
> rt-constrain is more than is needed.  The rt-constrain-lite document 
> would provide a single document that could be cited in procurements, 
> rather than either citing full rt-constrain (even though it provides 
> more than is required) or citing full rt-constrain with caveats (which 
> is a messy way of doing it).
> 
> As for the normative changes: you actually identify this yourself, in 
> your message.  As you point out, rt-constrain-lite specifically exempts 
> the PE from having to honor filtering for received rt-constrain routes.  
> This is an interoperable difference between the two.
> 
> As an aside, you've also inadvertently pointed out a bug in the 
> rt-constrain specification.  The first paragraph you quote:
> 
>>    "A BGP speaker MAY participate in the distribution of Route Target
>>    information without using the learned information for purposes of VPN
>>    NLRI output route filtering, although this is discouraged."
> 
> would not seem to be compatible with the second one you quote:
> 
>>    "A VPN NLRI route should be advertised to a peer that participates in
>>    the exchange of Route Target membership information if that peer has
>>    advertised either the default Route Target membership NLRI or a Route
>>    Target membership NLRI containing any of the targets contained in the
>>    extended communities attribute of the VPN route in question."
> 
> although I guess you can observe that the latter paragraph is a "should" 
> and not a "must".  (If you take this point of view you would also have 
> to agree that rt-constrain-lite does not "directly violate" RFC4684.)
> 
> Regarding your secondary question about the PE honoring, or not, 
> rt-constrain route filtering -- if the PE were required to do this, that 
> is the same as requiring it to do a full RFC4684 implementation, which 
> would defeat the point of a "lite" flavor.  I don't think it's 
> reasonable to say "just parse default but nothing else" since it's 
> perfectly permissible for the RR to never send a default, which would 
> leave the PE stuck forever.
> 
> However, this does lead me to consider that you could ask the PE to wait 
> until it has received any rt-constrain route at all from the RR before 
> advertising VPN routes.  This heuristic would seem to be almost the same 
> as waiting for the default route without having the same failure mode if 
> the default is never sent.
> 
> Regards,
> 
> --John
> 
> On Jun 27, 2009, at 11:29 AM, Robert Raszuk wrote:
>> Observation #1:
>>
>> Let's notice that original RFC4684 already well defines rt-constrain
>> lite in it's published text:
>>
>>    "A BGP speaker MAY participate in the distribution of Route Target
>>    information without using the learned information for purposes of VPN
>>    NLRI output route filtering, although this is discouraged."
>>
>> As RT-constrain lite draft does exactly the above paragraph it is at
>> least redundant.
>>
>> Observation #2:
>>
>> The original RFC4684 says:
>>
>>    "A VPN NLRI route should be advertised to a peer that participates in
>>    the exchange of Route Target membership information if that peer has
>>    advertised either the default Route Target membership NLRI or a Route
>>    Target membership NLRI containing any of the targets contained in the
>>    extended communities attribute of the VPN route in question."
>>
>> RT-C lite says:
>>
>>    "Specifically, the PE need only implement the ability to send Route
>>    Target Membership NLRI; it need not have the ability to receive,
>>    store and filter upon such information."
>>
>> That directly violates RFC4684 as quoted above. After exchanged the 4684
>> capabilities the PE should wait for the default rt filter or atomic one
>> before it starts any VPN route advertisement.
>>
>> The same for the RR side ... RR may expect after negotiating RFC4684
>> capability not to receive any routes from a peer until it has send
>> default rt NLRI or an atomic one. That may be used for peer
>> prioritization as an example.
>>
>> Conclusion of the observation #2 above leads me to believe that
>> reception and parsing of at least default rt-filter by RT-Constrain lite
>> is required.
>>
>> But I am more interested to find out what is missing today in RFC4684 in
>> the light of the first observation.
> 
> 


From jgs@juniper.net  Mon Jun 29 09:52:03 2009
Return-Path: <jgs@juniper.net>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937523A6BCF; Mon, 29 Jun 2009 09:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNOkbgcLV1dj; Mon, 29 Jun 2009 09:52:02 -0700 (PDT)
Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id C02453A6B51; Mon, 29 Jun 2009 09:52:00 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSkjxMSMZw6o0MRJtlUVtjB+GVXUPhwa6@postini.com; Mon, 29 Jun 2009 09:52:23 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 29 Jun 2009 09:21:30 -0700
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 09:21:30 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 09:21:30 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 09:21:29 -0700
Received: from [172.16.13.201] ([172.16.13.201])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n5TGLSL50382; Mon, 29 Jun 2009 09:21:28 -0700 (PDT)	(envelope-from jgs@juniper.net)
Message-ID: <3376C1C1-A02C-494B-85D5-B8F9C17026CE@juniper.net>
From: "John G. Scudder" <jgs@juniper.net>
To: "raszuk@cisco.com" <raszuk@cisco.com>
In-Reply-To: <4A4681DD.8090207@cisco.com>
Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-rt-constrain-lite-00
Date: Mon, 29 Jun 2009 12:21:28 -0400
References: <20090625183020.9B10F3A69E1@core3.amsl.com> <06AB6078-835E-437B-AB13-F64AD78E4C35@juniper.net> <4A463ADA.1030503@cisco.com> <9AE4DF10-F7F6-4976-A779-929D47478CB3@juniper.net> <4A4681DD.8090207@cisco.com>
X-Mailer: Apple Mail (2.935.3)
X-OriginalArrivalTime: 29 Jun 2009 16:21:29.0664 (UTC) FILETIME=[A8921C00:01C9F8D5]
Cc: idr List <idr@ietf.org>, L3VPN <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 16:52:03 -0000

Robert,

I agree that this is a supportable point:

On Jun 27, 2009, at 4:32 PM, Robert Raszuk wrote:
> WFIW I can easily see the full RFC4684 implementation allowing to drop
> incoming filters (with exceptions or not) on inbound

But it's at odds with your previous comment:

On Jun 27, 2009, at 11:29 AM, Robert Raszuk wrote:
> RT-C lite says:
>
>    "Specifically, the PE need only implement the ability to send Route
>    Target Membership NLRI; it need not have the ability to receive,
>    store and filter upon such information."
>
> That directly violates RFC4684 as quoted above.

Since the text you objected to pertains exactly to the dropping of  
incoming filters, I guess you have changed your mind on this point.   
That is fine with me.

On Jun 27, 2009, at 4:32 PM, Robert Raszuk wrote:
> Would you agree that this draft should be progressed only if we  
> would be
> able to find an implementation that supports it and not full RFC4684 ?

I generally don't think protocol specifications should be progressed  
without implementation, so sure.

> And as soon as such implementation would gain full RFC4684 support we
> either find another one supporting only RTC-lite or move RTC-lite to
> historical ?

Seems generally reasonable.

Thanks,

--John

From robert@raszuk.net  Mon Jun 29 10:08:28 2009
Return-Path: <robert@raszuk.net>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301ED3A6801; Mon, 29 Jun 2009 10:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJUQ1VlFr93n; Mon, 29 Jun 2009 10:08:27 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6B4773A67A6; Mon, 29 Jun 2009 10:08:27 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,310,1243814400"; d="scan'208";a="181355255"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 29 Jun 2009 17:08:48 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5TH8mnC006576;  Mon, 29 Jun 2009 10:08:48 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n5TH8m02009127; Mon, 29 Jun 2009 17:08:48 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 29 Jun 2009 10:08:47 -0700
Received: from [10.21.119.15] ([10.21.119.15]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 29 Jun 2009 10:08:47 -0700
Message-ID: <4A48F51B.9040600@raszuk.net>
Date: Mon, 29 Jun 2009 10:08:43 -0700
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "John G. Scudder" <jgs@juniper.net>
Subject: Re: [Idr] Fwd: New Version Notification for	draft-scudder-idr-rt-constrain-lite-00
References: <20090625183020.9B10F3A69E1@core3.amsl.com>	<06AB6078-835E-437B-AB13-F64AD78E4C35@juniper.net>	<4A463ADA.1030503@cisco.com>	<9AE4DF10-F7F6-4976-A779-929D47478CB3@juniper.net>	<4A4681DD.8090207@cisco.com> <3376C1C1-A02C-494B-85D5-B8F9C17026CE@juniper.net>
In-Reply-To: <3376C1C1-A02C-494B-85D5-B8F9C17026CE@juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Jun 2009 17:08:47.0563 (UTC) FILETIME=[441721B0:01C9F8DC]
Authentication-Results: sj-dkim-2; header.From=robert@raszuk.net; dkim=neutral
Cc: "raszuk@cisco.com" <raszuk@cisco.com>, idr List <idr@ietf.org>, L3VPN <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert@raszuk.net
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 17:08:28 -0000

Hi John,

> I agree that this is a supportable point:

Thank you.

But I don't think I have changed my mind. The difference is that an 
implementation may _allow_ to configure incoming filter, but for example 
always permit to get the default filter in.

If the implementation does not have an ability to even receive a filter 
as RTC-lite allows (regardless if the sender is aware of it or not) it 
in my view violates the RFC4684 or for that matter creates an 
interesting precedence for BGP4 itself.

Thx,
R.


> On Jun 27, 2009, at 4:32 PM, Robert Raszuk wrote:
>> WFIW I can easily see the full RFC4684 implementation allowing to drop
>> incoming filters (with exceptions or not) on inbound
> 
> But it's at odds with your previous comment:
> 
> On Jun 27, 2009, at 11:29 AM, Robert Raszuk wrote:
>> RT-C lite says:
>>
>>    "Specifically, the PE need only implement the ability to send Route
>>    Target Membership NLRI; it need not have the ability to receive,
>>    store and filter upon such information."
>>
>> That directly violates RFC4684 as quoted above.
> 
> Since the text you objected to pertains exactly to the dropping of 
> incoming filters, I guess you have changed your mind on this point.  
> That is fine with me.