Hi，Eric， Today is a special day, so, first, Happy Halloween :)
Then thanks for your reply. I still have some questions seeing inline below. Would you please explain for me? Thanks:) BRs, Linda Wang Eric Rosen <[email protected]> 写于 2013-10-24 21:54:12: > > If providers just want to enable Global Multicast Reachablity only, they > > just need enable MCAST-IPv6(define in > > draft-wang-mboned-glo-ipv6-mcast-reachability) address family only without > > enable MCAST-VPN address family which may cause unnecessary route > > advertisements. > > I really don't understand this line of reasoning. > > Suppose a provider wants to use his backbone network to support both VPN > Multicast (MVPN) and and Global Table Multicast (GTM), and wants to use > protocols and procedures based on RFC6514 for both. Perhaps, e.g., the > provider is already supporting MVPN and now wants to add GTM support, using, > as much as possible, the same set of protocols and procedures. //Linda:Suppose a provider enables MCAST-VPN ability in his backbone network for only support VPN Multicast, except all MVPN I-PMSI tunnels are building for every VRF , every PE would additionally built a default tunnel for GTM and all the procedures using for building the GTM tunnel are redundant. And on the other hand, a provider enables MCAST-VPN ability in his backbone network for only support GTM, except GTM tunnels are building, every PE would additionally built default tunnels for every VRF and all the procedures for building the MVPN I-PMSI tunnels are redundant.So draft-wang can avoid the unneccery tunnel building. Am I right? If I missing anything, please point out:) > > Following the procedures of draft-zzhang-l3vpn-mvpn-global-table-mcast, the > MVPN C-multicast and A-D routes use the same AFI/SAFI (MCAST-VPN) as the GTM > C-multicast and A-D routes. Existing procedures and tools continue to > apply. If draft-wang is used, then the provider needs to use two different > AFI/SAFIs, one for MVPN and one for GTM. What is the point of using the > additional AFI/SAFI? It's just a complication for no benefit; every > additional AFI/SAFI brings some operational overhead. //Linda: Yes,from the perspective of coding, two different AFI/SAFIs lead to two kinds of codec,but except codec, GTM can reuse many interaction procedures that MVPN is using :) > > If a provider only wants to use his backbone for GTM, the MCAST-VPN SAFI is > still fine. I don't know why you think it causes unnecessary route > advertisement. You just have to set the RD field in the NLRI to zero, so > that the NLRI identifies the global table rather than a VRF. //Linda: Sorry for misunderstanding there are unnecessary route advertisements. Yes,you're right.Thanks for pointing it out:) > It isn't worth introducing a new SAFI just to shorten the NLRI by a few > octets. > > > 1.Without RD: > > > a. All the A-D route is more simpler in encoding. > > Setting the RD to zero is not much of a complication. It's a lot simpler > than having a new SAFI. //Linda：RD 0:0 is reserved by GTM,which means VPN VRF can't use RD 0:0,right? > > 2.Without RT > > No, it's not possible to eliminate the RTs. RTs are absolutely required on > the C-multicast Join routes and the Leaf A-D routes. These route types are > always "targeted" to a single upstream node, and that node is identified by > the RT. Not only is that important for constraining the distribution of > the routes, it is also needed so that the upstream node can tell that it is > the target of a particular C-multicast Join or Leaf A-D route. //Linda: I think the upstream node is identified by the unicast route and the selected route policy, once the C-multicast Join routes received by the upstream node,then RT decides which VRF import the C-multicast routes.In the context of GTM, there is no consideration which VRF import the c-mulitcast routes but the global muticast route table.So i doute where need RT in GTM ? > > I also think it would be unwise to distribute the other route types without > RTs, as that would eliminate the ability to constrain the distribution of > those routes. It would also eliminate the ability to create extranets that > contain both VRFs and global tables. > > > We can remove VRF Route Import Extended Community > > No you can't, as that is needed, in general, to identify the "Upstream PE" > for a given multicast source or RP. The MVPN procedures depend on being > able to identify the Upstream PE ("Upstream PBR" in the draft-zzhang-...-01 > terminology). Without the VRF Route Import Extended Community, the MVPN/GTM > procedures will only work within a single AS. > > >.Global multicast reachability is not going to aggregate,so we can remove > > the MPLS Label field in PMSI Tunnel Attribute > > The MPLS Label field in the PMSI Tunnel Attribute of a Leaf A-D route is > needed to support Ingress Replication, so it cannot be eliminated. > > Also, one may wish to aggregate GTM and MVPN traffic in the same tunnel, in > which case one would want to use the MPLS label field of the PMSI Tunnel > Attribute in an I/S-PMSI A-D route to distinguish the MVPN traffic from the > GTM traffic. > > For cases where the label is not needed, RFC6514 already specifies a way to > encode "no label", i.e., set the label field to zero. There is no need to > add another yet another attribute just so that one can omit the label field > instead of setting it to zero. > > From draft-wang: > > the 6MPE routers convey the IPv4 address of > 6MPE Router-ID as the BGP Next Hop for the advertised A-D routes. > And the IPv4 address MUST be encoded as an IPv4-mapped IPv6 address > in the BGP Next Hop field. This encoding is consistent with the > definition of an IPv4-mapped IPv6 address in [RFC4291]. > > I was surprised to see this; if one objects to carrying eight octets of RD=0 > and/or three octets of label=0, surely one will object to encoding a > four-octet IPv4 address in a 16-octet field ;-) //Linda: Thanks for your humorous:) This section is only used for 6-4-6 scenario. I should clearly describe this section in next version:) > > Note that this method of encoding the next hop is not consistent with the MVPN > standards; please see RFC 6515 for details. > > > > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately.
