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<mailto:marina.fizg...@gmail.com>
marina.fizg...@ecitele.com<mailto: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<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] PCE segment routing extension

[Alexander Vainshtein]

Hi all,
A minor comment:
I think that the first label in this  discussion could be a label from the SRLB 
as well as from SRGB. Actually, any label that represents a known local SID of 
the PCC can do.

And I fully agree tthat this should be aligned across PCEP/BGP/NETCONF.

My 2c,

Thumb typed by Sasha Vainshtein


From: Jonathan Hardwick 
Sent: Wednesday, August 15, 2018 8:00:36 PM
To: Michael Gorokhovsky; Marina Fizgeer; Dhruv Dhody
Cc: pce@ietf.org; Siva Sivabalan (msiva); Clarence Filsfils (cfilsfil); Jeff 
Tantsura; wim.henderi...@alcatel-lucent.com; Alexander Vainshtein; Alexander 
Ferdman; Ron Sdayoor; Dhruv Dhody
Subject: RE: [Pce] PCE segment routing extension

Michael, Marina,

To check I understand – you are proposing that the first label is a label from 
the PCC’s own SRGB and is not actually pushed, but is instead used locally by 
the PCC to identify the next hop?  That could work, and in particular I think 
it works well for binding labels.  I discussed this possibility with Dhruv at 
the last IETF meeting, but without conclusion.

As Dhruv points out in his review, this is not just a PCEP specific question.  
We should make sure that the interpretation is aligned across PCEP / BGP and 
netconf / YANG.

Cheers
Jon


From: Michael Gorokhovsky [mailto:michael.gorokhov...@ecitele.com]
Sent: Wednesday, August 15, 2018 5:33 PM
To: Jonathan Hardwick ; Marina Fizgeer 
; Dhruv Dhody 
Cc: pce@ietf.org; Siva Sivabalan (msiva) ; Clarence Filsfils 
(cfilsfil) ; Jeff Tantsura ; 
wim.henderi...@alcatel-lucent.com; Alexander Vainshtein 
; Alexander Ferdman 
; Ron Sdayoor ; Dhruv 
Dhody 
Subject: RE: [Pce] PCE segment routing extension

Hi Jon & all,

I concur with Marina here. Let us take your example with first label in SR-ERO 
list as L1. We have the following options here :

  1.  The label is associated with Prefix SID
  2.  The label is associated with adjacency SID
  3.  The label is associated with binding SID

In all of these cases first label shall be handled locally and differently in 
order to find the  next hop.
For example for adjacency segment the first label shall be not pushed and next 
hop of adjacency shall be used
For binding SID the first label shall be replaced with bound policy label stack.
The same approach from my POV shall be used for first label that is associated 
with prefix SID.  it shall be known locally for PCC and to be used to find 
actual next hop (or next hops with remote SRGBs) to destination SID. It may be 
done if first label (L1) allocated from local SRGB.

Regards, Michael

From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Wednesday, August 15, 2018 7:03 PM
To: Marina Fizgeer 
mailto:marina.fizg...@ecitele.com>>; Dhruv Dhody 
mailto:dhruv.i...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) 
mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) 
mailto:cfils...@cisco.com>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele..com>>; 
Alexander Ferdman 
mailto:alexander.ferd...@ecitele.com>>; Ron 
Sdayoor mailto:ron.sday...@ecitele.com>>; Dhruv Dhody 
mailto:dhruv.dh...@huawei.com>>
Subject: RE: [Pce] PCE segment routing extension

Hi Marina

Say that the first label in the SR-ERO is L1.  Then the PCE is instructing the 
PCC to push a stack of labels onto each packet that uses this LSP, where the 
outermost label is L1.  How does the PCC know which next hop to send the 
labelled packet to?  L1 does not identify the next hop; L1 is a label taken 
from the SRGB of the next hop.

If we assumed that all nodes use the same SRGB, then I agree, the PCC could 
look up L1 in its SRGB and work out what it refers to.  But we can’t assume 
that all nodes have the same SRGB.  Label L1 might not even be in the PCC’s 
SRGB.

Cheers
Jon


From: Marina Fizgeer [mailto:marina.fizg...@ecitele.com]
Sent: Wednesday, August 15, 2018 4:38 PM
To: Jonathan Hardwick 
mailto:jonathan.hardw...@metaswitch.com>>; 
Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) 
mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) 
mailto:cfils...@cisco.com>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele..com>>; 
Alexander Ferdman 
mailto:alexander.ferd...@ecitele.com>>; Ron 
Sdayoor mailto:ron.sday...@ecitele.com>>; Dhruv Dhody 
mailto:dhruv.dh...@huawei.com>>
Subject: RE: [Pce] PCE segment routing extension

Hi, Jonathan and Dhruv

Re: [Pce] PCE segment routing extension

[Jonathan Hardwick]

Michael, Marina,

To check I understand – you are proposing that the first label is a label from 
the PCC’s own SRGB and is not actually pushed, but is instead used locally by 
the PCC to identify the next hop?  That could work, and in particular I think 
it works well for binding labels.  I discussed this possibility with Dhruv at 
the last IETF meeting, but without conclusion.

