Subject: Re: [MBONED] New Version Notification for draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt

From: [email-masked]
Date: Fri, 11 Oct 2013 16:23:54 +0800

Hi,Jeffrey

  Section 3 said:
   RFC 6514 specifies that MCAST-VPN routes carry a Route Distinguisher
   (RD).  For GTM, it SHOULD be possible to configure an RD that is used
   only for MCAST-VPN A-D routes for the global table.  The RD can be
   defaulted to a special 64-bit all-zero value (denoted as RD 0:0).
 
This means we can configure the RD when GTM is enable, right? 
Here is a question: In a large network, there are many different 
administrators,what if admin1 configures the value 1:1 in his manage 
area(area1), and admin2 configures the valure 2:2 in another area(area2)? 

If I miss something please point out.Thanks!

BRs
Linda Wang

> Hi,
> 
> This is an update to draft-zzhang-mboned-mvpn-global-table-mcast-00.
> 
> We have re-homed it to l3vpn, and hopefully addressed most comments 
> that Eric had.
> 
> Your review and comments are appreciated.
> 
> Thanks.
> Jeffrey
> 
> -----Original Message-----
> From: internet-drafts at ietf.org [mailto:internet-drafts at ietf.org] 
> Sent: Friday, July 12, 2013 3:55 PM
> To: Dante J.Pacella; Lenny Giuliano; Jason Schiller; Lenny Giuliano;
> Jeffrey (Zhaohui) Zhang
> Subject: New Version Notification for draft-zzhang-l3vpn-mvpn-
> global-table-mcast-00.txt
> 
> 
> A new version of I-D, draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt
> has been successfully submitted by Jeffrey Zhang and posted to the
> IETF repository.
> 
> Filename:    draft-zzhang-l3vpn-mvpn-global-table-mcast
> Revision:    00
> Title:       Global Table Multicast with BGP-MVPN Procedures
> Creation date:    2013-07-12
> Group:       Individual Submission
> Number of pages: 14
> URL:             http://www.ietf.org/internet-drafts/draft-zzhang-
> l3vpn-mvpn-global-table-mcast-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-zzhang-l3vpn-
> mvpn-global-table-mcast
> Htmlized:        http://tools.ietf.org/html/draft-zzhang-l3vpn-mvpn-
> global-table-mcast-00
> 
> 
> Abstract:
>    This document describes a way to implement Global Table Multicast,
>    aka Internet Multicast, using BGP encodings and procedures for MVPN
>    as specified in [RFC6514].
> 
>    No protocol modification/extension is required.  This is purely for
>    informational and clarifying purposes only.
> 
>  
> 
> 
> The IETF Secretariat
> 
> 
> 
--------------------------------------------------------
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: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 11 Oct 2013 14:02:42 +0000

Linda,

Base MVPN protocol allows to have different RDs and same is here.
In a newer revision of the draft (to be submitted), we have actually removed that wording, because while it is ok to use non-zero RDs it does not add any obvious value. The original text was to show that existing MVPN procedures can be used as is (well, with some minor excepts that were spelled out).

Thanks.
Jeffrey

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 11, 2013 4:24 AM
To: Jeffrey (Zhaohui) Zhang
Cc: [email-masked]; [email-masked]
Subject: Re: [MBONED] New Version Notification for draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt

Hi,Jeffrey

  Section 3 said:

This means we can configure the RD when GTM is enable, right?
Here is a question: In a large network, there are many different administrators,what if admin1 configures the value 1:1 in his manage area(area1), and admin2 configures the valure 2:2 in another area(area2)?

BRs
Linda Wang

---

From: [email-masked]
Date: Wed, 16 Oct 2013 16:16:58 +0800

Hi,Jeffrey

  See below inline.

BRs,
Linda Wang

