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

Document Type Active Internet-Draft (individual)
Last updated 2019-01-29
Replaces draft-zzhang-mpls-rmr-rsvp-p2mp
Stream (None)
Intended RFC status (None)
Formats plain text 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
Updates: 4875 (if approved)                                     R. Singh
Intended status: Standards Track                        Juniper Networks
Expires: August 2, 2019                                 January 29, 2019

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

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 August 2, 2019.

Copyright Notice

   Copyright (c) 2019 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 August 2, 2019                 [Page 1]
Internet-Draft                rmr-rsvp-p2mp                 January 2019

   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 simplified:

   There is no need for ERO/RRO/SERO/SRRO or hop by hop routing.  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 August 2, 2019                 [Page 2]
Internet-Draft                rmr-rsvp-p2mp                 January 2019

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