Subject: Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info

From: [email-masked]
Date: Tue, 9 Aug 2016 11:55:41 +0800

Other documents have already addressed this issue, for example, set L-flag 
of Prefix-SID Sub-TLV in draft-ietf-isis-segment-routing-extensions-05 and 
contain IPv4 Source Router ID in rfc7794.

Thanks,

Deccan

[spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info
"John G. Scudder" <[email-masked]> Sun, 24 July 2016 12:54 UTCShow header
Dear WG,

As we discussed at our meeting, working group adoption has been requested 
for draft-filsfils-spring-sr-recursing-info. Please reply to the list with 
your comments, including although not limited to whether or not you 
support adoption. Non-authors are especially encouraged to comment.

We will end the call on August 31, 2015. 

Authors, please indicate whether you are aware of any relevant IPR and if 
so, whether it has been disclosed.

Thanks,

--Bruno and John

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 22 Aug 2016 13:38:54 +0000

> On Aug 9, 2016, at 5:55 AM, [email-masked] wrote:
> 
> Other documents have already addressed this issue,

I don’t think so. Can you point to these documents ?

> for example, set L-flag of Prefix-SID Sub-TLV in draft-ietf-isis-segment-routing-extensions-05 and contain IPv4 Source Router ID in rfc7794. 

the L flag has the solely purpose of indicating the sid contains a local value. Typically it goes with the V flag that indicates a value (i.e.: local label).

Nothing is mentioned regarding sharing the same sid among different services.

s.

> As we discussed at our meeting, working group adoption has been requested for draft-filsfils-spring-sr-recursing-info. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment.
> 
> Authors, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed.
> 
> Thanks,
> 
> --Bruno and John
> 
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: [email-masked]
Date: Tue, 23 Aug 2016 10:39:43 +0800

Hi Stefano

Sure, SRRI provided in this document can explicitly indicate a recursive 
operation (or relationship). 
But it maybe a default behavior to do recursive operation when an SR-NODE 
received remote prefix-sid with L/V flag set according to the documents 
already existed. For example, 
prefix reachability advertisement received:
    prefix (1.0.0.99/32) 
        prefix-sid (30004), L/V flag set,  //ISIS-SR
        "IPv4 Source Router ID" is 1.0.0.4 //rfc7794
Then, prefix 1.0.0.9/32 can do recursion to prefix 1.0.0.4/32 by default. 
If "default behavior" is not accepted, we can define a new RECURSIVE flag 
in Prefix-SID Sub-TLV.

BTW, all we discussed is SID recursive but not sharing, even the first 
case in this draft is actually not SID sharing, otherwise it will be cared 
by draft-ietf-spring-conflict-resolution.

Thanks
Deccan

"Stefano Previdi (sprevidi)" <[email-masked]> 
2016-08-22 21:38

收件人
"[email-masked]" <[email-masked]>, 
抄送
SPRING WG <[email-masked]>
主题
Re: [spring] WG adoption requested for 
draft-filsfils-spring-sr-recursing-info

> for example, set L-flag of Prefix-SID Sub-TLV in 
draft-ietf-isis-segment-routing-extensions-05 and contain IPv4 Source 
Router ID in rfc7794. 

the L flag has the solely purpose of indicating the sid contains a local 
value. Typically it goes with the V flag that indicates a value (i.e.: 
local label).

Nothing is mentioned regarding sharing the same sid among different 
services.

s.

> As we discussed at our meeting, working group adoption has been 
requested for draft-filsfils-spring-sr-recursing-info. Please reply to the 
list with your comments, including although not limited to whether or not 
you support adoption. Non-authors are especially encouraged to comment.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 23 Aug 2016 15:22:23 +0000

Hi Deccan,

> On Aug 23, 2016, at 4:39 AM, [email-masked] wrote:
> 
> Hi Stefano 
> 
> Sure, SRRI provided in this document can explicitly indicate a recursive operation (or relationship). 
> But it maybe a default behavior to do recursive operation when an SR-NODE received remote prefix-sid with L/V flag set according to the documents already existed. For example, 

there are other cases where V/L are used so I wouldn’t 
bind these flags to the recursive behavior.

> If "default behavior" is not accepted, we can define a new RECURSIVE flag in Prefix-SID Sub-TLV. 

if I understand your proposal, you could:
. attach the SourceRouterID (RFC7794) to the prefix
. attach a prefix-sid with:
   . recursive flag set, which means the sid is to be 
      taken from the sourceRouterID
   . optionally set the V/L flag and also a local label
   . if no V/L flag are set, the value of the sid/label 
      field in the prefix-sid must be 0 on transmit and 
      ignored on receive.

I see at least 2 problems with that:
1. the value of the prefix-sid you’re going to advertise 
   will be misinterpreted by non-srri-capable nodes 
   (i.e.: nodes know knowing the recursive flag). I.e: The 
   value of the prefix sid would be either an explicit 
   null label either a 0-value index.
2. RFC7794 states that: the Router ID advertised is 
   always the Router ID of the IS-IS instance that 
   originated the advertisement.
 
   This reduces the ability to use other addresses of the 
   node for recursion.

Bottom line, having a separate repository for the recursing 
information is the safest and cleanest option which allows 
better flexibility (i.e.: allowing to recurse to a 
non-router-ID address) and which ensure backward 
compatibility (i.e.: non-srri-nodes will simply ignore the 
whole srri info and consider the prefix as it had no sid at 
all).

> BTW, all we discussed is SID recursive but not sharing,

of course it is sharing. As defined in the draft, the 
local label attached to the srri info it’s an optional 
optimization. Without the local label, you will share the 
same sid among multiple prefixes. 

> even the first case in this draft is actually not SID sharing, otherwise it will be cared by draft-ietf-spring-conflict-resolution. 

No, it is not a conflict. Having a dedicated srri 
repository makes it clear.

s.

> Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info
> 
> 
> 
> 
> 
>

---

From: [email-masked]
Date: Thu, 25 Aug 2016 10:41:02 +0800

Stefano,

see inline with [Deccan]

Thanks
Deccan

2016-08-23 23:22

收件人

Hi Deccan,

> But it maybe a default behavior to do recursive operation when an 
SR-NODE received remote prefix-sid with L/V flag set according to the 
documents already existed. For example, 

[Deccan] Yes, it is entirely possible to generate a segment list only 
including segments with local meaning, such as adjacency segment list, 
service segment list, etc., without any node segment. So it is not 
appropriate to do recursive operation for local meaning segments by 
default. There maybe other cases that I don't know.

[Deccan] The above last point could be modified:
In despite V/L flag set or not, the value of the sid/label field in the 
prefix-sid must always be a valid value. That is, for recursive use-case, 
it is its own sid; for sharing use-case, it is the sharing sid. However, 
if the received nodes don't know RECURSIVE flag, for sharing use-case, sid 
conflicting will process; for recursive use-case, no recursion to be done.

[Deccan] Yes, the alternate method only allows to recurse to a router-id 
address. But, don't you think router-id address is enough for any segment 
list? Especially for an SR-TE path dynamic computed by CSPF, I think a 
non-router-id address will have no chance to represent a node-segment. 
However, the alternate method seems to be not much clean than SRRI method, 
for the possible sid conflicting introduced in sharing use-case, from this 
point, the SRRI method is good.

> even the first case in this draft is actually not SID sharing, otherwise 
it will be cared by draft-ietf-spring-conflict-resolution. 

[Deccan] Ok, I have not got this point before. However, if router-id 
address is enough, sid sharing seems to be not so much significant, do you 
think so?

s.

services.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 25 Aug 2016 09:39:16 +0000

> On Aug 25, 2016, at 4:41 AM, [email-masked] wrote:
> 
> Stefano, 
> 
> see inline with [Deccan] 
> 
> Thanks 
> Deccan 
> 
> 
> 
> [Deccan] Yes, it is entirely possible to generate a segment list only including segments with local meaning, such as adjacency segment list, service segment list, etc., without any node segment. So it is not appropriate to do recursive operation for local meaning segments by default. There maybe other cases that I don't know.
> 
> In despite V/L flag set or not, the value of the sid/label field in the prefix-sid must always be a valid value. That is, for recursive use-case, it is its own sid; for sharing use-case, it is the sharing sid. However, if the received nodes don't know RECURSIVE flag, for sharing use-case, sid conflicting will process; for recursive use-case, no recursion to be done. 

so, it’s broken.

> [Deccan] Yes, the alternate method only allows to recurse to a router-id address. But, don't you think router-id address is enough for any segment list?

absolutely not. Yu need to be able to recurse multiple prefixes to different addresses (all belonging to the same node).

> Especially for an SR-TE path dynamic computed by CSPF, I think a non-router-id address will have no chance to represent a node-segment. However, the alternate method seems to be not much clean than SRRI method, for the possible sid conflicting introduced in sharing use-case, from this point, the SRRI method is good. 

CSPF is not the main use case here.

> [Deccan] Ok, I have not got this point before. However, if router-id address is enough,

router-ID is not enough.

> sid sharing seems to be not so much significant, do you think so? 

I think the srri method is the cleanest and safest option to provide both:
. recursion of a prefix to a different sid
. sharing the same sid among different prefixes
without incurring well known backward-compatibility and conflicting issues.

srri is a generic solution applicable to a variety of use cases.

Thanks.
s.