Subject: [mpls] Comments about draft-xiong-mpls-path-segment-sr-mpls-interworking and difference between Path Segment and BSID

From: <[email-masked]>
Date: Thu, 12 Sep 2019 15:05:03 +0800 (CST)

Hi  all,

I noticed you proposed comments at the IETF#105 MPLS meeting to the draft "draft-xiong-mpls-path-segment-sr-mpls-interworking". Your comment and review is very appreciated!

The Path Segment defined in draft-ietf-spring-mpls-path-segment has been proposed and adopted in Spring WG.

The Path Segment is a path identification for Performance measurement and Bidirectional path correlation and End-to-end Path Protection.

The draft "draft-xiong-mpls-path-segment-sr-mpls-interworking" mainly focus on the SR and MPLS Interworking with Path Segment to provide

end-to-end bidirectional VPN service in inter-domain scenario. 

I noticed the Binding SID is also used in inter-domain scenario. I think the main difference is as follows:

Binding SID indicates a SID List. Selected path by replace the Binding SID to a SID List. Path Segment indicates a path, it can realize OAM,PM,protection. Selected path by path segment correlation.

Binding SID can not replace path segment in bidirectional path, OAM, PM and protection etc. If we use Binding SID, the per-segment or per-domain OAM/PM/protection can not be achieved.

I just start the discussion and comments and suggestions are very welcome!

Best Regards,

Quan

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 12 Sep 2019 15:47:23 +0530

Hi Quan,

Thanks for your mail and further discussion.

It is not about Path SID v/s Binding SID, both are needed and each serve a
specific purpose.

The comment I made during 105 was that you are using Path SID to do the
function of Binding SID!

See
https://tools.ietf.org/html/draft-xiong-spring-path-segment-sr-inter-domain-00#section-3.1,
where you say -

  The border nodes should
  install the following MPLS data entries for Path segments:

    incoming label: i-Path
       outgoing label: the SID list of the next domain or link + next i-Path

Here you are not using Path SID for OAM/PM but for the functionality of
Binding SID! That seems like a wrong thing to do!

Thanks!
Dhruv

On Thu, Sep 12, 2019 at 12:35 PM <[email-masked]> wrote:

> Hi  all,
>
>
> I noticed you proposed comments at the IETF#105 MPLS meeting to the draft
> "draft-xiong-mpls-path-segment-sr-mpls-interworking". Your comment and
> review is very appreciated!
>
>
> The Path Segment is a path identification for Performance measurement and
> Bidirectional path correlation and End-to-end Path Protection.
>
> The draft "draft-xiong-mpls-path-segment-sr-mpls-interworking" mainly
> focus on the SR and MPLS Interworking with Path Segment to provide
>
> Binding SID indicates a SID List. Selected path by replace the Binding SID
> to a SID List. Path Segment indicates a path, it can realize
> OAM,PM,protection. Selected path by path segment correlation.
>
> Binding SID can not replace path segment in bidirectional path, OAM, PM
> and protection etc. If we use Binding SID, the per-segment or per-domain
> OAM/PM/protection can not be achieved.
>
>

---

From: <[email-masked]>
Date: Mon, 16 Sep 2019 16:41:34 +0800 (CST)

Hi Dhruv,

Sorry to reply late! Sorry to misunderstand your comment!

I agree with you.  Path Segment and  Binding SID are different and each serve a specific purpose.

I think the use of the binding SID [RFC8402] is recommended to reduce the size of lable stack in our draft.

But the use of binding SID is not recommended to sticth the inter-domain instead of Path Segment.

The draft proposed two interworking models including Stitching (section-3.1) and Nesting (section-3.2).

For the stitching model, there is no end-to-end Path Segment, the end-to-end path across multiple domanins has been partitioned to several

domain segments and each domain segment is identified as an inter-domain Path Segment (i-Path). These i-Paths can be used to correlate the 

inter-domain paths whcih can be  stitched to an end-to-end path. In the headend node, the i-Path MUST bind the two unidirectional 

paths and correlate the bidirectional path. Moreover, each domain can accomplish the per-segment OAM, PM or protection by using the  i-Path.  

