Subject: RE: Last Call: draft-ietf-l3vpn-2547bis-mcast-bgp (BGP Encodings andProcedures for Multicast in MPLS/BGP IP VPNs) to Proposed Standard

From: Jie Dong <[email-masked]>
Date: Tue, 03 Nov 2009 09:57:08 +0800

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of The IESG
> Sent: Wednesday, August 26, 2009 4:47 AM
> To: IETF-Announce
> Cc: [email-masked]
> 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 [email-masked] mailing lists by 
> 2009-09-08. Exceptionally, comments may be sent to 
> [email-masked] 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
>

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 9 Nov 2009 14:15:44 -0800

Jie,

> Here are some comments on this draft. (hope this is not too late:)

see in-line...

> sections of this draft, a 4-octet AS specific equivalent  should also be

Agreed. 

> 2. Section 8: PE distinguish Labels Attribute

Thanks for catching this. The correct text should be as follows:

 "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 is
 not a multiple of 7, or the PE Address field is expected to be an IPv6
 address, and the length of the attribute is not a multiple of 19."

> of C-multicast route will be filled with an IP address? 

Yes.

> It may not consistent with statement in the first paragraph of this section:
>

The text you are quoting above applies when one uses segmented
inter-AS tunnels.

> in PMSI tunnel attribute could be moved into the NLRIs of A-D route.

When multiple multicast flows are aggregated into the same P-tunnel,
and each of these flows uses different upstream-assigned label,
then it is likely that these flows belong to different MVPNs. As
such, the routes that advertise these flows and their P-tunnel have
different RTs, and thus should not be combined into a single BGP
Update message.
  
Yakov.