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 <[email protected]>
Sent: Wednesday, August 15, 2018 8:00:36 PM
To: Michael Gorokhovsky; Marina Fizgeer; Dhruv Dhody
Cc: [email protected]; Siva Sivabalan (msiva); Clarence Filsfils (cfilsfil); Jeff
Tantsura; [email protected]; 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:[email protected]]
Sent: Wednesday, August 15, 2018 5:33 PM
To: Jonathan Hardwick <[email protected]>; Marina Fizgeer
<[email protected]>; Dhruv Dhody <[email protected]>
Cc: [email protected]; Siva Sivabalan (msiva) <[email protected]>; Clarence Filsfils
(cfilsfil) <[email protected]>; Jeff Tantsura <[email protected]>;
[email protected]; Alexander Vainshtein
<[email protected]>; Alexander Ferdman
<[email protected]>; Ron Sdayoor <[email protected]>; Dhruv
Dhody <[email protected]>
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:[email protected]]
Sent: Wednesday, August 15, 2018 7:03 PM
To: Marina Fizgeer
<[email protected]<mailto:[email protected]>>; Dhruv Dhody
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; Siva Sivabalan (msiva)
<[email protected]<mailto:[email protected]>>; Clarence Filsfils (cfilsfil)
<[email protected]<mailto:[email protected]>>; Jeff Tantsura
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
Michael Gorokhovsky
<[email protected]<mailto:[email protected]>>;
Alexander Vainshtein
<[email protected]<mailto:[email protected]>>;
Alexander Ferdman
<[email protected]<mailto:[email protected]>>; Ron
Sdayoor <[email protected]<mailto:[email protected]>>; Dhruv Dhody
<[email protected]<mailto:[email protected]>>
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:[email protected]]
Sent: Wednesday, August 15, 2018 4:38 PM
To: Jonathan Hardwick
<[email protected]<mailto:[email protected]>>;
Dhruv Dhody <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; Siva Sivabalan (msiva)
<[email protected]<mailto:[email protected]>>; Clarence Filsfils (cfilsfil)
<[email protected]<mailto:[email protected]>>; Jeff Tantsura
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
Michael Gorokhovsky
<[email protected]<mailto:[email protected]>>;
Alexander Vainshtein
<[email protected]<mailto:[email protected]>>;
Alexander Ferdman
<[email protected]<mailto:[email protected]>>; Ron
Sdayoor <[email protected]<mailto:[email protected]>>; Dhruv Dhody
<[email protected]<mailto:[email protected]>>
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:[email protected]]
Sent: Wednesday, August 15, 2018 6:17 PM
To: Dhruv Dhody <[email protected]<mailto:[email protected]>>; Marina
Fizgeer <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; Siva Sivabalan (msiva)
<[email protected]<mailto:[email protected]>>; Clarence Filsfils (cfilsfil)
<[email protected]<mailto:[email protected]>>; Jeff Tantsura
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
Michael Gorokhovsky
<[email protected]<mailto:[email protected]>>;
Alexander Vainshtein
<[email protected]<mailto:[email protected]>>;
Alexander Ferdman
<[email protected]<mailto:[email protected]>>; Ron
Sdayoor <[email protected]<mailto:[email protected]>>; Dhruv Dhody
<[email protected]<mailto:[email protected]>>
Subject: RE: [Pce] PCE segment routing extension
Marina, Dhruv,
Please see below.
Cheers
Jon
From: Dhruv Dhody [mailto:[email protected]]
Sent: Wednesday, August 15, 2018 2:59 PM
To: Marina Fizgeer
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; Siva Sivabalan (msiva)
<[email protected]<mailto:[email protected]>>; Clarence Filsfils (cfilsfil)
<[email protected]<mailto:[email protected]>>; Jeff Tantsura
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
Jonathan Hardwick
<[email protected]<mailto:[email protected]>>;
Michael Gorokhovsky
<[email protected]<mailto:[email protected]>>;
Alexander Vainshtein
<[email protected]<mailto:[email protected]>>;
Alexander Ferdman
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; Dhruv Dhody
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]>
[email protected]<mailto:[email protected]>
___________________________________________________________________________
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
[email protected]<mailto:[email protected]>
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.
___________________________________________________________________________
___________________________________________________________________________
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.
___________________________________________________________________________
___________________________________________________________________________
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
[email protected]
https://www.ietf.org/mailman/listinfo/pce