If we use Binding SID to stitch the inter-domain, the per-segment or per-domain OAM/PM/protection can not be achieved.

For the nesting model, an end-to-end Path Segment (e-Path) is existed and the end-to-end OAM/PM/protection can be accomplished by using e-Path.

In this model, sub-path Path Segment (s-Path) MAY also be defined and used to indicate the intra-domain path when the per-segment or per-domain

OAM, PM or protection is requried.  

In both models, the use of the binding SID [RFC8402] is also recommended to reduce the size of lable stack.

Best Regards,

Quan

原始邮件

发件人：DhruvDhody <[email-masked]>
收件人：熊泉00091065;
抄送人：Loa Andersson <[email-masked]>;Tarek Saad <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年09月12日 18:18
主 题 ：Re: Comments about draft-xiong-mpls-path-segment-sr-mpls-interworkingand difference between Path Segment and BSID

Hi Quan,

It is not about Path SID v/s Binding SID, both are needed and each serve a specific purpose.

The comment I made during 105 was that you are using Path SID to do the function of Binding SID!

See https://tools.ietf.org/html/draft-xiong-spring-path-segment-sr-inter-domain-00#section-3.1, where you say - 

  The border nodes should

    incoming label: i-Path

Here you are not using Path SID for OAM/PM but for the functionality of Binding SID! That seems like a wrong thing to do!

Thanks!
Dhruv

Hi  all,

Best Regards,

Quan

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 16 Sep 2019 14:31:05 +0530

Hi Quan,

Thanks for your email..

> But the use of binding SID is not recommended to sticth the inter-domain instead of Path Segment.

But Binding SID was meant to be used not just for label stack
reduction, but also for multi-domain scenarios.

See -
https://tools.ietf.org/html/draft-ietf-pce-binding-label-sid-00#section-1
https://tools.ietf.org/html/draft-filsfils-spring-sr-policy-considerations-03#section-6

The key question is - Why are you NOT using binding segment for
stitching? I think you try to explain that below -

> If we use Binding SID to stitch the inter-domain, the per-segment or per-domain OAM/PM/protection can not be achieved.

May be you need to use *BOTH* path segment and binding segment then!!
But associating the functionality of a binding SID to a path SID is
not correct!

Thanks!
Dhruv

---

From: <[email-masked]>
Date: Mon, 16 Sep 2019 17:25:38 +0800 (CST)

Hi  Dhruv,

Thanks for your quick reply!

I agree with you that Binding SID can to be used not just for label stack but also stitching in multi-domain scenarios.

The interworking scenario which we proposed also belongs to multi-domain scenarios, but as my last email mentioned,

the Binding SID can not meet our requirement. For example, the bidirectional path correlation and  the per-segment or 

per-domain OAM/PM/protection can not be achieved by using  Binding SID.

So could you please give us some suggestions to settle this issue?

Thanks,

Quan

原始邮件

发件人：DhruvDhody <[email-masked]>
收件人：熊泉00091065;
抄送人：Loa Andersson <[email-masked]>;Tarek Saad <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年09月16日 17:03
主 题 ：Re: Comments about draft-xiong-mpls-path-segment-sr-mpls-interworkinganddifference between Path Segment and BSID

Hi Quan,

Thanks for your email..

See -

>
> The draft proposed two interworking models including Stitching (section-3..1) and Nesting (section-3.2).
>
>

Thanks!
Dhruv

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 16 Sep 2019 15:10:23 +0530

Hi Quan,

> So could you please give us some suggestions to settle this issue?

I thought I did with -

Thanks!
Dhruv

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 17 Sep 2019 07:24:01 +0000

Agree. Binding SID and Path Segment are both needed. 

There are no doubt that they have different functionalities and usages:

* Binding SID maps a SID to an SID list, and this mapping action will be done by the mapping node, which is the beginning of the NEXT path (represented by the SID lists). The mapping node is the ingress node of the associated path.

* Path SID  maps a SID to a SID list, and this mapping is used at control plane only, there will not be any new SID list to be inserted introduced by Path SID. The path segment will be processed by the egress node of the associated path.

