Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.
draft-ietf-pce-binding-label-sid-16

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-pce-binding-label-sid@ietf.org, jgs@juniper.net, julien.meuric@orange.com, pce-chairs@ietf.org, pce@ietf.org, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.' to Proposed Standard (draft-ietf-pce-binding-label-sid-15.txt)

The IESG has approved the following document:
- 'Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.'
  (draft-ietf-pce-binding-label-sid-15.txt) as Proposed Standard

This document is the product of the Path Computation Element Working Group.

The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/

Ballot Text

Technical Summary:

   In order to provide greater scalability, network confidentiality, and service
   independence, Segment Routing (SR) utilizes a Binding Segment
   Identifier (BSID).  It is possible to associate a BSID to an RSVP-TE-
   signaled Traffic Engineering Label Switch Path or an SR Traffic
   Engineering path.  The BSID can be used by an upstream node for
   steering traffic into the appropriate TE path to enforce SR policies.
   This document specifies the binding value as an MPLS label or Segment
   Identifier.  It further specifies an approach for reporting binding
   label/SID by a Path Computation Client (PCC) to the Path Computation
   Element (PCE) to support PCE-based Traffic Engineering policies.

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?
- No

Document Quality:

Are there existing implementations of the protocol?
- Yes, 2 implementations are mentioned in the I-D.

Have a significant number of vendors indicated their plan to implement the specification?
- There are 4 different vendors among the authors.

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?
- Adrian Farrel did a careful review of the document and Olivier Dugeon suggested to add a flag which resulted in a more robust and consistent extension.
 
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?
- N/a

Personnel:

Who is the Document Shepherd?
- Julien Meuric

Who is the Responsible Area Director?
- John Scudder

RFC Editor Note