> Base MVPN protocol allows to have different RDs and same is here.
//Linda: Sorry for mistaking RD to RT.
> In a newer revision of the draft (to be submitted), we have actually
> removed that wording, because while it is ok to use non-zero RDs it 
> does not add any obvious value. The original text was to show that 
> existing MVPN procedures can be used as is (well, with some minor 
> excepts that were spelled out).
//Linda：you'll remove RD wording? Yes,agree for remove RD field in all 
A-D Routes in the context of GTM. But what about RT? Do you still want to 
remain RT? If we remove RT,there are no the questions you mentioned in 
Section 3.3.

//Linda: Also, I saw MBR(MPLS Border Router) is called in your draft, does 
it mean the core network must be MPLS-enable? 

> > A new version of I-D, 
draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt
> 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: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 16 Oct 2013 13:13:51 +0000

Linda,

RD is still used, but it’s all-0. I meant that the wording about using any value for the RD is removed.
RT is still used (optional in certain case) – you’ll see the details once the new revision is posted (soon).

Initially we used “MPLS Border Router” which implies MPLS core; but that has also been renamed (and MPLS core is not required).

Jeffrey

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 16, 2013 4:17 AM
To: Jeffrey (Zhaohui) Zhang
Cc: [email-masked]; [email-masked]
Subject: 答复: RE: [MBONED] New Version Notification for draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt

Hi,Jeffrey

  See below inline.

BRs,
Linda Wang

> excepts that were spelled out).
//Linda：you'll remove RD wording? Yes,agree for remove RD field in all A-D Routes in the context of GTM. But what about RT? Do you still want to remain RT? If we remove RT,there are no the questions you mentioned in Section 3.3.

//Linda: Also, I saw MBR(MPLS Border Router) is called in your draft, does it mean the core network must be MPLS-enable?

> Thanks.
> Jeffrey
>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: [email-masked]
Date: Thu, 17 Oct 2013 09:44:41 +0800

Hi,Jeffrey

  Expecting for your updated version.

  But I still insist to remove RD&RT, like in my draft 
http://datatracker.ietf.org/doc/draft-wang-mboned-glo-ipv6-mcast-reachability/,in 
which we define a new NLRI. 
  The advantage for defining a new NLRI is obvious as follow:

  1.Without RD:
    a. All the A-D route is more simper in encoding.
    b. RD set 0:0 doesn't add any obvious value, on the contrary, it set 
0:0 occupys a little space of VRF RD. 

  2.Without RT:
    a. There are no questions you mentioned in section 3.3.
    b. We can remove VRF Route Import Extended Community as we define a 
new NLRI without RD&RT conception.

  3.Global multicast reachability is not going to aggregate,so we can 
remove the MPLS Label field in PMSI Tunnel Attribute to simple the 
encoding.

  4.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.

  Expecting further communication in the coming meeting.Thanks!

BRs,
Linda Wang

"Jeffrey (Zhaohui) Zhang" <[email-masked]> 写于 2013-10-16 21:13:51:

> Initially we used “MPLS Border Router” which implies MPLS core; but 
> that has also been renamed (and MPLS core is not required).
> 
> Jeffrey
> 
> Subject: 答复: RE: [MBONED] New Version Notification for draft-
> zzhang-l3vpn-mvpn-global-table-mcast-00.txt
> 
> 
> Hi,Jeffrey 
> 
>   See below inline. 
> 
> //Linda：you'll remove RD wording? Yes,agree for remove RD field in 
> all A-D Routes in the context of GTM. But what about RT? Do you 
> still want to remain RT? If we remove RT,there are no the questions 
> you mentioned in Section 3.3. 
> 
> //Linda: Also, I saw MBR(MPLS Border Router) is called in your 
> draft, does it mean the core network must be MPLS-enable? 
> 
> > Thanks. 
> > Jeffrey 
> >

---

From: Eric Rosen <[email-masked]>
Date: Thu, 24 Oct 2013 09:54:12 -0400

> If providers just want to enable Global Multicast Reachablity only, they
> just need enable MCAST-IPv6(define in

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.

> 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.

---

From: [email-masked]
Date: Fri, 1 Nov 2013 10:51:31 +0800

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

> 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:) 
 
> 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 :) 

> 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?
> 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 ?  
> 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:)