Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3

[Robert Raszuk <[e-mail]>]

Yakov,

The goals of overwriting Originator_ID by the RR in RFC4684 are totally 
different then those described in mvpn spec.

To quote:

    The first of these route advertisement rules is designed such that
    the originator of an RT membership NLRI does not drop an RT
    membership NLRI that is reflected back to it, thus allowing the route
    reflector to use this RT membership NLRI in order to signal the
    client that it should distribute VPN routes with the specific target
    towards the reflector.

So it has no bearing on limiting the churn of RTs ... contrary it makes 
sure that reflected NLRI is just not dropped.

On the other hand in current mvpn draft the goal is to stabilize the 
control plane behavior to make it comparable with alternative solutions 
to the same application space.

Cheers,
R.


> Robert,
> 
>> Therefor before proceeding in this WG I would like to either see all 
>> references to BGP route reflectors use removed. Alternatively they could 
>> be replaced with the new term describing their newly defined and 
>> apparently required functionality for any form of sensible operation of 
>> the proposed herein solution.
> 
> Let me remind you that modifying the ORIGINATOR_ID and Next_hop
> attributes by Route Reflectors (by setting up the ORIGINATOR_ID
> attribute to self) is by no means new to C-multicast routing. From
> rfc4684, section 3.2:
> 
>   i.   When advertising RT membership NLRI to a route-reflector client,
>        the Originator attribute shall be set to the router-id of the
>        advertiser, and the Next-hop attribute shall be set of the local
>        address for that session.
> 
> Interestingly enough at the time this rfc was published, you did
> *not* raise any objections/concerns to Route Reflectors modifying
> the ORIGINATOR_ID and the Next_Hop attributes (by setting both of
> them to self).
> 
> Moreover, at that time you did *not* request that in rfc4684 "all
> references to BGP route reflectors use removed". You did *not*
> request to replace all references to BGP route reflectors in that
> rfc "with the new term".
> 
> All this is especially interesting since you are one of the co-authors
> of rfc4684.
> 
> Yakov.