Skip to main content

GMPLS Signaling Extensions for Shared Mesh Protection
draft-ietf-teas-gmpls-signaling-smp-12

Revision differences

Document history

Date Rev. By Action
2022-08-09
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-07-12
12 (System) RFC Editor state changed to AUTH48
2022-07-11
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2022-06-06
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2022-06-06
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2022-06-06
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2022-06-03
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2022-06-02
12 (System) RFC Editor state changed to EDIT
2022-06-02
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-06-02
12 (System) Announcement was received by RFC Editor
2022-06-02
12 (System) IANA Action state changed to In Progress
2022-06-02
12 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2022-06-02
12 Amy Vezza IESG has approved the document
2022-06-02
12 Amy Vezza Closed "Approve" ballot
2022-06-02
12 Amy Vezza Ballot approval text was generated
2022-06-02
12 (System) Removed all action holders (IESG state changed)
2022-06-02
12 John Scudder IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2022-04-27
12 Robert Wilton [Ballot comment]
Thanks for addressing my discuss in -12.
2022-04-27
12 Robert Wilton [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss
2022-04-19
12 (System) Changed action holders to John Scudder (IESG state changed)
2022-04-19
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-04-19
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2022-04-19
12 Jeong-dong Ryoo New version available: draft-ietf-teas-gmpls-signaling-smp-12.txt
2022-04-19
12 (System) New version approved
2022-04-19
12 (System) Request for posting confirmation emailed to previous authors: Bin-Yeong Yoon , He Jia , Italo Busi , Jeong-dong Ryoo , Peter Park
2022-04-19
12 Jeong-dong Ryoo Uploaded new revision
2022-04-07
11 (System) Changed action holders to John Scudder, Italo Busi, He Jia, Jeong-dong Ryoo, Bin-Yeong Yoon, Peter Park (IESG state changed)
2022-04-07
11 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2022-04-07
11 Robert Wilton
[Ballot discuss]
Thanks for this document, and sorry for the late discuss, which should hopefully be trivial to fix.

  Notification (N): 1 bit

  …
[Ballot discuss]
Thanks for this document, and sorry for the late discuss, which should hopefully be trivial to fix.

  Notification (N): 1 bit

      When set to 1, this bit indicates that the control plane message
      exchange is only used for notification during protection
      switching.  When set to 0 (default), it indicates that the control
      plane message exchanges are used for protection-switching
      purposes.  The N bit is only applicable when the LSP Protection
      Type Flag is set to 0x04 (1:N Protection with Extra- Traffic),
      0x08 (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional
      Protection), or 0x20 (Shared Mesh Protection).  If 0x20 (SMP), the
      N bit MUST be set to 1.  The N bit MUST be set to 0 in any other
      case.

I think that the way that this RFC4872 text has been updated makes this text unclear/ambiguous.

Specifically, I think that somebody could reasonably interpret this as saying that the N bit is set to 1 for SMP, and otherwise it must always be set to 0, but I don't think that is the intention.  So please can this be clarified.

One fix could be to swap the order of the last 2 sentences.  E.g.,

      or 0x20 (Shared Mesh Protection).  The N bit MUST
      be set to 0 in any other case. If 0x20 (SMP), the
      N bit MUST be set to 1.

Alternatively, I think that you could possibly just remove the "If 0x20 (SMP), the N bit MUST be set to 1." and instead rely on the text in 5.2/5.3, (perhaps strengthening with RFC 2119 language if required).

Regards,
Rob
2022-04-07
11 Robert Wilton [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton
2022-04-06
11 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2022-04-06
11 Warren Kumari
[Ballot comment]
I'd like to thank the authors for this document -- I found it a useful, well written, and easy read.

I'd especially like …
[Ballot comment]
I'd like to thank the authors for this document -- I found it a useful, well written, and easy read.

I'd especially like to thank Dan Romascanu for his OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-teas-gmpls-signaling-smp-10-opsdir-lc-romascanu-2022-02-01/), and for the subsequent conversation.
The text which was added to the Introduction section improved the document.
2022-04-06
11 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2022-04-06
11 Roman Danyliw
[Ballot comment]
Thank you to David Mandelberg for the SECDIR review.

** Section 6.3

  In order to indicate the SMP preemption priority, the 16-bit …
[Ballot comment]
Thank you to David Mandelberg for the SECDIR review.

** Section 6.3

  In order to indicate the SMP preemption priority, the 16-bit Reserved
  field [RFC4873] of the PROTECTION object is redefined.  The last 32
  bits in the PROTECTION object defined in [RFC4873] are updated as
  follows:


I had trouble following the references in the above text to understand what exactly was being updated.  John Scudder help me understand the follow:

RFC 4872 reserved a 32-bit field in the PROTECTION object header. Subsequently, RFC 4873 allocated several fields from that field, and left the remainder of the bits reserved. This specification further allocates the preemption priority field from those formerly-reserved bits.

I’d recommend included text to this effect.

** Concur with Paul and Francesca that a registry for LSP (Protection Type) Flag would be helpful.

** Section 8.

For this reason, it is important not only to use security
  mechanisms as discussed in [RFC4872] but also to preserve privacy of
  information about protecting LSPs within the network.

How would one "preserve the privacy of information about protecting LSPs"?  Is this equivalent to acknowledging that detailed knowledge of a network's topology can help an attacker better target or improve the efficacy of an attack?
2022-04-06
11 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2022-04-06
11 John Scudder
[Ballot comment]
I just noticed that RFC 4873 has:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|R|  Reserved    | Seg.Flags |        …
[Ballot comment]
I just noticed that RFC 4873 has:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|R|  Reserved    | Seg.Flags |          Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

But this draft has:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|R|  Reserved    | Seq.Flags |  Reserved    | Preempt Prio  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"Seg" with a G got changed into "Seq" with a Q. I assume that was a typo and should be corrected.
2022-04-06
11 John Scudder Ballot comment text updated for John Scudder
2022-04-05
11 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2022-04-05
11 Francesca Palombini
[Ballot comment]
Thank you for the work on this document.

Only one comment: I had the same reaction as Paul, I believe it would have …
[Ballot comment]
Thank you for the work on this document.

Only one comment: I had the same reaction as Paul, I believe it would have been good to create IANA registries for the LSP (Protection Type) Flags, although that is really a comment on RFC 4872 (which by the way already uses what I consider IANA-compliant terminology by stating "The following values are defined.  All other values are reserved."). But since this is a general comment, which can make more sense if other flags are expected to be defined in the future, I leave it up to the working group and AD to make the best choice.

Francesca
2022-04-05
11 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2022-04-05
11 Lars Eggert
[Ballot comment]
Document has a TLP Section 6.c.iii "pre-5378" boilerplate. Is this really
needed? What text is copied from an older RFC?

Thanks to Dale …
[Ballot comment]
Document has a TLP Section 6.c.iii "pre-5378" boilerplate. Is this really
needed? What text is copied from an older RFC?

Thanks to Dale Worley for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/sVz7p-OqBMRBhxHaqKo9667CRd8).

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

Section 4. , paragraph 8, nit:
> hase several secondary LSPs in an efficient manner, and (5) the capability to
>                            ^^^^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "efficiently" to avoid
wordiness.

Section 5.5. , paragraph 2, nit:
> does not need the shared resources any more. Upon receipt of this Notify mess
>                                    ^^^^^^^^
Did you mean the adverb "anymore"?

Section 5.6. , paragraph 3, nit:
> t to 0x04 (1:N Protection with Extra- Traffic), 0x08 (1+1 Unidirectional Pro
>                                ^^^^^^^^^^^^^^
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.
2022-04-05
11 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2022-04-04
11 Paul Wouters
[Ballot comment]
I came in a bit late as incoming AD, but happy to see that most review comments were addressed. I think the wording …
[Ballot comment]
I came in a bit late as incoming AD, but happy to see that most review comments were addressed. I think the wording about the Reserved Field changes could be improved a little (there are 4 different Reserved fields, although only one is 16 bit in size), although it is clear enough to understand which field was meant.

It would have been nice if the "Notification and Operational Bits" had been an IANA registry, so it could have been updated more clearly without repeating a lot of text from the RFC being updated. Especially if more bits are going to be used in the future. But it is a bit late for that now as it would require more updated text for the generic handling of the bits along with fields in the IANA registry for the bit specific behaviours (eg the setting of N and O bit)
2022-04-04
11 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2022-04-04
11 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2022-04-04
11 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

Please find below a very minor non-blocking COMMENT point, feel free to ignore.

Special …
[Ballot comment]
Thank you for the work put into this document.

Please find below a very minor non-blocking COMMENT point, feel free to ignore.

Special thanks to Vishnu Beeram for the shepherd's write-up including the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

## Section 1

While slightly out of context of this document, the operational differences between between SMP and SMR would have been a plus. The last sentence of section 3 would have been better in this introduction IMHO, but this is a matter of taste ;-)
2022-04-04
11 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2022-04-03
11 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2022-03-31
11 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2022-03-31
11 Gunter Van de Velde Closed request for Telechat review by OPSDIR with state 'Overtaken by Events'
2022-03-29
11 Andrew Alston [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston
2022-03-24
11 Dan Romascanu Assignment of request for Telechat review by OPSDIR to Dan Romascanu was rejected
2022-03-24
11 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Dan Romascanu
2022-03-24
11 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Dan Romascanu
2022-03-23
11 Cindy Morgan Placed on agenda for telechat - 2022-04-07
2022-03-22
11 John Scudder Ballot has been issued
2022-03-22
11 John Scudder [Ballot Position Update] New position, Yes, has been recorded for John Scudder
2022-03-22
11 John Scudder Created "Approve" ballot
2022-03-22
11 John Scudder IESG state changed to IESG Evaluation from Waiting for Writeup
2022-03-22
11 John Scudder Ballot writeup was changed
2022-02-24
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2022-02-24
11 Jeong-dong Ryoo New version available: draft-ietf-teas-gmpls-signaling-smp-11.txt
2022-02-24
11 (System) New version approved
2022-02-24
11 (System) Request for posting confirmation emailed to previous authors: Bin-Yeong Yoon , He Jia , Italo Busi , Jeong-dong Ryoo , Peter Park
2022-02-24
11 Jeong-dong Ryoo Uploaded new revision
2022-02-03
10 (System) IESG state changed to Waiting for Writeup from In Last Call
2022-02-02
10 Dale Worley Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dale Worley. Sent review to list.
2022-02-01
10 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2022-02-01
10 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-teas-gmpls-signaling-smp-10. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-teas-gmpls-signaling-smp-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the "Notify Error" error code (25) registry, part of the Error Codes and Globally-Defined Error Value Sub-Codes registry on the Resource Reservation Protocol (RSVP) Parameters registry page located at:

https://www.iana.org/assignments/rsvp-parameters/

two new registrations are to be made as follows:

Value: [ TBD-at-Registration ]
Description: Shared resources unavailable
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Shared resources available
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2022-02-01
10 Dan Romascanu Request for Last Call review by OPSDIR Completed: Not Ready. Reviewer: Dan Romascanu. Sent review to list.
2022-01-30
10 David Mandelberg Request for Last Call review by SECDIR Completed: Ready. Reviewer: David Mandelberg. Sent review to list.
2022-01-28
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to David Mandelberg
2022-01-28
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to David Mandelberg
2022-01-28
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Dan Romascanu
2022-01-28
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Dan Romascanu
2022-01-21
10 Jean Mahoney Request for Last Call review by GENART is assigned to Dale Worley
2022-01-21
10 Jean Mahoney Request for Last Call review by GENART is assigned to Dale Worley
2022-01-20
10 Cindy Morgan IANA Review state changed to IANA - Review Needed
2022-01-20
10 Cindy Morgan
The following Last Call announcement was sent out (ends 2022-02-03):

From: The IESG
To: IETF-Announce
CC: draft-ietf-teas-gmpls-signaling-smp@ietf.org, jgs@juniper.net, teas-chairs@ietf.org, teas@ietf.org, vbeeram@juniper.net …
The following Last Call announcement was sent out (ends 2022-02-03):

From: The IESG
To: IETF-Announce
CC: draft-ietf-teas-gmpls-signaling-smp@ietf.org, jgs@juniper.net, teas-chairs@ietf.org, teas@ietf.org, vbeeram@juniper.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (GMPLS Signaling Extensions for Shared Mesh Protection) to Proposed Standard


The IESG has received a request from the Traffic Engineering Architecture and
Signaling WG (teas) to consider the following document: - 'GMPLS Signaling
Extensions for Shared Mesh Protection'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-02-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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
  Profile (MPLS-TP) network.

  This document updates RFC 4872 and RFC 4873 to provide the extensions
  to the Generalized Multi-Protocol Label Switching (GMPLS) signaling
  to support the control of the SMP.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-signaling-smp/



No IPR declarations have been submitted directly on this I-D.




2022-01-20
10 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2022-01-20
10 John Scudder Last call was requested
2022-01-20
10 John Scudder Last call announcement was generated
2022-01-20
10 John Scudder Ballot approval text was generated
2022-01-20
10 John Scudder Ballot writeup was generated
2022-01-20
10 John Scudder IESG state changed to Last Call Requested from AD Evaluation
2022-01-16
10 Jeong-dong Ryoo New version available: draft-ietf-teas-gmpls-signaling-smp-10.txt
2022-01-16
10 (System) New version approved
2022-01-16
10 (System) Request for posting confirmation emailed to previous authors: Bin-Yeong Yoon , He Jia , Italo Busi , Jeong-dong Ryoo , Peter Park
2022-01-16
10 Jeong-dong Ryoo Uploaded new revision
2022-01-13
09 Jeong-dong Ryoo New version available: draft-ietf-teas-gmpls-signaling-smp-09.txt
2022-01-13
09 (System) New version approved
2022-01-13
09 (System) Request for posting confirmation emailed to previous authors: Bin-Yeong Yoon , He Jia , Italo Busi , Jeong-dong Ryoo , Peter Park
2022-01-13
09 Jeong-dong Ryoo Uploaded new revision
2022-01-04
08 (System) Changed action holders to John Scudder (IESG state changed)
2022-01-04
08 John Scudder IESG state changed to AD Evaluation from Publication Requested
2021-10-17
08 Jeong-dong Ryoo New version available: draft-ietf-teas-gmpls-signaling-smp-08.txt
2021-10-17
08 (System) New version approved
2021-10-17
08 (System) Request for posting confirmation emailed to previous authors: Bin-Yeong Yoon , He Jia , Italo Busi , Jeong-dong Ryoo , Peter Park
2021-10-17
08 Jeong-dong Ryoo Uploaded new revision
2021-10-08
07 Ines Robles Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Ines Robles. Sent review to list.
2021-09-23
07 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Ines Robles
2021-09-23
07 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Ines Robles
2021-09-23
07 Luc André Burdet Assignment of request for Last Call review by RTGDIR to Jon Mitchell was marked no-response
2021-08-13
07 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Jon Mitchell
2021-08-13
07 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Jon Mitchell
2021-08-10
07 John Scudder Requested Last Call review by RTGDIR
2021-06-16
07 Vishnu Beeram
> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up. Changes are expected over time.

> This …
> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up. Changes are expected over time.

> This version is dated 1 November 2019.

> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Standards Track

> Why is this the proper type of RFC?

The document defines RSVP related formats and behaviors.

> Is this type of RFC indicated in the title page header?

Yes

> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary:
>
> Relevant content can frequently be found in the abstract and/or
> introduction of the document. If not, this may be an indication that
> there are deficiencies in the abstract or introduction.

  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
  Profile (MPLS-TP) network.

  This document updates RFC 4872 to provide the extensions to the
  Generalized Multi-Protocol Label Switching (GMPLS) signaling to
  support the control of the SMP.

> Working Group Summary:
>
> Was there anything in WG process that is worth noting? For example, was
> there controversy about particular points or were there decisions where
> the consensus was particularly rough?

There was notable debate on how pre-emption is handled in the Shared
Mesh Protection signaling procedures. The authors addressed all of these
concerns by adding relevant text to the document.


> Document Quality:
>
> Are there existing implementations of the protocol? Have a significant
> number of vendors indicated their plan to implement the specification?
> Are there any reviewers that merit special mention as having done a
> thorough review, e.g., one that resulted in important changes or a
> conclusion that the document had no substantive issues? If there was a
> MIB Doctor, YANG Doctor, Media Type or other expert review, what was its
> course (briefly)? In the case of a Media Type review, on what date was
> the request posted?

The document has been discussed and reviewed thoroughly by the WG. While
there have been no official statements on implementation of this
new framework, some of the authors are from a vendor, and implementation
is expected.

> Personnel:
>
>  Who is the Document Shepherd?
Vishnu Pavan Beeram

> Who is the Responsible Area Director?
John Scudder

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd. If this version of the document is not ready for
> publication, please explain why the document is being forwarded to the
> IESG.

The Document Shepherd has reviewed the document as part of normal WG progress
and WG last call. The Shepherd believes this document is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No. 

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that took
> place.

No.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No specific concerns.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why?

Yes, see:
Pre-WGLC: https://mailarchive.ietf.org/arch/msg/teas/xlUivOQ7W6UwjOqlOvZwF1onqH4/
Pre-Adoption: https://mailarchive.ietf.org/arch/msg/teas/HmnoD_NCcFDBgdt7Xs1WJbK6rc8/


> (8) Has an IPR disclosure been filed that references this document? If
> so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

No IPR disclosed.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others being
> silent, or does the WG as a whole understand and agree with it?

Solid among those who are interested. “Strong concurrence of a fair number
of individuals, with others being silent" is a reasonable
characterization.


> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)

No discontent seen.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

The document passes ID nits.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
> reviews.

N/A.

> (13) Have all references within this document been identified as either
> normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

No.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

No.

> (16) Will publication of this document change the status of any existing
> RFCs? Are those RFCs listed on the title page header, listed in the
> abstract, and discussed in the introduction? If the RFCs are not listed
> in the Abstract and Introduction, explain why, and point to the part of
> the document where the relationship of this document to the other RFCs
> is discussed. If this information is not in the document, explain why
> the WG considers it unnecessary.

Yes. This document updates RFC 4872. RFC 4872 is listed on the title page
header, listed in the abstract, and discussed in the introduction.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA
> registries. Confirm that any referenced IANA registries have been
> clearly identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 8126).

