Network Working Group                             Gargi Nalawade
Internet Draft                                 Arjun Sreekantiah
Expires: August 2004 Cisco Systems

                                MDT SAFI

1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

2. Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

3. Abstract

   There is a need for transporting MDT attributes within and across
   Autonomous Systems. This draft defines a new Address-Family that can
   be used to do the distribution.

4. Introduction

   Two end-points of a Multicast Tunnel need to know the end-point
   information and its binding to a network address and the MDT used for
   the respective VRF at the remote PE. Normally, Tunnel endpoint

draft-nalawade-mdt-safi-00.txt                                          [Page 1]

Internet Draft draft-nalawade-idr-mdt-safi-00.txt                    August 2004

   addresses can be statically configured. But in case of a large
   network with large number of VPNs where there may be a need for a
   large number of endpoints and a large number of VRFs, the amount of
   information that needs to be exchanged and maintained between PEs for
   Multicast Tunnels for VPNs, is quite large. It therefore needs a
   mechanism that can maintain and support Multicast Tunnel based VPNs
   in a flexible, scalable manner. Also, in inter-AS and inter-provider
   scenarios, this mechanism needs to be supported across autonomous
   systems and provider domains.


   A new Subsequent-Address Family called the MDT SAFI is being defined.
   The NLRI for this SAFI, will contain the address of the nexthop which
   will be used by the multicast source PE to send the PIM Join for the
   default MDT address to.

   The NLRI format is 8-byte-RD:IPv4-address followed by the MDT group
   address.  i.e. The MP_REACH attribute for this SAFI will contain one
   or more tuples of the following form :

          |                               |
          |  RD:IPv4-address (12 octets)  |
          |                               |
          |  MDT Group-address (4 octets) |

   where :

   Route-Distinguisher : is the RD of the VRF to which this MDT
   attribute belongs.

   MDT Group Address : is the Group-address of the MDT-Group that a VRF
   is associated to. This can be variable length. But for

   IPV4 addresses - this will be 4 octets.

6. The Connector Attribute

   An Optional Transitive Connector attribute is being defined to link a

draft-nalawade-mdt-safi-00.txt                                          [Page 2]

Internet Draft draft-nalawade-idr-mdt-safi-00.txt                    August 2004

   BGP AFI/SAFI with another AFI/SAFI, so that the prefix of one
   AFI/SAFI could derive an information entity that is dependant on the
   NLRI advertised through another AFI/SAFI. An example of this is as
   illustrated in [MT-DISC].

   The attribute contains one or more tuples of the form :

          |                              |
          |  AFI (2 octets)              |
          |  SAFI (1 octets)             |
          |                              |
          |  Value (Variable)            |
          |                              |

   where :

   AFI : is the value of the Address-family which needs the information
   carried in the value field of this attribute.

   SAFI : is the value of the Subsequent Address-family which needs the
   information carried in the value field of this attribute.

   Value : is a variable length field defined by the AFI/SAFI carried in
   this tuple, which would be used by the AFI/SAFI in this tuple.

   When the AFI is IPv4 Address-family and the SAFI is MDT, the value of
   the tuple will contain the IPv4 address of the PE sourcing the CE-
   learnt VPNv4 prefixes, and this attribute will accompany the VPNv4
   prefix advertisement. The usage of this attribute for this AFI/SAFI
   is described in [MT-DISC].

7. Capability Advertisement

   A BGP speaker that wishes to exchange the MDT SAFI, MUST use the
   MP_EXT Capability Code as defined in [BGP-MP], to advertise the
   corresponding (AFI, SAFI) pair.

   A BGP speaker MAY participate in the distribution of MDT information.

draft-nalawade-mdt-safi-00.txt                                          [Page 3]

Internet Draft draft-nalawade-idr-mdt-safi-00.txt                    August 2004

8. Operation

   A BGP Speaker that receives the Capability for the MDT SAFI, MAY
   advertise the MDT SAFI prefixes to that peer. The prefixes in the MDT
   SAFI are populated by the PEs that advertise their CE-learnt

9. Security Considerations

   This extension to BGP does not change the underlying security issues.

10. Acknowledgements

   The authors would like to thank  IJsbrand Wijnands for his contr-
   ibution towards the Connector Attribute needed for the IPv4-MDT SAFI
   as described in [MT-DISC]. The authors would also like to thank Shyam
   Suri, Ruchi Kapoor, Shyam Suri, Yiqun Cai, Dan Tappan, Jennifer Li,
   Yi Chou, Arjen Boers for their comments and contrib- utions. We would
   also like to thank Bhavani Parise for his review and comments.

11. Normative References

   [BGP-4]  Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol
   4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-17.txt, January 2002.

   [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
   BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002.

   [BGP-SSA] Kapoor R., Nalawade G., ôBGPv4 SAFI-Specific Attributeö,
   draft-nalawade-kapoor-bgp-ssa-00.txt, June 2003.

   [MULTI-BGP] Bates et al, Multiprotocol Extensions for BGP-4, draft-
   ietf-idr-rfc2858bis-02.txt, work in progress.

   [MT-DISC] Wijnands, I., Nalawade, G., Multicast Tunnel discovery and
   RPF connector, wijnands-mt-discovery-00.txt, work in progress.

12. Author's Addresses

   Gargi Nalawade
   170 Tasman Drive
   San Jose, CA, 95134

   Arjun Sreekantiah
   170 Tasman Drive
   San Jose, CA, 95134

draft-nalawade-mdt-safi-00.txt                                          [Page 4]

Internet Draft draft-nalawade-idr-mdt-safi-00.txt                    August 2004

13. Intellectual Property Statement

   Cisco Systems may seek patent or other intellectual property
   protection for some of all of the technologies disclosed in this
   document. If any standards arising from this document are or become
   protected by one or more patents assigned to Cisco Systems, Cisco
   intends to disclose those patents and license them on reasonable
   and non-discriminatory terms.

14. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.  The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its successors or
   assigns.  This document and the information contained herein is
   provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE

15. Expiration Date

   This memo is filed as <draft-nalawade-idr-mdt-safi-00.txt>, and
   expires August, 2004.

draft-nalawade-mdt-safi-00.txt                                          [Page 5]