Subject: [Pce] SR Bidirectional Association (was RE: PCEP extensions for SR-TP)

From: Dhruv Dhody <[email-masked]>
Date: Wed, 29 Aug 2018 11:18:34 +0000

<Resending after trimming the CC list>

Hi All,

In case of RSVP-TE double sided bi-directional setup [1], we have –

                               +-----+
                               | PCE |
                               +-----+
   PCUpd/PCInitiate            /    \         PCUpd/PCInitiate
   Tunnel 1 (F)               /      \        Tunnel 2 (R)
   (LSP1 (F))                /        \       (LSP2 (R))
   Assoc#1                  /          \      Assoc#1
                           /            \
                          v              v
                     +-----+    LSP1     +-----+
                     |  S  |------------>|  D  | Via RSVP-TE
        Via RSVP-TE  |     |<------------|     | LSP1 (F)
        LSP2 (R)     +-----+    LSP2     +-----+

That is, the PCE creates the association and provisions at the both ends, the RSVP-TE does the rest of the work in signaling to the egress the status of the forward LSP (LSP1 (F)) and the ingress about the reverse LSP (LSP2 (R)).

Now in case of SR, where we don’t have signaling but to support the bi-directional use-case we want both ends of the bi-directional tunnel to be aware of the LSP in the other direction. In [2], we added “SR bidirectional double sided association” that is different from RSVP-TE case where we include the reverse direction LSP to the ingress and vice-versa via PCEP -

                               +-----+
                               | PCE |
                               +-----+
   PCUpd/PCInitiate            /    \         PCUpd/PCInitiate
   Tunnel 1 (F)               /      \        Tunnel 2 (R)
   (LSP1 (F), LSP2 (R))      /        \       (LSP2 (R), LSP1 (F))
   Assoc#1                  /          \      Assoc#1
                           /            \
                          v              v
                     +-----+    LSP1     +-----+
                     |  S  |------------>|  D  |
                     |     |<------------|     |
                     +-----+    LSP2     +-----+

                            <No Signaling>

The reasons to do this –

-       We want the egress to be aware of the “path segment label/SID” used by forward LSP and the ingress to be aware of reverse LSP. Without this information the solution breaks.

-       The control plane of the ingress and egress needs to be aware of the status of both directions to consider the bi-directional tunnel as up.

-       For diagnostics as well as Monitoring (directed BFD) it is important for the control plane of the node to be aware of the status/path of the both sides LSP.

-       [RFC7551] describes various operations for bi-directional RSVP-TE, such as associating existing unidirectional LSP into associated bidirectional where RSVP-TE used to signal and notify the status of the other direction LSP, the PCEP needs to bridge this gap in case of SR.

-       During protection switching we want both ends to do switching together as per [RFC6372]
It is interesting to note that if the PCE does not do this, then encoding of the association in PCEP and notifying it to the PCC is kind of useless.

Thanks!
Dhruv / Cheng

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-association-bidir/
[2] https://datatracker.ietf.org/doc/draft-li-pce-sr-bidir-path/

Dhruv Dhody
Lead Architect
Network Business Line
Huawei Technologies India Pvt. Ltd.
Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
Bengaluru, Karnataka - 560066
Tel: + 91-80-49160700 Ext 71583 II Email: [email-masked]<mailto:[email-masked]>
[Huawei-small]
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 28 August 2018 08:37
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Pce] 答复: RE: RE: PCEP extensions for SR-TP

Hi Marina,

   Thank you for the comments and suggestions!

   I have uodated the version of the draft.  https://datatracker.ietf.org/doc/draft-xiong-pce-pcep-extension-sr-tp/

   I still add the path label extension into  the SR-ERO.   The path is similiar with SR node or adjacency and we view the path label

   as a type of SR segmnet label or SID named SR path SID.

   Please check it and give more comments! Thanks!

Quan

熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R＆D Institute/Wireline Product Operation

武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: [email-masked]<mailto:[email-masked]>
www.zte.com.cn<http://www.zte.com.cn/>

原始邮件
发件人：MarinaFizgeer <[email-masked]<mailto:[email-masked]>>
收件人：熊泉00091065;
抄送人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>胡方伟10075772;詹双平10034653;Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>Alexander Ferdman <[email-masked]<mailto:[email-masked]>>Ron Sdayoor <[email-masked]<mailto:[email-masked]>>Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>Rotem Cohen <[email-masked]<mailto:[email-masked]>>
日 期 ：2018年08月22日 16:38
主 题 ：RE: RE: PCEP extensions for SR-TP
Hi, Xiong Quan,
As far as I understand your question, path label shall be allocated by PCE.
Then, forward path label shall be added to the bottom (last one) of the label stack and the reverse path label shall be configured to the data plane as incoming  label for this LSP

Best regards,

