Subject: I-D Action:draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt

From: [email-masked]
Date: Mon, 27 Apr 2009 07:45:01 -0700 (PDT)

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 Encodings and Procedures for Multicast in MPLS/BGP IP VPNs
	Author(s)       : R. Aggarwal, et al.
	Filename        : draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt
	Pages           : 61
	Date            : 2009-04-27

This document describes the BGP encodings and procedures for
exchanging the information elements required by Multicast in MPLS/BGP
IP VPNs, as specified in [MVPN].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-2547bis-mcast-bgp-07.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.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 27 Apr 2009 08:06:29 -0700

Hi,

I have few question on section 11.4 which has not been addressed by 
authors yet.

    Hence a BGP Route Reflector or ASBR that receives multiple such
    routes with the same NLRI will re-advertise only one of these routes
    to other BGP speakers.
...
    To further reduce the routing churn due to C-multicast routes changes
    a Route Reflector that re-advertises a C-multicast route SHOULD set
    the Next Hop field of the MP_REACH_NLRI attribute of the route to an
    IP address of the Route Reflector.

Question 1:

* If we are considering route reflection as defined in RFC4456 to what 
value such described in section 11.4 route reflector will set the 
ORIGINATOR_ID ?

   - If it will not set it to the best path as it would be per default 
bgp behavior to which reflected path it would be set ? First received ?

   - If it will set it to the best bgp path among those carrying the 
same set of C-multicast routes spec should clarify that each subsequent 
new best path election will result in new advertisement of same 
C-multicast route.

Question 2:

* When route reflector will withdraw advertised C-multicast route ?

   - Would it withdraw only when last valid path attached to given 
C-multicast route is withdrawn from it by the PE ?

   - Would it need to send implicit withdraw when best path get's 
withdrawn and new path selected as best to reflect to ORIGINATOR_ID value ?

Thx,
R.