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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf