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

[Rahul Aggarwal <rahul at juniper.net>]

Hi Eric,

First, to me the goal of draft-morin is to provide a set of
mandatory and optional, options (from the set of options in
draft-ietf-l3vpn-2547bis-mcast) that would allow SPs to deploy
inter-operable implementations using technology/options that the *SPs
want*.

This is a very important excercise for the L3VPN WG to progress on the
MVPN subject. draft-morin IMO is an excellent start towards this
excercise. It should be adopted as a WG document and can evolve to address
*valid concerns*.

And valid concerns do not include philosophical arguments.
Unfortunately several of your concerns were philosphical in nature and do
not help with constructive progress.

More below:

On Fri, 14 Dec 2007, Eric Rosen wrote:

>
> I think Yakov's  reply makes it pretty clear that  adoption of this document
> as a WG document at the current time is premature.
>

On the contrary it shows that draft-morin is quite ready to become a WG
document ! I think his reply separates your valid concerns from the ones that are not
valid. And proves that the set of valid concerns is a) addressable and b)
can be addressed after WG adoption.

Let me repeat here what is the set of valid concerns that you seem to
have:

"Of the issues raised by you in the above the only legitimate ones
seems to be (a) more analysis on different flavor of multicast LSPs,
(b) whether there is a need for BGP-based auto-discovery with
PIM-based shared trees, and (c) whether the UDP-based S-PMSIs
signaling should be best considered as an optional part of the  PIM
C-multicast  routing control  plane.  All of these issues can be
addressed after the document gets adopted as a WG draft."


> I was  prepared for someone to  say that the  issues I raised can  be worked
> after the  document is accepted.  However,  we see from  Yakov's answer that
> he,  at least,  wants to  suppress discussion  of all  the  remaining issues
> (after all, they're  all FUD ;-)).

Yakov in his email asked you several specific questions. I don't
call that "supress discussion". If you have reasonable answers to have a
constructive discussion on those subjects, please speak up. Else it just
demonstrates that several of your points called out as FUD were indeed FUD
(or to put more politely philosophical) !

> For the kind of document that draft-morin seems to be, I think it is the job
> of the authors to investigate all  the issues, not to say "we won't consider
> any issue until some  else proves beyond a shadow of a  doubt that there's a
> real problem".

The discussion of the issues has to be grounded in *rational technical
arguments* put forth by SPs to guide the set of mandatory/optional
options.

>
> > Moreover since PIM is based on unreliable message exchange, "join latency"
> > with PIM could be in 10s of seconds.
>
> The worst  case join latency in  either case could be  arbitrarily long, but
> I'm sure everyone knows ((well, almost everyone ;-)) that's it's the average
> join latency that is important.

Try telling that to a SP who has an important financial feed that needs
*predictable* join latency.

>  Since packets don't usually get lost in the
> backbone, that's  not much of  an issue.   I don't think  it takes a  lot of
> fancy analysis  to determine  that it's  faster to send  a data  packet from
> point A  to point B then  to send it from  point A to  an intermediate point
> where it  is processed and then afterwards  sent along to point  C.  One can
> argue  that the  latency increase  isn't significant,  or that  it's  a good
> tradeoff  against something  else,  but it's  just  silly to  deny that  the
> latency increase exists!
>

There doesn't seem to be any technical argument on why the average join
latency will increase. The average has to take into account the worst case
latency, and the latency of first join and subsequent joins (which
is lesser than the latency of the first join).

> > supporting BSR without  MI-PMSI has been explained in  the presentation at
> > the  L3VPN  WG  meeting  (with  you  as one  of  the  co-authors  on  that
> > presentation).
>
> Many of  the presentations  we've given over  the years  presented solutions
> which  turned out  to  be  unsatisfactory.  Certainly  the  support or  lack
> thereof  for  BSR  is  something  that a  "considerations"  document  should
> examine.
>

To me this falls in the category of which multicast LSP flavor to choose.
And this can be done after the document becomes a WG document.

rahul