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

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

Hi Eric,

Eric Rosen :
>
> Eric> I would  like to  see the  draft offer much  stronger support  for its
> Eric> recommendation to implement outsourced  RPs, or else to eliminate that
> Eric> recommendation.
> 
> This is addressed at the text from section 4 of the draft:
> 
>         "It is therefore the recommendation of the authors
>         that implementations should support a co-located RP model"
> 
> Thus it seems  to me that the draft recommends that  the co-located RP model
> be implemented, and I think I am within my rights to oppose the inclusion of
> that recommendation.

For sure and nobody contested this right.

I'm interested in understanding why you have such a strong feeling about
a statement that only recommends a relatively minor optional feature,
that actually happens to be implemented by numerous vendors in multicast
VRFs, including the one you work for.

The mVPN requirements (RFC4834) actually talk in terms of "MAY" about
this feature. Is it the difference between "MAY" and "should", that
makes you so strongly react ?


> Thomas> your  underlying suggestion  that co-authors  of mvpn-considerations
> Thomas> state  that "the  outsourced-RP  feature should  be implemented"  to
> Thomas> simplify things for some particular vendor(s)
> 
> I apologize if my words led you  to make that inference, but that was not my
> intended  implication.   I  do  think  that  the  outsourced-RP  feature  is
> primarily a  simplification for the  vendor, and really just  a complication
> for the  SP and its customers.

To fully clarify what caused this misunderstanding, can you explain how
implementing this optional feature is "primarily a simplification for
the vendor" ?

> However, my assumption is  that the authors have  an  honest
> disagreement  with  me, not  that  they  have any  ulterior
> motives.

Nice to see you clarify this point.

> Thomas> operators have just a sincere  interest in trying to identify a best
> Thomas> candidate for becoming a standard (vs. a set of "profiles")
> 
> At no time did  I question the sincerity of the authors,  nor have I accused
> anyone  of attempting to  spread FUD,  of telling  lies, or  having ulterior
> motives.  I hope you will agree that ad hominem attacks of that sort have no
> place on this ML.

Ad hominem attacks indeed are not appropriate. 

You will hopefully agree too, that critics on the statements made (and
not on the people who make them) or the form of reasoning used (and not
on the people who use them), certainly do have a place here. 

You can also agree that it is quite natural to wonder about the
motivations when trying to better understand the issue raised.

-Thomas