ietf
[Top] [All Lists]

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

2009-11-09 17:17:15
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>