As Dhruv points out in his review, this is not just a PCEP specific question.  
We should make sure that the interpretation is aligned across PCEP / BGP and 
netconf / YANG.

Cheers
Jon


From: Michael Gorokhovsky [mailto:michael.gorokhov...@ecitele.com]
Sent: Wednesday, August 15, 2018 5:33 PM
To: Jonathan Hardwick ; Marina Fizgeer 
; Dhruv Dhody 
Cc: pce@ietf.org; Siva Sivabalan (msiva) ; Clarence Filsfils 
(cfilsfil) ; Jeff Tantsura ; 
wim.henderi...@alcatel-lucent.com; Alexander Vainshtein 
; Alexander Ferdman 
; Ron Sdayoor ; Dhruv 
Dhody 
Subject: RE: [Pce] PCE segment routing extension

Hi Jon & all,

I concur with Marina here. Let us take your example with first label in SR-ERO 
list as L1. We have the following options here :

  1.  The label is associated with Prefix SID
  2.  The label is associated with adjacency SID
  3.  The label is associated with binding SID

In all of these cases first label shall be handled locally and differently in 
order to find the  next hop.
For example for adjacency segment the first label shall be not pushed and next 
hop of adjacency shall be used
For binding SID the first label shall be replaced with bound policy label stack.
The same approach from my POV shall be used for first label that is associated 
with prefix SID.  it shall be known locally for PCC and to be used to find 
actual next hop (or next hops with remote SRGBs) to destination SID. It may be 
done if first label (L1) allocated from local SRGB.

Regards, Michael

From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Wednesday, August 15, 2018 7:03 PM
To: Marina Fizgeer 
mailto:marina.fizg...@ecitele.com>>; Dhruv Dhody 
mailto:dhruv.i...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) 
mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) 
mailto:cfils...@cisco.com>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
Alexander Ferdman 
mailto:alexander.ferd...@ecitele.com>>; Ron 
Sdayoor mailto:ron.sday...@ecitele.com>>; Dhruv Dhody 
mailto:dhruv.dh...@huawei.com>>
Subject: RE: [Pce] PCE segment routing extension

Hi Marina

Say that the first label in the SR-ERO is L1.  Then the PCE is instructing the 
PCC to push a stack of labels onto each packet that uses this LSP, where the 
outermost label is L1.  How does the PCC know which next hop to send the 
labelled packet to?  L1 does not identify the next hop; L1 is a label taken 
from the SRGB of the next hop.

If we assumed that all nodes use the same SRGB, then I agree, the PCC could 
look up L1 in its SRGB and work out what it refers to.  But we can’t assume 
that all nodes have the same SRGB.  Label L1 might not even be in the PCC’s 
SRGB.

Cheers
Jon


From: Marina Fizgeer [mailto:marina.fizg...@ecitele.com]
Sent: Wednesday, August 15, 2018 4:38 PM
To: Jonathan Hardwick 
mailto:jonathan.hardw...@metaswitch.com>>; 
Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) 
mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) 
mailto:cfils...@cisco.com>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
Alexander Ferdman 
mailto:alexander.ferd...@ecitele.com>>; Ron 
Sdayoor mailto:ron.sday...@ecitele.com>>; Dhruv Dhody 
mailto:dhruv.dh...@huawei.com>>
Subject: RE: [Pce] PCE segment routing extension

Hi, Jonathan and Dhruv
Thank you for reply.

Please, see in line

Best regards,

Marina

From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Wednesday, August 15, 2018 6:17 PM
To: Dhruv Dhody mailto:dhruv.i...@gmail.com>>; Marina 
Fizgeer mailto:marina.fizg...@ecitele.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) 
mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) 
mailto:cfils...@cisco.com>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@e

Re: [Pce] PCE segment routing extension

[Jonathan Hardwick]

Hi Marina

Say that the first label in the SR-ERO is L1.  Then the PCE is instructing the 
PCC to push a stack of labels onto each packet that uses this LSP, where the 
outermost label is L1.  How does the PCC know which next hop to send the 
labelled packet to?  L1 does not identify the next hop; L1 is a label taken 
from the SRGB of the next hop.

If we assumed that all nodes use the same SRGB, then I agree, the PCC could 
look up L1 in its SRGB and work out what it refers to.  But we can’t assume 
that all nodes have the same SRGB.  Label L1 might not even be in the PCC’s 
SRGB.

Cheers
Jon


From: Marina Fizgeer [mailto:marina.fizg...@ecitele.com]
Sent: Wednesday, August 15, 2018 4:38 PM
To: Jonathan Hardwick ; Dhruv Dhody 

Cc: pce@ietf.org; Siva Sivabalan (msiva) ; Clarence Filsfils 
(cfilsfil) ; Jeff Tantsura ; 
wim.henderi...@alcatel-lucent.com; Michael Gorokhovsky 
; Alexander Vainshtein 
; Alexander Ferdman 
; Ron Sdayoor ; Dhruv 
Dhody 
Subject: RE: [Pce] PCE segment routing extension

Hi, Jonathan and Dhruv
Thank you for reply.

Please, see in line

Best regards,