The IANA section was fully reviewed by the document shepherd. All protocol
extensions that the document makes are associated with the appropriate
reservations in IANA registries.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find useful
> in selecting the IANA Experts for these new registries.

None.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, YANG modules,
> etc.

N/A

> (20) If the document contains a YANG module, has the module been checked
> with any of the recommended validation tools
> (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
> formatting validation? If there are any resulting errors or warnings,
> what is the justification for not fixing them at this time? Does the
> YANG module comply with the Network Management Datastore Architecture
> (NMDA) as specified in RFC8342?

There are no yang modules in this document.
2021-06-16
07 Vishnu Beeram Responsible AD changed to John Scudder
2021-06-16
07 Vishnu Beeram IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2021-06-16
07 Vishnu Beeram IESG state changed to Publication Requested from I-D Exists
2021-06-16
07 Vishnu Beeram IESG process started in state Publication Requested
2021-06-16
07 Vishnu Beeram Changed consensus to Yes from Unknown
2021-06-16
07 Vishnu Beeram The document defines RSVP protocol related formats and behaviors.
2021-06-16
07 Vishnu Beeram Intended Status changed to Proposed Standard from None
2021-06-16
07 Vishnu Beeram
> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up. Changes are expected over time.

> This …
> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up. Changes are expected over time.

> This version is dated 1 November 2019.

> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Standards Track

> Why is this the proper type of RFC?

The document defines RSVP related formats and behaviors.

> Is this type of RFC indicated in the title page header?

Yes

> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary:
>
> Relevant content can frequently be found in the abstract and/or
> introduction of the document. If not, this may be an indication that
> there are deficiencies in the abstract or introduction.

  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
  Profile (MPLS-TP) network.

  This document updates RFC 4872 to provide the extensions to the
  Generalized Multi-Protocol Label Switching (GMPLS) signaling to
  support the control of the SMP.

> Working Group Summary:
>
> Was there anything in WG process that is worth noting? For example, was
> there controversy about particular points or were there decisions where
> the consensus was particularly rough?

There was notable debate on how pre-emption is handled in the Shared
Mesh Protection signaling procedures. The authors addressed all of these
concerns by adding relevant text to the document.


> Document Quality:
>
> Are there existing implementations of the protocol? Have a significant
> number of vendors indicated their plan to implement the specification?
> Are there any reviewers that merit special mention as having done a
> thorough review, e.g., one that resulted in important changes or a
> conclusion that the document had no substantive issues? If there was a
> MIB Doctor, YANG Doctor, Media Type or other expert review, what was its
> course (briefly)? In the case of a Media Type review, on what date was
> the request posted?

The document has been discussed and reviewed thoroughly by the WG. While
there have been no official statements on implementation of this
new framework, some of the authors are from a vendor, and implementation
is expected.

> Personnel:
>
>  Who is the Document Shepherd?
Vishnu Pavan Beeram

> Who is the Responsible Area Director?
John Scudder

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd. If this version of the document is not ready for
> publication, please explain why the document is being forwarded to the
> IESG.

The Document Shepherd has reviewed the document as part of normal WG progress
and WG last call. The Shepherd believes this document is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No. 

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that took
> place.

No.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No specific concerns.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why?

Yes, see:
Pre-WGLC: https://mailarchive.ietf.org/arch/msg/teas/xlUivOQ7W6UwjOqlOvZwF1onqH4/
Pre-Adoption: https://mailarchive.ietf.org/arch/msg/teas/HmnoD_NCcFDBgdt7Xs1WJbK6rc8/


> (8) Has an IPR disclosure been filed that references this document? If
> so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

No IPR disclosed.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others being
> silent, or does the WG as a whole understand and agree with it?

Solid among those who are interested. “Strong concurrence of a fair number
of individuals, with others being silent" is a reasonable
characterization.


> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)

