Subject: RE: Re: Global Table Multicast

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 1 Nov 2013 14:10:25 +0000

Linda,

Please see zzh> below.

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 31, 2013 10:52 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Jeffrey (Zhaohui) Zhang
Subject: 答复: Re: Global Table Multicast

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-masked]<mailto:[email-masked]>> 写于 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.
Zzh> If the provider only support MVPN, why would every PE have to build a default tunnel for GTM?
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:)
Zzh> If the provider only support GTM, why would every PE have to build a default tunnel for every VRF?

>
> 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 :)
Zzh> Use/no-use of the RD will also lead to different coding. Since we have an option to make things (almost identical), why not?
>
> 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?
Zzh> So? RD 0:0 was not used before anyway.

> > 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 ?
Zzh> The VRF import RT has two parts: global admin field and local admin field. The global admin field constrains the distribution to only the upstream PE and the local admin field identifies the particular VRF. In draft-zzhang, the local admin field is set to 0 because as you said there is only one global table; but we still need the global admin field to constrain the distribution of the c-mcast route to only the upstream PE.
Jeffrey
>
> 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.

---

From: [email-masked]
Date: Wed, 6 Nov 2013 14:54:38 +0800

Jeffrey,
 
   OK, I see. No problem now.
   Many thx:)

BRs,
Linda

"Jeffrey (Zhaohui) Zhang" <[email-masked]> 
2013-11-01 22:10

收件人
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
主题
RE: Re: Global Table Multicast

Linda,
 
Please see zzh> below.

Hi，Eric， 

  Then thanks for your reply. I still have some questions seeing inline 
below. Would you please explain for me? 

  Thanks:) 

BRs, 
Linda Wang 

> 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. 
Zzh> If the provider only support MVPN, why would every PE have to build a 
default tunnel for GTM?
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:) 
Zzh> If the provider only support GTM, why would every PE have to build a 
default tunnel for every VRF?
 
> 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 :) 
Zzh> Use/no-use of the RD will also lead to different coding. Since we 
have an option to make things (almost identical), why not?
> 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:)
> Setting the RD to zero is not much of a complication.  It's a lot 
simpler
//Linda：RD 0:0 is reserved by GTM,which means VPN VRF can't use RD 
0:0,right?
Zzh> So? RD 0:0 was not used before anyway.

> 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 ? 
Zzh> The VRF import RT has two parts: global admin field and local admin 
field. The global admin field constrains the distribution to only the 
upstream PE and the local admin field identifies the particular VRF. In 
draft-zzhang, the local admin field is set to 0 because as you said there 
is only one global table; but we still need the global admin field to 
constrain the distribution of the c-mcast route to only the upstream PE.
Jeffrey
> 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:)
 
--------------------------------------------------------
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.