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
>