--- 1/draft-ietf-teas-gmpls-signaling-smp-09.txt	2022-01-16 19:13:09.804454269 -0800
+++ 2/draft-ietf-teas-gmpls-signaling-smp-10.txt	2022-01-16 19:13:09.840455159 -0800
@@ -1,23 +1,23 @@
 
 TEAS Working Group                                                 J. He
 Internet-Draft                                                   I. Busi
 Updates: 4872, 4873 (if approved)                    Huawei Technologies
 Intended status: Standards Track                                 J. Ryoo
-Expires: July 17, 2022                                           B. Yoon
+Expires: July 20, 2022                                           B. Yoon
                                                                     ETRI
                                                                  P. Park
                                                                       KT
-                                                        January 13, 2022
+                                                        January 16, 2022
 
          GMPLS Signaling Extensions for Shared Mesh Protection
-                 draft-ietf-teas-gmpls-signaling-smp-09
+                 draft-ietf-teas-gmpls-signaling-smp-10
 
 Abstract
 
    ITU-T Recommendation G.808.3 defines the generic aspects of a Shared
    Mesh Protection (SMP) mechanism, where the difference between SMP and
    Shared Mesh Restoration (SMR) is also identified.  ITU-T
    Recommendation G.873.3 defines the protection switching operation and
    associated protocol for SMP at the Optical Data Unit (ODU) layer.
    RFC 7412 provides requirements for any mechanism that would be used
    to implement SMP in a Multi-Protocol Label Switching - Transport
@@ -35,21 +35,21 @@
    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 July 17, 2022.
+   This Internet-Draft will expire on July 20, 2022.
 
 Copyright Notice
 
    Copyright (c) 2022 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
@@ -270,22 +270,22 @@
 
 5.1.  Identifiers
 
    To simplify association operations, both LSPs (i.e., the protected
    and the secondary LSPs) belong to the same session.  Thus, the
    SESSION object MUST be the same for both LSPs.  The LSP ID, however,
    MUST be different to distinguish between the protected LSP carrying
    normal traffic and the secondary LSP.
 
    A new LSP Protection Type "Shared Mesh Protection" is defined (see
-   Section 6.1) to the LSP Flags of PROTECTION object (see [RFC4872]) to
-   set up the two LSPs.  This LSP Protection Type value is applicable
+   Section 6.1) for the LSP Flags of PROTECTION object (see [RFC4872])
+   to set up the two LSPs.  This LSP Protection Type value is applicable
    only to bidirectional LSPs as required in [G808.3].
 
 5.2.  Signaling Primary LSPs
 
    The PROTECTION object (see [RFC4872]) is included in the Path message
    during signaling of the primary working LSPs, with the LSP Protection
    Type value set to "Shared Mesh Protection".
 
    Primary working LSPs are signaled by setting in the PROTECTION object
    the S bit to 0, the P bit to 0, the N bit to 1 and in the ASSOCIATION
@@ -386,21 +386,21 @@
    Section 4, if it still needs the protection resource.
 
 5.6.  SMP APS Configuration
 
    SMP relies on APS protocol messages being exchanged between the nodes
    along the path to activate an SMP protecting LSP.
 
    In order to allow exchange of APS protocol messages, an APS channel
    has to be configured between adjacent nodes along the path of the SMP
    protecting LSP.  This should be done before any SMP protecting LSP
-   has been set up by other means than GMPL signaling which are
+   has been set up by other means than GMPLS signaling which are
    therefore outside the scope of this document.
 
    Depending on the APS protocol message format, the APS protocol may
    use different identifiers than GMPLS signaling to identify the SMP
    protecting LSP.
 
    Since APS protocol is for further study in [G808.3], it can be
    assumed that APS message format and identifiers are technology-
    specific and/or vendor-specific.  Therefore, additional requirements
    for APS configuration are outside the scope of this document.