No discontent seen.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

The document passes ID nits.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
> reviews.

N/A.

> (13) Have all references within this document been identified as either
> normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

No.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

No.

> (16) Will publication of this document change the status of any existing
> RFCs? Are those RFCs listed on the title page header, listed in the
> abstract, and discussed in the introduction? If the RFCs are not listed
> in the Abstract and Introduction, explain why, and point to the part of
> the document where the relationship of this document to the other RFCs
> is discussed. If this information is not in the document, explain why
> the WG considers it unnecessary.

Yes. This document updates RFC 4872. RFC 4872 is listed on the title page
header, listed in the abstract, and discussed in the introduction.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA
> registries. Confirm that any referenced IANA registries have been
> clearly identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 8126).

The IANA section was fully reviewed by the document shepherd. All protocol
extensions that the document makes are associated with the appropriate
reservations in IANA registries.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find useful
> in selecting the IANA Experts for these new registries.

None.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, YANG modules,
> etc.

N/A

> (20) If the document contains a YANG module, has the module been checked
> with any of the recommended validation tools
> (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
> formatting validation? If there are any resulting errors or warnings,
> what is the justification for not fixing them at this time? Does the
> YANG module comply with the Network Management Datastore Architecture
> (NMDA) as specified in RFC8342?

There are no yang modules in this document.
2021-06-16
07 Vishnu Beeram Notification list changed to vbeeram@juniper.net because the document shepherd was set
2021-06-16
07 Vishnu Beeram Document shepherd changed to Vishnu Pavan Beeram
2021-06-16
07 Jeong-dong Ryoo New version available: draft-ietf-teas-gmpls-signaling-smp-07.txt
2021-06-16
07 (System) New version approved
2021-06-16
07 (System) Request for posting confirmation emailed to previous authors: Bin-Yeong Yoon , He Jia , Italo Busi , Jeong-dong Ryoo , Peter Park
2021-06-16
07 Jeong-dong Ryoo Uploaded new revision
2021-04-24
06 Jeong-dong Ryoo New version available: draft-ietf-teas-gmpls-signaling-smp-06.txt
2021-04-24
06 (System) New version approved
2021-04-24
06 (System) Request for posting confirmation emailed to previous authors: Bin-Yeong Yoon , He Jia , Italo Busi , Jeong-dong Ryoo , Peter Park
2021-04-24
06 Jeong-dong Ryoo Uploaded new revision
2021-02-19
05 Vishnu Beeram IETF WG state changed to In WG Last Call from WG Document
2021-02-18
05 Vishnu Beeram Pre WGLC IPR Poll

hejia@huawei.com
https://mailarchive.ietf.org/arch/msg/teas/FFK5KLjr5PBn_haGDJ85B-n36HU/

Italo Busi
https://mailarchive.ietf.org/arch/msg/teas/voiEugaEiUjnvVMFRY8AbZABmeA/

ryoo@etri.re.kr
https://mailarchive.ietf.org/arch/msg/teas/nFgC2tp6NyK_OQUAmdB-RUSfB3Y/

byyun@etri.re.kr
https://mailarchive.ietf.org/arch/msg/teas/3ovHNG0iZveJQ0semwkB3ITGDDc/

peter.park@kt.com
https://mailarchive.ietf.org/arch/msg/teas/GHPOErNI7vqv_nOumMNGRyHP7S8/

tochio@fujitsu.com
https://mailarchive.ietf.org/arch/msg/teas/-OdUBi4u19dLqPp-boiIuhCLm3I/
2021-01-14
05 Jeong-dong Ryoo New version available: draft-ietf-teas-gmpls-signaling-smp-05.txt
2021-01-14
05 (System) New version approved
2021-01-14
05 (System) Request for posting confirmation emailed to previous authors: Bin-Yeong Yoon , He Jia , Italo Busi , Jeong-dong Ryoo , Peter Park
2021-01-14
05 Jeong-dong Ryoo Uploaded new revision
2020-09-08
04 Jeong-dong Ryoo New version available: draft-ietf-teas-gmpls-signaling-smp-04.txt
2020-09-08
04 (System) New version approved
2020-09-08
04 (System) Request for posting confirmation emailed to previous authors: He Jia , Bin-Yeong Yoon , Jeong-dong Ryoo , Peter Park , Italo Busi
2020-09-08
04 Jeong-dong Ryoo Uploaded new revision
2020-03-08
03 Jeong-dong Ryoo New version available: draft-ietf-teas-gmpls-signaling-smp-03.txt
2020-03-08
03 (System) New version approved
2020-03-08
03 (System) Request for posting confirmation emailed to previous authors: Italo Busi , Bin-Yeong Yoon , He Jia , Jeong-dong Ryoo , Peter Park
2020-03-08
03 Jeong-dong Ryoo Uploaded new revision
2020-01-07
02 Jeong-dong Ryoo New version available: draft-ietf-teas-gmpls-signaling-smp-02.txt
2020-01-07
02 (System) New version approved
2020-01-07
02 (System) Request for posting confirmation emailed to previous authors: Italo Busi , Peter Park , He Jia , Bin-Yeong Yoon , Jeong-dong Ryoo
2020-01-07
02 Jeong-dong Ryoo Uploaded new revision
2020-01-06
01 (System) Document has expired
2019-07-05
01 Jeong-dong Ryoo New version available: draft-ietf-teas-gmpls-signaling-smp-01.txt
2019-07-05
01 (System) New version approved
2019-07-05
01 (System) Request for posting confirmation emailed to previous authors: Italo Busi , teas-chairs@ietf.org, He Jia
2019-07-05
01 Jeong-dong Ryoo Uploaded new revision
2019-01-15
00 Vishnu Beeram This document now replaces draft-he-teas-gmpls-signaling-smp instead of None
2019-01-15
00 Italo Busi New version available: draft-ietf-teas-gmpls-signaling-smp-00.txt
2019-01-15
00 (System) WG -00 approved
2019-01-14
00 Italo Busi Set submitter to "Italo Busi ", replaces to (none) and sent approval email to group chairs: teas-chairs@ietf.org
2019-01-14
00 Italo Busi Uploaded new revision