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 protected]> 写于 2013-10-16 21:13:51:

> 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) �C 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 protected] [mailto:[email protected]] 
> Sent: Wednesday, October 16, 2013 4:17 AM
> To: Jeffrey (Zhaohui) Zhang
> Cc: [email protected]; [email protected]
> Subject: 答复: RE: [MBONED] New Version Notification for draft-
> zzhang-l3vpn-mvpn-global-table-mcast-00.txt
> 
> 
> Hi,Jeffrey 
> 
>   See below inline. 
> 
>   If I miss something please point out.Thanks! 
> 
> BRs, 
> Linda Wang 
> 
> 
> "Jeffrey (Zhaohui) Zhang" <[email protected]> 写于 2013-10-11 22:02:42:
> 
> > Linda, 
> > 
> > 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? 
> 
> > Thanks. 
> > Jeffrey 
> > 
> > From: [email protected] [mailto:[email protected]] 
> > Sent: Friday, October 11, 2013 4:24 AM
> > To: Jeffrey (Zhaohui) Zhang
> > Cc: [email protected]; [email protected]
> > Subject: Re: [MBONED] New Version Notification for draft-zzhang-
> > l3vpn-mvpn-global-table-mcast-00.txt 
> > 
> > 
> > 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. 
> > 
> > 
> 
> --------------------------------------------------------
> 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.
> 
> 
--------------------------------------------------------
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.

Reply via email to