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@xxxxxxxx [mailto:l3vpn-bounces@xxxxxxxx]
> On Behalf Of The IESG
> Sent: Wednesday, August 26, 2009 4:47 AM
> To: IETF-Announce
> Cc: l3vpn@xxxxxxxx
> 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@xxxxxxxx mailing lists by
> 2009-09-08. Exceptionally, comments may be sent to
> iesg@xxxxxxxx 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
>
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf