IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN
RFC 6515

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    l3vpn mailing list <l3vpn@ietf.org>,
    l3vpn chair <l3vpn-chairs@tools.ietf.org>
Subject: Protocol Action: 'IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN' to Proposed Standard (draft-ietf-l3vpn-mvpn-infra-addrs-05.txt)

The IESG has approved the following document:
- 'IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast
  (draft-ietf-l3vpn-mvpn-infra-addrs-05.txt) as a Proposed Standard

This document is the product of the Layer 3 Virtual Private Networks
Working Group.

The IESG contact persons are Stewart Bryant and Adrian Farrel.

A URL of this Internet Draft is:

Technical Summary

   To provide Multicast VPN (MVPN) service, Provider Edge routers
   originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN")
   BGP routes; they also originate unicast VPN routes that carry MVPN-
   specific attributes.  These routes encode addresses from the
   customer's address space, as well as addresses from the provider's
   address space.  These two address spaces are independent, and the
   address family (IPv4 or IPv6) of the two spaces may or may not be the
   same.  These routes always contain an "address family" field that
   specifies whether the customer addresses are IPv4 addresses or
   whether they are IPv6 addresses.  However, there is no field that
   explicitly specifies the address family of the provider addresses.
   To ensure interoperability, this document specifies that provider
   IPv4 addresses are always encoded in these update messages as four-
   octet addresses, and that the distinction between IPv4 and IPv6 is
   signaled solely by the length of the address field.  Specific cases
   are explained in detail.

Working Group Summary

  This document is a product of L3VPN WG. There were no 
  technical comments on the document during the WG Last Call, 
  which was completed in November 2010.

  During IESG review some additional comments were raised
  by a member of the community that required the document
  to go back through WG Last Call and IETF Last Call where
  no further comments were made.

Document Quality

  The L3VPN chairs report that they are aware of at least two
  implementations of this specification.


   Ben Niven-Jenkins is the Document Shepherd for this document.
   Stewart Bryant is the Responsible Area Director.

RFC Editor Note

This document updates draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt which
is in the same cluster. This document should therefore  be assigned a 
later RFC number than draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt