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

[Yakov Rekhter <[e-mail]>]

Jie,

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

see in-line...

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

Agreed. 

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

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

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

Yes.

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

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

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

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.