Re: Comments on draft-morin-l3vpn-mvpn-considerations-01.txt

[Thomas Morin <thomas.morin at orange-ftgroup.com>]

Hi Eric,

Following my reply on yesterday, I'll try to go in detail through your
comments and see what are the points that I think could be better
covered in draft-mvpn-considerations.

* First, some of your comments shows that there is much confusion
related to the theme of "what new is put into BGP vs. what PIM does /
what BGP does new that PIM was/wasn't doing". I admit I would have
expected a co-author of the solution drafts to actually clear up that
kind of confusion, but let's focus on what can be done in
mvpn-considerations to improve everybody's understanding : I propose we
add a section detailing what is done by PIM in the Full PIM peering
approach (both the case where explicit tracking is done by upstream PEs,
and the case where Join suppression is made) and what is done by BGP in
the BGP approach, on the PE and on the RRs. We won't try to compare
things quantitatively, but I think spelling out the details can help
shed light on the general debate of the relative merits of PIM and BGP
to carry C-multicast routing information.  (see below, in reply to your
"transactional nature of PIM", a rough cut of the things we can explain
to help evaluate how the multicast routing processing is spread onto the
different entities).

* On the general theme of BGP routing activity due to C-multicast route
and route reflectors : you are right in saying the document could talk
more about it. I think we can incorporate content explaining that moving
some processing from PIM to BGP will require adjusting the route
reflectors infrastructure by whether by increasing route reflector
processing resources and taking care of not badly impacting unicast
routes (e.g. distinct BGP sessions), or more likely by introducing
distinct route reflectors for mVPN.  We can also talk about the tools to
control the impact of end user activity to the amount of processing done
by the control plane (leave dampening, join dampening, impact of join
dampening on join latency).

* About join latency : for sure minimizing join latency can be important
for some specific applications and I agree we should talk about it. As
said earlier, I think the draft should use fact-based arguments and here
the facts that can be talked about is that the C-multicast routing join
latency relative performance in the BGP and PIM cases, will depend on
BGP performance of the PE and RR(s) relatively compared to PE PIM
processing performance on the PEs, and also on the network latency that
will be added at each processing "hop" (one in the case of PIM, one, two
or more in the case of BGP). All these performance aspects being to
consider in both the low scale space and the higher scale space, since
both PIM and BGP approaches can be expected to be differently impacted
by higher scale scenarios, for join-latency. Last, I think we should
state that absolute performance figure in the end depend on
implementations.

* On outsourcing the RP : the draft currently basically says that the
feature has applicability and should be implemented, but that in no way
it should be required to enable it (and we do mention drawbacks similar
to those you insisted upon).  This section needs some improvement : as
suggested by Yiqun Cai during the meeting, we don't exactly distinguish
between the two role associated with the "RP" label in such a context --
PIM register decapsulation and RP routing function vs.
Anycast-RP-related functions.  We plan to update this section in this
sense, then if you have precise comments on stuff that we
should/shouldn't talk about, please make them (see below inlined, I
didn't really understood what you disagree with in the current text).

* Remark about using BGP autodiscovery to detect misconfigurations, and
the fact it may not be helpful in transitions scenarios : I agree, and I
think we can definitely mention this in an updated version.

* On Extranet : the current text we propose is only saying that the BGP
approach for C-multicast routing reuses the RT import/export semantics
to define Extranet, to illustrate the benefits brought by using the same
protocol/semantics for unicast and multicast. You insist on reminding us
that an early implementation of the Full PIM peering approach do also
support this : if it also is a good illustration of reusing existing RT
import/export semantics, then we should also mention it for sure. The
fact is that Extranet for the Full PIM peering approach is not (yet?)
described in any spec (AFAIK).  So what I propose is that you first
point us toward a description of such a feature and (a) tell us if that
would be relevant to include in that section mentioning consistency
brought by the reuse of RT import/export semantics, and (b) we provide a
section trying to compare the relative merits of the different
approaches to provide an Extranet feature.

* On encapsulation techniques : as you suggest, we can highlight the
benefits of using MP2MP MPLS trees for facilitating the implementation
of some of the different proposed ways of supporting C-bidir-PIM. We can
certainly also explain how it would facilitate the support of the Full
PIM peering approach, but (see below inlined) I'm not sure I do yet
understand well what you suggest.  Another point (that you didn't
mention) is the expected scalability benefits of using MP2MP trees with
one MP2MP tree per VPN, we can also mention this.

