[Pce] FW: New Version Notification for draft-ietf-pce-segment-routing-13.txt

[Jonathan Hardwick]

This revision addresses the recent comments from the shepherd review and the 
2nd WGLC.
I believe that this is now ready for the IESG.  Dhruv - please check you are 
happy with it.

Thanks
Jon

-Original Message-
From: internet-dra...@ietf.org  
Sent: Friday, 12 October, 2018 5:47 PM
To: Wim Henderickx ; Siva Sivabalan 
; Jonathan Hardwick ; 
Jonathan Hardwick ; Jeff Tantsura 
; Clarence Filsfils 
Subject: New Version Notification for draft-ietf-pce-segment-routing-13.txt


A new version of I-D, draft-ietf-pce-segment-routing-13.txt
has been successfully submitted by Jon Hardwick and posted to the IETF 
repository.

Name:   draft-ietf-pce-segment-routing
Revision:   13
Title:  PCEP Extensions for Segment Routing
Document date:  2018-10-12
Group:  pce
Pages:  31
URL:
https://www.ietf.org/internet-drafts/draft-ietf-pce-segment-routing-13.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/
Htmlized:   https://tools.ietf.org/html/draft-ietf-pce-segment-routing-13
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-13

Abstract:
   Segment Routing (SR) enables any head-end node to select any path
   without relying on a hop-by-hop signaling technique (e.g., LDP or
   RSVP-TE).  It depends only on "segments" that are advertised by Link-
   State Interior Gateway Protocols (IGPs).  A Segment Routed Path can
   be derived from a variety of mechanisms, including an IGP Shortest
   Path Tree (SPT), explicit configuration, or a Path Computation
   Element (PCE).  This document specifies extensions to the Path
   Computation Element Communication Protocol (PCEP) that allow a
   stateful PCE to compute and initiate Traffic Engineering (TE) paths,
   as well as a PCC to request a path subject to certain constraints and
   optimization criteria in SR networks.



  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] PCE segment routing extension

[Jonathan Hardwick]

Dhruv, Marina,

In the new revision of the PCE segment routing draft (which I am about to 
submit) I have addressed comment (2) below by adding this text.

In section 6.2.1:
“If an ERO specifies a new SR-TE path for an existing LSP and the PCC 
determines that the ERO contains SR-ERO subobjects that are not valid, then the 
PCC MUST NOT update the LSP.”

In section 6.2.2.1:
“If an ERO specifies a new SR-TE path for an existing LSP and the PCC 
encounters an error while processing the ERO, then the PCC MUST NOT update the 
LSP.”

Thanks
Jon

From: Dhruv Dhody 
Sent: Wednesday, 15 August, 2018 2:59 PM
To: Marina Fizgeer 
Cc: pce@ietf.org; Siva Sivabalan (msiva) ; Clarence Filsfils 
(cfilsfil) ; Jeff Tantsura ; 
wim.henderi...@alcatel-lucent.com; Jonathan Hardwick 
; Michael Gorokhovsky 
; Alexander Vainshtein 
; Alexander Ferdman 
; ron.sday...@ecitele.com; Dhruv Dhody 

Subject: Re: [Pce] PCE segment routing extension

Hi Marina,

I am the document shephered [1] for this I-D. I am working with the authors in 
the final stages towards RFC publication. Please see inline for my response.

Thanks!
Dhruv

[1] https://mailarchive.ietf.org/arch/msg/pce/38-FbYFEE33bTP6-yUXkKKGN8xw


On Wed, Aug 15, 2018 at 5:22 PM Marina Fizgeer 
mailto:marina.fizg...@ecitele.com>> wrote:
Dear authors of draft-ietf-pce-segment-routing-12,

My colleagues and I are interested in some clarifications:

1.   In section 6.2.1 “If the first SR-ERO represents an MPLS label value 
then the NAI field MUST NOT be absent…”

In case of binding SID as first SR-ERO, it can be MPLS label only, without NAI.
[Dhruv]: I am working with the authors in removing the restriction, you will 
find my rationale in [1].
But also note that while preparing MPLS label stack at PCE, this label stack 
should be from the POV of the ingress PCC.

2.   This draft defines the new error codes related to SR-ERO conversion, 
that were not defined in previous version.
What is expected behavior of PCC in additional to sending error message.

For example:

In case PCUpd for PCE initiated LSP, PCE sends new SR-ERO objects to PCC. PCC 
shall validate and interpret the SR-ERO EROs.

If SR-EROs cannot be converted to an MPLS label stack and a next hop, PCC shall 
send PCErr message with Error-Type “Reception of an invalid object”.

What is expected handling of new SR-EROs in updating LSP – LSP shall stay with 
old SR-ERO objects or with new ones, but in down state?
[Dhruv]: I agree that this should be clearly stated. Keeping the principle of 
make before break, staying on wil old SR path makes sense!

Thanks!
Dhruv



Best regards,

Marina Fizgeer
Email: marina.fizg...@gmail.com
marina.fizg...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] I-D Action: draft-ietf-pce-segment-routing-13.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

Title   : PCEP Extensions for Segment Routing
Authors : Siva Sivabalan
  Clarence Filsfils
  Jeff Tantsura
  Wim Henderickx
  Jon Hardwick
Filename: draft-ietf-pce-segment-routing-13.txt
Pages   : 31
Date: 2018-10-12

Abstract:
   Segment Routing (SR) enables any head-end node to select any path
   without relying on a hop-by-hop signaling technique (e.g., LDP or
   RSVP-TE).  It depends only on "segments" that are advertised by Link-
   State Interior Gateway Protocols (IGPs).  A Segment Routed Path can
   be derived from a variety of mechanisms, including an IGP Shortest
   Path Tree (SPT), explicit configuration, or a Path Computation
   Element (PCE).  This document specifies extensions to the Path
   Computation Element Communication Protocol (PCEP) that allow a
   stateful PCE to compute and initiate Traffic Engineering (TE) paths,
   as well as a PCC to request a path subject to certain constraints and
   optimization criteria in SR networks.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-segment-routing-13
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce