> 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.
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.
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.
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.
> 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.
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 ;-)
Note that this method of encoding the next hop is not consistent with the MVPN
standards; please see RFC 6515 for details.