* You highlight the fact that the scalability benefits brought by
aggregation of the traffic multiple VPNs in a PSMI-tunnel, requires the
support of upstream assigned labels : this is something that I'm not
against mentioning in the document, but I'm unsure how this will help
see which control plane approach is better than another one, since such
aggregation is supported whatever control plane approach you take...
(any idea ?)

* You make some comments related to S-PSMI scalability in inter-AS in
the segmented inter-AS model : there indeed were recent discussions
about among authors of draft-ietf-l3vpn-2547bis-mcast-bgp, which you and
me happen to be in, on possible improvements needed to make the
segmented approach better in this respect.  We will need to update
mvpn-considerations accordingly (this was in fact planned before your
comments, as mentioned in the slides presented in Vancouver). 

* BSR/auto-rp support : we can definitely tackle this point. It is true
that current specs for the BGP approach doesn't explain in detail how to
cover this.

Please tell us if you feel that the above proposed updates are relevant.
It seems to me that it integrates a fair amount of useful comments that
you made, and that can indeed make the document at the same time more
balanced and precise.


See inlined below, a few reactions I have on your comments.


Eric Rosen :
>
> - As BGP  is generally  used, BGP churn  is a  function of real  or apparent
>   topology changes.  BGP churn is NOT generally caused by enduser events.
> 
>   This changes when  BGP is used to distribute  multicast routes.  BGP churn
>   can now  be initiated by PIM  Joins, and a PIM  Join may be  the result of
>   some enduser clicking  a button on his PC (e.g.,  "receive video").  it is
>   not clear that there is any limit on the rate at which such enduser events
>   can occur.  We do not appear to  have adequate data from which we can draw
>   conclusions as to the impact of enduser actions on BGP churn.

Yes, as said above, I propose to add content in the draft to talk about
new routing to be taken care of by BGP. It also has to be said, to be
fair, that (a) BGP updates can be caused by routing events in customer
sites and that BGP has tools to cope with such things (such as
dampening) which can be reused for C-multicast routes and that (b) the
"input" to this processing problem is the same whatever control plane
approach is chosen.


[...]
> - Churn  vs. latency:  To  control the  BGP  churn, we  have discussed  such
>   features as  Join Dampening.   However, that can't  be expected to  have a
>   salutary effect on the latency!
> 
>   There really should  be some recognition in the draft  that the effects on
>   latency and churn are as yet poorly understood.

Well... do you deliberately chose to omit that what is first suggested
by the mvpn bgp solution draft (which you co-author!) is leave-dampening
and has no effect on join latency ? do you really honestly "poorly
understand" the effects of join-dampening on churn and latency ?