Marina

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, August 22, 2018 11:11 AM
To: Marina Fizgeer <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; Alexander Ferdman <[email-masked]<mailto:[email-masked]>>; Ron Sdayoor <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>;  Rotem Cohen <[email-masked]<mailto:[email-masked]>>
Subject: 答复: RE: PCEP extensions for SR-TP

Hi Marina,

Thanks for your comments! I understand your points now.

I agree with you that two labels need to be added to the ERO sub-object list. That is forwarding path label and reverse path label.

An  And  just one label will be inserted into the SR label stack and another one is stored for the bi-directional binding and mapping process.

The details are as following:

So there is one problem left. How to carry the path label?

1, add two sub-TLVs to the LSP object (one for forward path ID and  one with R bit for reverse path ID).

2, add the two path labels  to the SR-ERO subobjects.

3,add one path label to the SR-ERO subobjects  and insterted into label stack together with ERO,  add another path to the LSP object sub-TLV for local processing.

Any suggestion is appreciated!

Best Regards,

Quan

熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R＆D  Institute/Wireline Product Operation

武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: [email-masked]<mailto:[email-masked]>
www.zte.com.cn<http://www.zte.com.cn/>

原始邮件
发件人：MarinaFizgeer <[email-masked]<mailto:[email-masked]>>
收件人：熊泉00091065;
抄送人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>胡方伟10075772;詹双平10034653;Michael  Gorokhovsky <[email-masked]<mailto:[email-masked]>>Alexander Ferdman <[email-masked]<mailto:[email-masked]>>Ron Sdayoor <[email-masked]<mailto:[email-masked]>>Alexander  Vainshtein <[email-masked]<mailto:[email-masked]>>Rotem Cohen <[email-masked]<mailto:[email-masked]>>
日 期 ：2018年08月22日  14:06
主 题 ：RE: PCEP extensions for SR-TP
Hi, Xiong Quan,
Thank you for reply.
Some comments:

1.      R bit shall be 1 for reverse direction (and not 0)

2.      As I understand, we don’t have egress ERO for reverse direction. My suggestion was to add the second (reverse) path ID to the  ingress  ERO of LSP.

3.      One remark: path ID is not routing object, may be make sense to add two sub-TLVs to the LSP object (one for forward path ID and  one  with R bit for reverse path ID). It means that LSP will have two additional attributes – forward path ID and reverse path ID

Best regards,

Marina

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, August 22, 2018 6:28 AM
To: Marina Fizgeer <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; Alexander Ferdman <[email-masked]<mailto:[email-masked]>>;  Ron Sdayoor <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>;  Rotem Cohen <[email-masked]<mailto:[email-masked]>>
Subject: 答复: PCEP extensions for SR-TP

Hi Marina,

Thanks for your attention and comments!  I think you have proposed a good question.

The "path label " which my draft defined is inserted into ERO list and uniquely identifies a uni-directional path.

So one label can be added to the Ingress ERO list for the  forwarding direction and

another label with the R bit set to 0 can be added to the egress ERO list for the reverse direction.

The two path labels can be the same or diffrent and can be binded to indentify a bi-directional path.

I will update the draft soon and provide more details.

More comments are welcome!

Quan

熊泉 xiongquan

软件工程师 Software Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R＆D   Institute/Wireline Product Operation

武汉市东湖高新技术开发区华师园路6号中兴通讯
2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th,
Hi-tech Donghu District, Wuhan, P.R.China, 430022
T: +86 27 13871144372
E: [email-masked]<mailto:[email-masked]>
www.zte.com.cn<http://www.zte.com.cn/>

原始邮件
发件人：MarinaFizgeer <[email-masked]<mailto:[email-masked]>>
收件人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
抄送人：熊泉00091065;胡方伟10075772;詹双平10034653;Michael   Gorokhovsky <[email-masked]<mailto:[email-masked]>>Alexander Ferdman <[email-masked]<mailto:[email-masked]>>Ron Sdayoor <[email-masked]<mailto:[email-masked]>>Alexander   Vainshtein <[email-masked]<mailto:[email-masked]>>Rotem Cohen <[email-masked]<mailto:[email-masked]>>
日 期 ：2018年08月20日  20:31
主 题 ：PCEP extensions for SR-TP
Dear authors of draft-xiong-pce-pcep-extension-sr-tp,
My colleagues and I are interested in some clarifications:
According to this draft, Path label can be added as the last label in the LSP SR-ERO list.
Each endpoint element needs 2 labels – one for forward path ID and one for incoming path ID
Our question is – if 2 path labels can be added to the LSP SR-ERO list (one with “R” bit) per LSP?
Path label with “R” bit set will not be added to outgoing label stack, but will be configured in the data plane as an incoming label.
Using this approach one SR-ERO list will contain outgoing Path label as well as incoming Path label
PCE path example:

Best regards,

Marina
Email: [email-masked]<mailto:[email-masked]>
            [email-masked]<mailto:[email-masked]>

___________________________________________________________________________

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.
___________________________________________________________________________