Internet DRAFT - draft-ietf-pim-ipv4-prefix-over-ipv6-nh

draft-ietf-pim-ipv4-prefix-over-ipv6-nh







Network Working Group                                           A. Gupta
Internet-Draft                                              Avi Networks
Intended status: Informational                                 S. Venaas
Expires: November 2, 2018                                  Cisco Systems
                                                             May 1, 2018


         Use of PIM Address List Hello across address families
             draft-ietf-pim-ipv4-prefix-over-ipv6-nh-02.txt

Abstract

   In the PIM Sparse Mode standard there is an Address List Hello option
   used to list secondary addresses of an interface.  Usually the
   addresses would be of the same address family as the primary address.
   In this document we provide a use case for listing secondary
   addresses that are from a different family.  In particular, Multi-
   Protocol BGP (MP-BGP) has support for distributing next-hop
   information for multiple address families using one AFI/SAFI Network
   Layer Reachability Information (NLRI).  When using this combined with
   PIM, the Address List Hello option can be used to determine which PIM
   neighbor to use as RPF neighbor.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on November 2, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of



Gupta & Venaas          Expires November 2, 2018                [Page 1]

Internet-Draft  PIM Address List across address families        May 2018


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   The PIM Sparse Mode standard [RFC7761] defines an Address List Hello
   option used to list secondary addresses of an interface.  It
   specifies that the addresses listed SHOULD be of the same address
   family as the primary address.  It was not anticipated that it could
   be useful to list addresses of a different address family.  This
   document describes a use-case for listing different address families.

   While use of MP-BGP along with [RFC5549] enables one routing protocol
   session to exchange next-hop info for both IPv4 and IPv6 prefixes,
   forwarding plane needs additional procedures to enable forwarding in
   data-plane.  For example, when a IPv4 prefix is learnt over IPv6
   next-hop, forwarding plane resolves the MAC-Address (L2-Adjacency)
   for IPv6 next-hop and uses it as destination-mac while doing inter-
   subnet forwarding.  While it's simple to find the required
   information for unicast forwarding, multicast forwarding in same
   scenario poses additional requirements.



Gupta & Venaas          Expires November 2, 2018                [Page 2]

Internet-Draft  PIM Address List across address families        May 2018


   Multicast traffic is forwarding on a tree build by multicast routing
   protocols such as PIM.  Multicast routing protocols are address
   family dependent and hence a system enabled with IPv4 and IPv6
   multicast routing will have two PIM sessions one for each of the AF.
   Also, Multicast routing protocol uses Unicast reachability
   information to find unique Reverse Path Forwarding Neighbor.  Further
   it sends control messages such as PIM Join to form the tree.  Now
   when a PIMv4 session needs to initiate new multicast tree in event of
   discovering new receiver It consults Unicast control plane to find
   next-hop information.  While this multicast tree can be Shared or
   Shortest Path tree, PIMv4 will need a PIMv4 neighbor to send join.
   However, the Unicast control plane can provide IPv6 next-hop as
   explained earlier and hence we need certain procedures to find
   corresponding PIMv4 neighbor address.  This address is vital for
   correct prorogation of join and furthermore to build multicast tree.
   This document describes various approaches along with their use-cases
   and pros-cons.

   Figure 1: Example Topology



             +-------------+                   +-------------+
             |             |                   |             |
             | Router1   1::1/64          1::2/64 Router2    |
10.1.1.1/32--+             +--------I1---------|             +-+PIM receiver
             |         1.1.1.1/24         1.1.1.2/24         |
             |             +                   +             |
             |             |                   |             |
             +-------------+                   +-------------+



   In example topology, Router1 and Router2 are PIMv4 and PIMv6
   neighbors on Interface I1.  Router2 learns prefix 10.1.1.1/32's next-
   hop as 1::1/64 on Interface I1 as advertised by Router1 using BGP
   IPV6 NLRI.But in order to send (10.1.1.1/32, multicast-group) PIMv4
   join on Interface I1, Router2 needs to find corresponding PIMv4
   neighbor.  In case there are multiple PIMv4 neighbors on same
   Interface I1, problem is aggravated.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, [RFC2119].







Gupta & Venaas          Expires November 2, 2018                [Page 3]

Internet-Draft  PIM Address List across address families        May 2018


2.  Solution

   A PIM router can advertise its locally configured IPv6 addresses on
   the interface in PIMv4 Hello messages as per [RFC7761] section 4.3.4.
   Same applies for IPv4 address in PIMv6 Hello.  PIM will keep this
   info for each neighbor in Neighbor-cache along with DR-priority,
   hold-time etc.  Once IPv6 Next-hop is notified to PIMv4, it will look
   into neighbors on the notified RPF-interface and find PIMv4 neighbor
   advertising same IPv6 local address in secondary Neighbor-list.  If
   such a match is found, that particular neighbor will be uses as IPv4
   RPF-Neighbor for initiating upstream join.

   This method is valid for networks enabled with PIMv4 and PIMv6 both
   as well for the networks enabled with only PIMv4 with IPv6 BGP
   session or PIMv6 with IPv4 BGP session.  This method does't required
   any additional config changes in the network.

3.  Security Considerations

   There are no new security considerations.

4.  IANA Considerations

   There are no IANA considerations.

5.  References

5.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

5.2.  Informative References

   [RFC5549]  Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
              Layer Reachability Information with an IPv6 Next Hop",
              RFC 5549, DOI 10.17487/RFC5549, May 2009,
              <https://www.rfc-editor.org/info/rfc5549>.

   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
              2016, <https://www.rfc-editor.org/info/rfc7761>.





Gupta & Venaas          Expires November 2, 2018                [Page 4]

Internet-Draft  PIM Address List across address families        May 2018


Authors' Addresses

   Ashutosh Gupta
   Avi Networks
   5155 Old Ironsides Dr. Suite 100
   Santa Clara, CA  95054
   USA

   Email: ashutosh@avinetworks.com


   Stig Venaas
   Cisco Systems
   821 Alder Drive
   San Jose, CA  95035
   USA

   Email: stig@cisco.com

































Gupta & Venaas          Expires November 2, 2018                [Page 5]