Olivier hi!
Lots of thanks for pointing to the PCEP-related draft.
I will look it up and, if necessary, will come back to you with more questions.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email protected]

From: spring [mailto:[email protected]] On Behalf Of Olivier Dugeon
Sent: Wednesday, July 18, 2018 2:34 PM
To: Alexander Vainshtein <[email protected]>; 
[email protected]
Cc: Michael Gorokhovsky <[email protected]>; Rotem Cohen 
<[email protected]>; '[email protected]' <[email protected]>; Shell Nakash 
<[email protected]>; Ron Sdayoor <[email protected]>
Subject: Re: [spring] Nesting of Path Segments


Hi,

May I suggest to read our draft 
https://tools.ietf.org/html/draft-dugeon-pce-stateful-interdomain-01

It provides a PCEP based solution suitable to setup end-to-end multi-domain 
Segment Path will keeping each domain independent and without the need for A to 
insert the complete stack. In addition, it allows to combine Segment Path and 
RSVP-TE tunnel, letting each domain enforces independently its local path with 
the technology it chosen. The counter part, is that each domain needs to deploy 
a PCE, but, for SR-TE is more or less essential.

Regards

Olivier

Le 18/07/2018 à 12:06, Alexander Vainshtein a écrit :
Dear all,
After sending my previous email I’ve noticed that label stacks in the diagram 
can be somewhat reduced if X-to-Y BSID would refer to combined X-to-Y path + 
X-to-Y Path SID and the same for Y-to-Z. The modified diagram is shown below. 
In addition to compression it also fixes a (Y-to-X Path SID added in the last 
stack).

However, even with the modified diagram, A would have to insert both A-to-Z 
Path SID and A-to-X Path SIDs in the stack, and Z would have to handle both 
Y-to-Z and A-to-Z Path SIDs on receive. (OAM packets for Y-to-Z path would not 
include A-to-Z Path SID, of course).

Such a scheme, if allowed, could be used, e.g., for monitoring packet loss (or 
delay) not just end-to-end but also on each separate sub-path.

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   
[email protected]<mailto:[email protected]>

From: Alexander Vainshtein
Sent: Wednesday, July 18, 2018 12:13 PM
To: 
'[email protected]<mailto:[email protected]>'
 
<[email protected]><mailto:[email protected]>
Cc: Shell Nakash <[email protected]><mailto:[email protected]>; 
Michael Gorokhovsky 
<[email protected]><mailto:[email protected]>; Ron 
Sdayoor ([email protected]<mailto:[email protected]>) 
<[email protected]><mailto:[email protected]>; Rotem Cohen 
([email protected]<mailto:[email protected]>) 
<[email protected]><mailto:[email protected]>; 
[email protected]<mailto:[email protected]>
Subject: Nesting of Path Segments

Dear authors of the Path Segment in 
SR-MPLS<https://tools.ietf.org/html/draft-cheng-spring-mpls-path-segment-02> 
draft,

My colleagues and I have a question about possibility of nesting of path 
segments in SR LSPs.

One relevant use case is shown in the embedded diagram below. It shows a 
network comprised of 3 domains and a bi-directional SR-TE path that crosses 
these domains and is comprised of bi-directional SR-TE LSPs in each of these 
domains.

[cid:[email protected]]

It is not clear to us whether such constructs are in our out of scope of the 
draft, because it states in Section 2.1:

   When Path Segment is used, a Path label MUST be inserted at the ingress node
   and MUST immediately follow the last label of the SR path.

This seems to suggest that only one Path label will be iserted by the ingress 
node.

Your timely feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   
[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.
___________________________________________________________________________




_______________________________________________

spring mailing list

[email protected]<mailto:[email protected]>

https://www.ietf.org/mailman/listinfo/spring


___________________________________________________________________________

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.
___________________________________________________________________________
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to