Marina

From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Wednesday, August 15, 2018 6:17 PM
To: Dhruv Dhody mailto:dhruv.i...@gmail.com>>; Marina 
Fizgeer mailto:marina.fizg...@ecitele.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) 
mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) 
mailto:cfils...@cisco.com>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
Alexander Ferdman 
mailto:alexander.ferd...@ecitele.com>>; Ron 
Sdayoor mailto:ron.sday...@ecitele.com>>; Dhruv Dhody 
mailto:dhruv.dh...@huawei.com>>
Subject: RE: [Pce] PCE segment routing extension

Marina, Dhruv,

Please see below.

Cheers
Jon

From: Dhruv Dhody [mailto:dhruv.i...@gmail.com]
Sent: Wednesday, August 15, 2018 2:59 PM
To: Marina Fizgeer 
mailto:marina.fizg...@ecitele.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) 
mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) 
mailto:cfils...@cisco.com>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
Jonathan Hardwick 
mailto:jonathan.hardw...@metaswitch.com>>; 
Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
Alexander Ferdman 
mailto:alexander.ferd...@ecitele.com>>; 
ron.sday...@ecitele.com<mailto:ron.sday...@ecitele.com>; Dhruv Dhody 
mailto:dhruv.dh...@huawei.com>>
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.

[Jon] The difficulty is knowing which label space the first SR-ERO label comes 
from.  If it is a label from the PCC’s own SRGB then it can be used to infer 
the next hop.  If it is a label from the first downstream router’s SRGB, then 
the PCC needs more information to determine the next hop.  The draft currently 
assumes the latter.
[MF: ] Actually the next hop resolution for Node (prefix) SID can be performed 
in PCC only, for example, ECMP or LFA use cases, where there are multiple next 
hops. So, PCE shall send label in SRGB range of PCC, otherwise PCC cannot 
resolve it even though NAI is presented

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 

Re: [Pce] PCE segment routing extension

[Marina Fizgeer]

Hi, Jonathan and Dhruv
Thank you for reply.

Please, see in line

Best regards,

Marina

From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Wednesday, August 15, 2018 6:17 PM
To: Dhruv Dhody ; Marina Fizgeer 

Cc: pce@ietf.org; Siva Sivabalan (msiva) ; Clarence Filsfils 
(cfilsfil) ; Jeff Tantsura ; 
wim.henderi...@alcatel-lucent.com; Michael Gorokhovsky 
; Alexander Vainshtein 
; Alexander Ferdman 
; Ron Sdayoor ; Dhruv 
Dhody 
Subject: RE: [Pce] PCE segment routing extension

Marina, Dhruv,

Please see below.

Cheers
Jon

From: Dhruv Dhody [mailto:dhruv.i...@gmail.com]
Sent: Wednesday, August 15, 2018 2:59 PM
To: Marina Fizgeer 
mailto:marina.fizg...@ecitele.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) 
mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) 
mailto:cfils...@cisco.com>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
Jonathan Hardwick 
mailto:jonathan.hardw...@metaswitch.com>>; 
Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
Alexander Ferdman 
mailto:alexander.ferd...@ecitele.com>>; 
ron.sday...@ecitele.com<mailto:ron.sday...@ecitele.com>; Dhruv Dhody 
mailto:dhruv.dh...@huawei.com>>
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.

[Jon] The difficulty is knowing which label space the first SR-ERO label comes 
from.  If it is a label from the PCC’s own SRGB then it can be used to infer 
the next hop.  If it is a label from the first downstream router’s SRGB, then 
the PCC needs more information to determine the next hop.  The draft currently 
assumes the latter.
[MF: ] Actually the next hop resolution for Node (prefix) SID can be performed 
in PCC only, for example, ECMP or LFA use cases, where there are multiple next 
hops. So, PCE shall send label in SRGB range of PCC, otherwise PCC cannot 
resolve it even though NAI is presented

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!

[Jon] I agree that this clarification should be added.

Thanks!
Dhruv



Best regards,

Marina Fizgeer
Email: marina.fizg...@gmail.com<mailto:marina.fizg...@gmail.com>
marina.fizg...@ecitele.com<mailto: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<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce

___

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.

Re: [Pce] PCE segment routing extension

[Jonathan Hardwick]

Marina, Dhruv,

Please see below.

Cheers
Jon

From: Dhruv Dhody [mailto:dhruv.i...@gmail.com]
Sent: Wednesday, August 15, 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.

[Jon] The difficulty is knowing which label space the first SR-ERO label comes 
from.  If it is a label from the PCC’s own SRGB then it can be used to infer 
the next hop.  If it is a label from the first downstream router’s SRGB, then 
the PCC needs more information to determine the next hop.  The draft currently 
assumes the latter.

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!

[Jon] I agree that this clarification should be added.

Thanks!
Dhruv



Best regards,

Marina Fizgeer
Email: marina.fizg...@gmail.com<mailto:marina.fizg...@gmail.com>
marina.fizg...@ecitele.com<mailto: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<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] PCE segment routing extension

[Dhruv Dhody]

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 
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] PCE segment routing extension

[Marina Fizgeer]

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.

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?

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