draft-ietf-l3vpn-mvpn-mldp-nlri-09.txt   draft-ietf-l3vpn-mvpn-mldp-nlri-10.txt 
skipping to change at page 1, line 16 skipping to change at page 1, line 16
Updates: 6514 Eric C. Rosen Updates: 6514 Eric C. Rosen
Expires: May 25, 2015 Juniper Networks, Inc. Expires: May 25, 2015 Juniper Networks, Inc.
Uwe Joorde Uwe Joorde
Deutsche Telekom Deutsche Telekom
November 25, 2014 November 25, 2014
Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes
draft-ietf-l3vpn-mvpn-mldp-nlri-09.txt draft-ietf-l3vpn-mvpn-mldp-nlri-10.txt
Abstract Abstract
Many service providers offer "BGP/MPLS IP VPN" service to their Many service providers offer "BGP/MPLS IP VPN" service to their
customers. Existing IETF standards specify the procedures and customers. Existing IETF standards specify the procedures and
protocols that a service provider uses in order to offer this service protocols that a service provider uses in order to offer this service
to customers who have IP unicast and IP multicast traffic in their to customers who have IP unicast and IP multicast traffic in their
VPNs. It is also desirable to be able to support customers who have VPNs. It is also desirable to be able to support customers who have
MPLS multicast traffic in their VPNs. This document specifies the MPLS multicast traffic in their VPNs. This document specifies the
procedures and protocol extensions that are needed to support procedures and protocol extensions that are needed to support
skipping to change at page 6, line 50 skipping to change at page 6, line 50
remains the NLRI of the S-PMSI A-D route from which it was derived. remains the NLRI of the S-PMSI A-D route from which it was derived.
In a Leaf A-D route for C-multicast mLDP that has not been derived In a Leaf A-D route for C-multicast mLDP that has not been derived
from an S-PMSI A-D, the "route key" field is as specified in from an S-PMSI A-D, the "route key" field is as specified in
[SEAMLESS-MCAST], except that the "Multicast Source Length", [SEAMLESS-MCAST], except that the "Multicast Source Length",
"Multicast Source", "Multicast Group Length", and "Multicast Group" "Multicast Source", "Multicast Group Length", and "Multicast Group"
fields are omitted, and in their place is a single mLDP FEC Element. fields are omitted, and in their place is a single mLDP FEC Element.
Thus the route key field consists of a Route Distinguisher, an MLDP Thus the route key field consists of a Route Distinguisher, an MLDP
FEC element, and the IP address of the Ingress PE router. FEC element, and the IP address of the Ingress PE router.
Please note that [BGP-ERR] section 4.3 ("Typed NLRI") is applicable Please note that [BGP-ERR] section 5.4 ("Typed NLRI") is applicable
if the Route Type field of the NLRI of a received MCAST-VPN route if the Route Type field of the NLRI of a received MCAST-VPN route
contains an unrecognized value. contains an unrecognized value. Any such routes will be discarded.
An mLDP FEC element contains an "address family" field whose value is An mLDP FEC element contains an "address family" field whose value is
from IANA's "Address Family Numbers" registry. The value of the from IANA's "Address Family Numbers" registry. The value of the
"address family" field identifies the address family of the "root "address family" field identifies the address family of the "root
node address" field of the FEC element. When an mLDP FEC element is node address" field of the FEC element. When an mLDP FEC element is
encoded into the NLRI of an a BGP update whose SAFI is MCAST-VPN, the encoded into the NLRI of an a BGP update whose SAFI is MCAST-VPN, the
address family of the root node address (as indicated in the FEC address family of the root node address (as indicated in the FEC
element) MUST "correspond to" the address family that is identified element) MUST "correspond to" the address family that is identified
in the "Address Family Identifier" (AFI) field of that BGP update. in the "Address Family Identifier" (AFI) field of that BGP update.
These two "address family" fields are considered to "correspond" to These two "address family" fields are considered to "correspond" to
 End of changes. 3 change blocks. 
3 lines changed or deleted 3 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/