If you combine these two SIDs into one, then troubles come. The OAM/PM based on Path Segment will dependent on the other domains, since this path segment also identify the next path in the next domain. But the OAM/PM should be domain-independent.  

How to solve this?
Use Path Segment for intra-domain OAM/PM
Use Binding SID for inter-domain path stitching.

Best, 
Cheng

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Monday, September 16, 2019 5:01 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Comments about draft-xiong-mpls-path-segment-sr-mpls-interworkingand difference between Path Segment and BSID

Hi Quan,

Thanks for your email..

> But the use of binding SID is not recommended to sticth the inter-domain instead of Path Segment.

But Binding SID was meant to be used not just for label stack reduction, but also for multi-domain scenarios.

See -

The key question is - Why are you NOT using binding segment for stitching? I think you try to explain that below -

> For the stitching model, there is no end-to-end Path Segment, the 
> end-to-end path across multiple domanins has been partitioned to 
> several
>
> domain segments and each domain segment is identified as an 
> inter-domain Path Segment (i-Path). These i-Paths can be used to 
> correlate the
>
> inter-domain paths whcih can be  stitched to an end-to-end path. In 
> the headend node, the i-Path MUST bind the two unidirectional
>

May be you need to use *BOTH* path segment and binding segment then!!
But associating the functionality of a binding SID to a path SID is not correct!

Thanks!
Dhruv

> In this model, sub-path Path Segment (s-Path) MAY also be defined and 
> used to indicate the intra-domain path when the per-segment or 
> per-domain
>
> 抄送人：Loa Andersson <[email-masked]>;Tarek Saad 
> <[email-masked]>;[email-masked] 
> <[email-masked]>;draft-xiong-mpls-path-segment-sr-mpls-interworking@iet
> f.org <[email-masked]>;
> 日 期 ：2019年09月12日 18:18
> 主 题 ：Re: Comments about 
> draft-xiong-mpls-path-segment-sr-mpls-interworkingand difference 
> between Path Segment and BSID Hi Quan,
>
> https://tools.ietf.org/html/draft-xiong-spring-path-segment-sr-inter-d
> omain-00#section-3.1, where you say -
>
>   The border nodes should

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: <[email-masked]>
Date: Wed, 25 Sep 2019 17:35:32 +0800 (CST)

Hi Dhruv and Cheng,

Thanks for your reply! Sorry to reply late!

I agree with you about that using  *BOTH* path segment and binding segment mentioned by Dhruv and

using Path Segment for intra-domain OAM/PM and Binding SID for inter-domain path stitching mentioned by Cheng.

And this mechanism is sepcified in draft "draft-ietf-spring-mpls-path-segment" which has been adopted by Spring WG.

But I think it is just appropriate for nesting model as that draft defined and it proposed the nesting of Path Segments.

The solution is not appropriate for stitching model. The reasons are as follows.

a. In stitching models, the BSID is not appropriate. As defined in RFC8402, the headend of an SR Policy binds a BSID to its policy.

The BSID which  indicates the SID List and selected path of the next domain MUST be pushed in at the ingress node of the prev domain 

and popped out at the ingress node of next domain.  The path  information of two domains ate mixed together, It can not meet the requirement of stitching model.

b.Whatover,the internal information of one domain has been exposed to other domain. It is not appropriate when the domains belong to different operators.

c. In stitching models, I think all the labels in label stack need to be pushed in at the ingress nodes and be popped out at the egress nodes of each domain. 

We can not carry all the BSIDs at the ingress node of ingress domain as nesting model defined.

d. In stitching models, we proposed the stitching of Path Segments.  We proposed the Path segments correlation to realize the inter-domain stitching. And the inter-domain stitching 

is not just the SID List stitching but also the path stitching which can achieve path OAM/PM/protection.

Quan

原始邮件

发件人：DhruvDhody <[email-masked]>
收件人：熊泉00091065;
抄送人：Loa Andersson <[email-masked]>;Tarek Saad <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年09月16日 17:41
主 题 ：Re: Comments aboutdraft-xiong-mpls-path-segment-sr-mpls-interworkinganddifferencebetween Path Segment and BSID

Hi Quan,

I thought I did with -

Thanks!
Dhruv