RE: Last Call: draft-ietf-l3vpn-2547bis-mcast-bgp (BGP Encodings andProcedures for Multicast in MPLS/BGP IP VPNs) to Proposed Standard
Jie Dong <dongjie_dj@huawei.com> Tue, 03 November 2009 01:57 UTC
Return-Path: <dongjie_dj@huawei.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8C13A6844; Mon, 2 Nov 2009 17:57:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.805
X-Spam-Level:
X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fpNRq2uqHhp; Mon, 2 Nov 2009 17:57:00 -0800 (PST)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id DF0603A682F; Mon, 2 Nov 2009 17:56:59 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSI00L6LG39GI@szxga03-in.huawei.com>; Tue, 03 Nov 2009 09:57:09 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSI00A3XG39HH@szxga03-in.huawei.com>; Tue, 03 Nov 2009 09:57:09 +0800 (CST)
Received: from d65110 ([10.111.12.97]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSI00B0WG38NV@szxml04-in.huawei.com>; Tue, 03 Nov 2009 09:57:09 +0800 (CST)
Date: Tue, 03 Nov 2009 09:57:08 +0800
From: Jie Dong <dongjie_dj@huawei.com>
Subject: RE: Last Call: draft-ietf-l3vpn-2547bis-mcast-bgp (BGP Encodings andProcedures for Multicast in MPLS/BGP IP VPNs) to Proposed Standard
In-reply-to: <20090825204712.6F41628C290@core3.amsl.com>
To: ietf@ietf.org, 'IETF-Announce' <ietf-announce@ietf.org>
Message-id: <028201ca5c28$f3cc4c20$610c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: Acolxd/6RSMIS05DQ6a8ErKrXJXs2Q16ZHwQ
Cc: l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2009 01:57:01 -0000
Hi, Here are some comments on this draft. (hope this is not too late:) 1. 4-octets ASN support The IANA Consideration section says the Source AS extended community is 2-octet AS specific. Consider that 4-octet ASN is supported in other sections of this draft, a 4-octet AS specific equivalent should also be defined. 2. Section 8: PE distinguish Labels Attribute +---------------------------------+ | PE Address | +---------------------------------+ | Label (3 octets) | +---------------------------------+ ....... +---------------------------------+ | PE Address | +---------------------------------+ | Label (3 octets) | +---------------------------------+ If my understanding is correct, this attribute can contain multiple PE address-Label pairs. thus more than 1 PE address can exist in this attribute. So the statement below may be inaccurate: "The attribute is also considered to be malformed if the PE Address field is expected to be an IPv4 address, and the length of the attribute minus 4 is not a multiple of 3, or the PE Address field is expected to be an IPv6 address, and the length of the attribute minus 16 is not a multiple of 3." 3. In section 11.1.3, it says: "Inter-AS I-PMSI A-D routes are not used to support non-segmented inter-AS tunnels...The Source AS field in the C-multicast route is set to value of the Originating Router's IP Address field of the found Intra-AS I-PMSI A-D route." Does this mean that for non-segmented inter-AS tunnel, the Source AS filed of C-multicast route will be filled with an IP address? It may not consistent with statement in the first paragraph of this section: "From the selected UMH route the local PE extracts (a) the autonomous system number of the upstream PE (as carried in the Source AS extended community of the route), and (b) the C-multicast Import RT of the VRF on the upstream PE (the value of this C-multicast Import RT is the value of the VRF Route Import Extended Community carried by the route). The Source AS field in the C-multicast route is set to that autonomous system." Besides, if the Originating Router's IP Address is an IPv6 address, it cannot be filled into the Source AS field of C-multicast route (4-octet). 4. Considerations about Route advertising Efficiency In this draft, A-D route may carry a PMSI tunnel attribute. MCAST-VPN NLRIs with different PMSI tunnel attributes have to be advertised using different BGP update messages. Different multicast flows using different P-tunnels will be advertised using individual update messages. This can be acceptable. However, if multiple multicast flows are aggregated into the same P-tunnel, due to the different upstream/downstream labels in their PMSI tunnel attributes, they still cannot be combined into one update message. Maybe there is some space to improve the efficiency? For example, the label field in PMSI tunnel attribute could be moved into the NLRIs of A-D route. Best regards, Jie > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] > On Behalf Of The IESG > Sent: Wednesday, August 26, 2009 4:47 AM > To: IETF-Announce > Cc: l3vpn@ietf.org > Subject: Last Call: draft-ietf-l3vpn-2547bis-mcast-bgp (BGP > Encodings andProcedures for Multicast in MPLS/BGP IP VPNs) to > Proposed Standard > > The IESG has received a request from the Layer 3 Virtual > Private Networks WG (l3vpn) to consider the following document: > > - 'BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs ' > <draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt> as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send > substantive comments to the ietf@ietf.org mailing lists by > 2009-09-08. Exceptionally, comments may be sent to > iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-2547bis-m > cast-bgp-07.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > w_id&dTag=15061&rfc_flag=0 >