You are in fact spreading FUD through strawman here :
- "strawman" because nobody is saying "join dampening" should be
extensively be used, and "join dampening" is in no way a key argument in
the rest of the debate (_leave_ dampening is an important tool) 
- "FUD" because you use vague terms ("poorly understood") to suggest
that something is proposed without having well been thought out ; "join
dampening" is in fact not in this case. It has actually well identified
effects: good effect on "churn" (higher dampening => lower churn) and
impacts latency ("higher dampening" => "higher join latency for the
first receiver"). The solution drafts already formulate this limitation
of join dampening, and I don't think mvpn-consideration has to repeat
this.

So as formulated in the head of this mail: the key thing is "how control
plane copes with join/leave events ? what impact on latency ?", and we
can definitely talk about this.  But we will focus on constructive
points like looking at what tools are proposed for the different
approaches to cope/reduce this load. We can even go further and suggest
that, even though the Full PIM peering approach doesn't
document/proposes such features, join/leave dampening could also be
supported with slight changes to PIM implementations. 



> - Transactional nature of PIM
> 
>   At first glance,  it may seem that having  PIM distribute multicast routes
>   to BGP is no different than  having OSPF distribute unicast routes to BGP,
>   i.e., that it is really  nothing new.  However, this isn't quite accurate.

(let me point your use of a "strawman" argument here again : when did
anyone suggest it was the same ? doesn the mvpn-considerations draft
state anything like that ?)


> The issue  is that PIM isn't really  a "routing protocol" in  the sense of
>   choosing  routes  based   on  topology.   It  is  a   protocol  that  uses
>   router-to-router  transactions  to construct  paths  and  assign flows  to
>   paths. In  some cases, especially when  Sparse Mode flows  are involved, a
>   number of  transactions involving  multiple nodes may  need to  take place
>   before the multicast "routing" stabilizes.  Each one of these transactions
>   must  pass through  the RR,  placing more  load on  the RR  and increasing
>   latency.
>
>   In  some  cases, where  PIM-SM  has  data-driven  state changes,  we  have
>   attempted  to avoid  putting the  data-driven state  changes into  BGP, by
>   having BGP send extra  messages, including timer-driven messages.  While I
>   tend to think that this is the right tradeoff, it does modify the dynamics
>   of path construction,  and we don't have any hard data  to tell us whether
>   we've made the right tradeoff,  or whether the "right tradeoff" depends on
>   just how the applications are using multicast.


You are formulating things in a "PIM is transactional / BGP is not", but
I think that this formulation has two drawbacks:

- talking about the "transactional nature" of PIM, and "router to router
transactions" is in fact unprecise/bogus:
  * first, because on a LAN, PIM message are not send from "router to
router", but rather received AND processed by all PIM routers on the LAN
(they are sent to a multicast group address) -- this is true for Hellos,
Join, Leave, and assert messages -- in many case the processing made
will then be different depending on if the router is the upstream PE or
not for the said Join.
  * second, "translation" is a surprising term in fact : PIM messages
are not acknowledged in any way; they can be lost or unprocessed,
without the router at the origin of a message being aware ; that is, one
of the entity taking part into the "transaction" could be unaware that
the "transaction" didn't happen -- weird for a "transaction", right ?
(BGP being TCP-based, depending on what you mean by "transaction", you
could very much argue than BGP is in fact more "transactional"...)

- this formulation is really hiding one very important thing in how PIM
behaves on a LAN, to resolve the one question important for an upstream
router "is there still somebody needing such (C-s,C-g) across the
mvpn ?"

  * by default, PIM uses the "join suppression/prune override"mechanism,
    on a LAN : this mode help scaling PIM by reducing messaging, by two
    means:
      => when a router sends a Join for a said (s,g), other routers will
         omit sending theirs for some time, sparing each time a PIM Join
      => on reception of a Prune, the upstream router relies on other
         routers on the LAN to know if there are some PE left that need
         the steam 
     The downside of the above is that a PE router has to process all
   Joins sent on the LAN to know if it has to reset a timer or not for 
   Join suppression, and to all Prunes sent on the LAN to know whether
   or not it shall override the Prune.   This really not a "router to
   router" conversation.

[  * optionally, on a LAN, PIM can desactivate these mechanism, but only
  if all routers on a LAN are able to do so (detected through a Hello
  option), and obviously the benefits are lost : more messages will be
  exchanged, and more state has to be maintained (explicit tracking) by
  the upstream PE  // this approach is not pushed by anybody AFAIK  ]

- now, let's look at what BGP does (Eric, I know you know that
already!):

  * it finds a right trade-off between the two extremes possible with
PIM (between "everybody participates to see if there is any downstream
PE left" and "upstream PE does all the work by explicitly tracking who
are the downstream PEs") : the route reflectors are introduced, the set
of route reflectors carrying C-multicast routes for a said VPN virtually
collaborate to maintain the "count", the upstream PE is 100% relieved
from this processing/state effort, which burden is put on the route
reflector(s).  This means you have the tooling to adapt your
architecture to the work load : you can choose to use zero route
reflector (to minimize latency e.g. if you happen to have a specific use
case), or one route reflector, or a hierarchy of route reflectors... you
can choose to you partition the different VPNs to have them by treated
by specific route reflectors... you have _already_ existing tools to
handle the load in high scale scenarios.  None of this you can do with
PIM LAN procedures !

  * by nature (contrarily to PIM exchanges on a LAN by default) the
semantics of C-multicast route processing with the proposed BGP
extension are "router to router" : C-multicast routes are addressed to
one specific upstream router and BGP has the tooling required to respect
this semantic with RT-contraint (reused from unicast).



> - Strange uses of PIM
> 
>   Talk  to  anyone  with a  lot  of  experience  in  PIM deployment  in  the
>   enterprise, and you'll hear lots of  strange stories about how PIM is used
>   in some enterprises.   Although PIM is optimized for  "many receivers, few
>   sources", it isn't always used  that way.  I've also heard anecdotes about
>   applications that make assumptions about the dynamic nature of PIM and may
>   break if  anything changes.   As usual,  hard data is  hard to  find.  But
>   there's always a risk that when you change the infrastructure underneath a
>   crufty old application you will break the application.  There are people I
>   respect, with  much more experience  in multicast deployment than  I have,
>   who think it's  just foolish to do anything that changes  the way in which
>   the infrastructure behaves for sparse mode.  While I am not convinced that
>   they are  right, I think that  this does have  to be recognized as  a risk
>   element.

Interesting. You will certainly agree that there is not much we can say
based on so scarce information. Given the above, I would myself even
fear that the specifics of the use of PIM LAN procedures in the context
of draft-ietf-l3vpn-2547bis-mcast would have any side effect...

-> Why wasn't this suggested for incorporation in what is now RFC4834
(mvpn requirements) ?
-> Can you provide more data points and details on what are these
strange use of PIM ? (Or can (the) provider(s) having such use case give
more details ?)  It would be useful to let "the community" and
co-authors of mvpn-considerations evaluate what the limitations of the
BGP C-multicast routing proposal would be. 


> Now let's look at some of the topics covered in the draft.
> 
> 1. From section 3.1, "the operational burden of setting up multicast on a PE
>    or for a VR/VRF SHOULD be as low as possible".
> 
>    I certainly  agree with  this!  However, I  don't think it  combines well
>    with the  later recommendation to support outsourced  RPs.  Obviously the
>    use of outsourced RPs increases the operational burden for the provider.
> 
>    I  note that  there doesn't  seem to  be any  requirement for  making the
>    operational burden  of MVPN on the  SP's customer be as  low as possible,
>    though such a requirement is  prominent in another SP requirements draft,
>    viz.,  draft-mnapierala-mvpn-part-reqt-00.txt.  Such a  requirement would
>    see to  militate against  the use  of the "outsourced  RP", at  least for
>    MVPN customers who already use  multicast.  (Which I imagine would be the
>    vast majority of them.)


I already mentioned this in the head of my answer: the draft precisely
says that an implementation should not require activating an RP function
on the PE.   

        "...support for a co-located RP model within an implementation
        should not restrict deployments to using a co-located RP
        model,..."
        
What do you exactly disagree with ??


> 2. Auto-discovery
> 
>    "BGP-based  auto-discovery is the  preferred solution  for auto-discovery
>    ...  while  PIM/shared-tree  based  auto-discovery should  be  optionally
>    considered for migration purposes only".
> 
>    There isn't  really a  dichotomy here.  The  facts are that  if PIM-based
>    shared  trees  are  used,  BGP-based auto-discovery  doesn't  really  add
>    anything,  but in  any  other circumstance,  BGP-based auto-discovery  is
>    absolutely necessary.
> 
>    But  if the recommendation  here is  to provide  BGP-based auto-discovery
>    even in the one case where  it isn't strictly needed, I certainly support
>    that recommendation.  This  is, in fact, already true  of the majority of
>    existing MVPN  deployments.  (Though  I have been  told that there  is at
>    lest one vendor which does not support it in existing deployments.)
>
>   There is a suggestion in the  draft that if PIM-based shared trees are in
> use, BGP auto-discovery can  help detect misconfigurations.  I'm not sure
>    about that, as I can imagine  transition scenarios in which more than one
>    shared tree is in use at some time.

I see that we agree here. We can add consideration about limitations of
misconfiguration detection.



> 4. S-PMSI Signaling
> 
>    The BGP-based S-PMSI  signaling mechanism does have a  risk factor that I
>    have mentioned above, but that is not considered in the draft
> 
>    In current practice,  BGP changes are caused by  topology changes, not by
>    end  user  activity. However,   it  is  enduser  activity  that  causes
>    invocation of the S-PMSI signaling  mechanism.

( Come on Eric, why do you chose a formulation that suggest a dynamic
activity triggered by end-users, while we are talking about an optional
optimisation that can be fully controlled/enabled/disabled by the
provider without impacting the service ?  )


> [...]The S-PMSI signaling is  also something that is
>    best done through a low latency  mechanism, and we do not at present have
>    the data to determine whether BGP will significantly increase the latency
>    when compared with the UDP-based proposal.

I disagree : the time between "the condition for triggering a Data-MDT"
triggering Data-MDT being true" and "traffic being put on the Data-MDT"
is something that currently already takes a fair among of time with some
implementations (many 10s of seconds).  And this only temporarily
reduces the bandwidth optimisation gain, and -again- with no impact on
the service provided to the user.

That said, comparing the signaling latency of S-PMSI with BGP and the
UDP protocol, is a bit like comparing apples and oranges (yes, Pink
Floyd's fans in the crowd, it is normal if you start hearing a little
singing voice) because BGP signaling ensures the delivery of this
information. The actual signaling minimal latency in both cases will
then depend partly on implementation, and on the number of processing
"hops" and on the network-related latency.

> In theory,  the use of BGP  S-PMSI signaling has a  number of advantages,
>    but I  don't think  I would  recommend against the  use of  the UDP-based
>    procedure unless and until I had some data about these pragmatic issues.

( You know that we do have recent facts about pragmatic issues related
to Data-MDT signaling with the UDP scheme, that would not have arised
with the BGP signaling approach. )


> "The  UDP-based protocol  is  restricted  to use  within  MVPNs using  an
>    MI-PMSI".
> 
>    This fact seems to me to be  neither here nor there.  It is true that the
>    UDP-based protocol is unlikely to be useful unless PIM is the C-multicast
>    routing control protocol, in which case  you have an MI-PMSI.   [...]

Hmmm... I don't read any such thing in draft-ietf-l3vpn-2547bis-mcast.

As I see it, there are two proposed control plane approaches for S-PMSI
signaling. We are trying to focus the solution draft on only providing
one (which will help produce a "standard"), and we happen to see that
there is one of the two that require a specific type of data plane. 


> The UDP-based S-PMSIs signaling is best considered as an optional part of
>    the  PIM C-multicast  routing control  plane, rather  than as  a separate
>    protocol with its own independent set of pros and cons.

Hmmm... can you explain why the BGP signaling for S-PMSI would not apply
if PIM is used for C-multicast routing ? it seems to me that it is
totally applicable.

Said differently: why BGP-based autodiscovery of I-PMSI would be a good
fit for the Full PIM peering approach, and BGP-based S-PMSI signaling
would not?


> "the  use  of  the  UDP-based  protocol  does  not  preserve  AS  routing
>     independence  when  used in  an  inter-AS  option  B context  (i.e.  the
>     decision by  a PE in an  AS to use an  S-PMSI for a  given customer flow
>     will impact routing state in other ASes)
> 
>    I  have no  idea what  this means,  so I  hope one  of the  authors will
>    explain.   (I also  don't  know what  is  meant by  the  claim that  the
>    BGP-based S-PMSI signaling  mechanism doesn't have whatever disadvantage
>    this is.)

The thing is that the BGP segmented model provide means so that an AS
can trigger an S-PMSI without forcing neighbor ASes to create more state
in their backbone.  The drawback of not allowing this is I think fairly
clear : bandwidth optimization decisions made by one provider won't
impact the amount of state another provider will have to cope with.

But, you knew that already, so it really seems like a matter of wording.
We will try to improve this.


> 5. Off-loading processing onto route reflector
> 
>    The claim is made that, when using BGP to carry C-multicast routes, "some
>    of  the processing burden  associated with  client multicast  routing [is
>    offloaded] onto BGP route reflectors"
> 
>    I  would  like the  authors  to  specify  precisely what  this  offloaded
>    processing burden is.  Some consideration of its effect on existing L3VPN
>    route reflector systems would also be worthwhile.
> 
>    As the  text is now, it is  very difficult to understand  or evaluate the
>    claim.

See above (answer to your "Transactional nature of PIM" item).


> 6. MI-PMSI issues
> 
>    "Moreover, mechanisms one and two are restricted to use within
> MVPNs using an MI-PMSI, thereby necessitating [...] (b) The use of one
> P-multicast tree per PE per VPN, even for PEs that do not have sources
> in their directly attached sites for that VPN."
> 
>    First,  claim b  is  not true,  as  explained in  draft-rosen-l3vpn-mvpn-
>    profiles-00.txt, section 3.3.

Eric, you know very well that mvpn-considerations-01  (from which you
extract these statement) was submitted in early October, but
draft-rosen-l3vpn-mvpn-profiles-00, which is the first proposal of the
use of PIM across a set of M2PMP tunnels, was submitted one month later,
in early November...

So:
- we can make all the effort to be as balanced as possible, but we can't
read into the future !  ;)
- are we expected to cover all mvpn architecture proposal that are not
yet WG documents ?
- even, after reading -profiles section 3.3, it doesn't really appear to
me that this a use of the Full or Lightweight PIM peering approaches,
but rather a fifth proposal to adapt PIM to a specific dynamic mesh of
MP2MP trees 



> Second, the fact that a control  protocol requires that it be possible to
>    instantiate a P-tunnel as a shared tree  of some sort does not seem to be
>    to be  a "restriction" or disadvantage.

I would disagree : if one control plane option was restricting the
choice of the possible underlying encapsulation technique, that would
certainly be a restriction and thus a disadvantage.

But...rereading our text, I see that we don't say the right thing.
The full and lightweight PIM peering approaches do _not_ require a
provider protocol supporting shared trees, but _do_ require setting up
an MI-PMSI (and a set of trees rooted at each PE would thus obviously
allow to support PIM for C-multicast routing).  We will definitely
correct this text.


> There are however some other things  that do seem to require the presence
>    of an MI-PMSI:   autoRP and BSR.  Since many  SP customers use autoRP/BSR
>    to discover  RPs, and since  it is not  clear how to provide  support for
>    these without an  MI-PMSI, I am not convinced that one can do without an
>    MI-PMSI even if BGP is used for distributing C-multicast routes.

On the other hand, when talking about higher scales, you have to look a
few years down the road. And these days, two things are preferred:
anycast-RP for ASM support, and SSM.  These don't require any
autoRP/BSR.  So, for me, we should ask ourselves : shall deployments or
services/applications to come (SSM) incur the penalty of past choices
(ASM related complexity) ?


> 7. BGP doesn't eliminate PIM anyway
>    
>    "using BGP for customer routing distribution within multicast VPNs avoids
>    the introduction of an  additional protocol that would require additional
>    OAM processes and tools."
> 
>    It's not as if  PIM is eliminated by BGP.  As long as  PIM is used on the
>    PE/CE links, the SP is still operating a PIM environment.  

Well, it is true (and I'll propose we update this statement), but it is
also true that much of the complex things to operate with PIM relate to
PIM LAN procedures that are not necessarily used on PE-CE links (but
that are used when you use the Full PIM peering approach). Operation
people would need more expertise on PIM, to work with the Full PIM
peering approach, than when they only have to work on PIM on point to
point PE-CE links.

> [...] 
> In  any  event, I'm  not  sure  I understand  how  adding  a  lot of  new
>    functionality  to BGP  (multicast  path  creation) is  going  to be  done
>    without the need for additional OAM processes and tools.

You have existing tools to observe/handle MP-BGP routes, extending them
to understand/troubleshoot BGP mVPN routing looks easier to me than
making tools to understand/troubleshoot multicast routing event with the
Full PIM peering approach.


> 9. Encapsulation techniques
> 
>     I notice that  there is one particular data plane  technique that is not
>     addressed  by the  document, viz.,  the use  of ingress  replication and
>     transmission through  unicast tunnels.  It would be  interesting to know
>     whether SPs  have interest in this  technology; if not, maybe  it can be
>     removed from the  drafts.  (I think it adds  complexity and frankly, I'm
>     not sure it's fully and properly specified.)

( As I said earlier the goal is to identify what can be MANDATORY
options to implement. Removing one option wouldn't help in this
respect... )


> I think section 3.4 can be taken as a requirement for both a "BGP + GRE"
>     profile  and a  "PIM +  MPLS" profile,  since it  seems to  advocate for
>     independence between the the control  plane and the data plane.  But I'm
>     not sure if that is what is intended, and would like clarification.

I don't really see where your interpretation comes from. Please quote
specific text.   In my views, we aim in fact at quit the opposite : we
want to privileges an choice of control plane independent of the data
plane, to not be in a "profile" situation where control plane and data
plane engineering choices are coupled. 


> 10. Upstream-Assigned Labels, MI-PMSI, and Scalability
>    
>     The  WG drafts frequently  discuss aggregation,  and the  possibility of
>     aggregation is frequently touted as a major scalability advantage.
> 
>     What isn't always clear is  that all forms of S-PMSI aggregation require
>     a  major   new  MPLS  feature,   upstream-assigned  labels.   Supporting
>     upstream-assigned labels requires significant  changes to the data plane
>     processing  of  many  different  platforms,  and is  not  likely  to  be
>     available for some period of time.
> 
>     So realistically, for  the foreseeable future, the use  of an MI-PMSI is
>     going  to remain  the  only  method of  aggregation.   Unless a  service
>     provider does not care if their  P-routers have to maintain an amount of
>     multicast state  which is proportional to  the sum of the  states of all
>     their customers, the service provider should be requiring support for an
>     MI-PMSI. 

There is much confusion in the above statement, between aggregation of
traffic from different VPNs into a PMSI tunnel, and aggregation of
distinct (c-s,c-g) flows of a VPN into a same PSMI tunnel:
- aggregation of traffic from different VPNs into a PMSI tunnel does
require upstream assigned labels
- aggregation of distinct (c-s,c-g) flows of a VPN into a same PSMI
tunnel does _not_ require upstream assigned labels

So you can aggregate traffic of distinct (c-s,c-g) flows of a same VPN
into a same PSMI tunnel, but you _don't_ need it to be an MI-PMSI
tunnel. You can also do this with I-PMSIs, and you can do this with an
S-PMSI tunnel too.    Also, the limitation of requiring
upstream-assigned labels to aggregate traffic from distinct VPNs is not
solved by the use of MI-PMSI, this limitation is common to all PMSI
flavors.

( Really, I don't understand what you are trying to suggest... merely
creating confusion ? )


> As  a further  note,  it should  be  pointed out  that inter-AS  segment
>     S-PMSIs are on a per-PE basis, not a per-AS basis.  Therefore without the
>     aggregation that  can be obtained  from upstream-assigned labels,  it is
>     not clear that segmented inter-AS  S-PMSIs are scalable at all.  This is
>     an issue which should be mentioned.

As said above, we plan to update mvpn-considerations to take into
account recent discussions/proposals about S-PMSI and inter-AS.  

But you make a rather interesting statement : "it is not clear that
segmented inter-AS S-PMSIs are scalable at all".  In fact the segmented
model merits are to introduce means to better scale all PMSI-related
state.  If the answer to the question was "no, segmented inter-AS
S-PMSIs are not scalable at all", then S-PMSI would not be scalable in
the non-segmented model either (where S-PMSI is by design per-PE!).

>    I think the draft should have a clear recommendation that in
>    the absence of upstream-assigned MPLS labels, MI-PMSIs should be
>    used.

???
That would be bogus :
* there is an applicability for scenarios where only I-PMSI are used
(where only trees toward PE having sources are instantiated)
* S-PMSI obviously have applicability and can be used

(Again, I apart from generating confusion, I really don't get your
point)



> 11. Outsourced RPs
> 
>     I  would like  to see  the  draft offer  much stronger  support for  its
>     recommendation to  implement outsourced RPs,  or else to  eliminate that
>     recommendation. 

Your already stated this in your item "1".
Maybe you wrote too many comments ?  ;-)


[...]
> I presume  that the extra  operational work for  SP and customer  is not
>     going to be justified by the  fact that it simplifies things for some of
>     the SP's vendors.

Oh....?!??
You definitely wrote too many comments...
Despite all the respect I have for you, this is totally bogus.
- First, you imply that the four operators co-authors of mvpn-considerations 
are adding content in mvpn-considerations to simplify the work of specific 
vendor(s). You must be living in a funky world full of conspiracy theories.
- Second, you have missed one important thing : the draft actually state
that implementing only the "outsourced RP" model is not acceptable. I
don't how this is supposed to "simplify things for some [..] vendor(s)",
and doesn't really fit your conspiracy theory plot.


> 12. The draft's conclusion
> 
>    "Consequently, at the present time and until there is experience with
>    all of the proposed mechanisms it is not clear which of the above
>    mechanisms should be recommended as the preferred solution to
>    implementers.  However, it would appear prudent for implementations
>    to consider supporting both the fourth (BGP-based) and first (full
>    per-MPVN PIM peering) mechanisms.  Further experience on both
>    implementation is likely to be required before some best practice can
>    be defined."
> 
>    I certainly agree with this  conclusion.  Perhaps it should be given more
>    prominence. 

It is nice to see you agree. 
A few things though :
- this is not the only conclusion of the draft (this talks about about
C-multicast routing)
- this draft is a work in progress: "final" conclusions will be the one
in whatever final version is produced, taking into account feedback,
comments, and experience gained on all solutions

-Thomas