RSVP-TE P2MP Tunnels on RMR
draft-zzhang-teas-rmr-rsvp-p2mp-00

Document Type Active Internet-Draft (individual)
Last updated 2018-09-07 (latest revision 2018-07-24)
Replaces draft-zzhang-mpls-rmr-rsvp-p2mp
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
TEAS WG                                                         Z. Zhang
Internet-Draft                                               A. Deshmukh
Intended status: Standards Track                                R. Singh
Expires: January 25, 2019                               Juniper Networks
                                                           July 24, 2018

                      RSVP-TE P2MP Tunnels on RMR
                   draft-zzhang-teas-rmr-rsvp-p2mp-00

Abstract

   This document specifies the optimization in RSVP-TE P2MP tunnel
   signaling over Resilient MPLS Rings (RMR).

Requirements Language

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

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 January 25, 2019.

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
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Zhang, et al.           Expires January 25, 2019                [Page 1]
Internet-Draft                rmr-rsvp-p2mp                    July 2018

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  RMR Object  . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Procedures  . . . . . . . . . . . . . . . . . . . . . . .   4
       2.2.1.  PATH Message/State  . . . . . . . . . . . . . . . . .   4
       2.2.2.  RESV Message/State  . . . . . . . . . . . . . . . . .   5
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Traditional RSVP-TE P2MP tunnel signaling could be quite involving.
   With RMR, this could be significantly simplifed:

   There is no need for ERO/RRO/SERO/SRRO or hop by hop rouing.  The
   tunnel ingress simply sends PATH messages in one or both directions
   of the ring, depending on how leaves are best reached.  The <S2L Sub-
   LSP Descriptor List> only needs to list the tunnel leaves, and a
   transit router does not need to "branch" a PATH message into multiple
   ones Therefore, unless there are many tunnel leaves on a huge ring, a
   single PATH message is enough.  In the rare situation of a large
   tunnel with many leaves to list, a small number of PATH messages
   should suffice.  Additionally, there is no need to signal and
   maintain individual sub-LSPs (one for each leaf) any more.  As a
   result, corresponding PATH/RESV state is also reduced.  Each node
   only needs to maintain a single PATH state and a single RESV state
   for each P2MP tunnel, and the RESV state does not need to track
   individual leaves - it just need to track if a RESV is received from
   downstream and/or if this node itself is a leaf.

   A RESV message is triggered to the PHOP when the RESV state is first
   created (either because the node is a leaf or because a RESV message
   is received from downstream) and it is refreshed periodically.  A
   RESV Tear is sent when the RESV state is deleted (when the node is no
   longer a Leaf and the RESV from downstream has timed out or a RESV
   Tear is received).

   Optionally, the tunnel ingress may not need to list any/all leaves.
   It could simply send the PATH message around the ring, with the <S2L

Zhang, et al.           Expires January 25, 2019                [Page 2]
Internet-Draft                rmr-rsvp-p2mp                    July 2018

   Sub-LSP Descriptor List> listing the root itself.  Through methods
Show full document text