Subject: [Isis-wg] Comments on draft-ietf-isis-segment-routing-extensions-01

From: Xuxiaohu <[email-masked]>
Date: Thu, 12 Jun 2014 10:10:01 +0000

Hi all, 

The following are some comments on draft-ietf-isis-segment-routing-extensions-01 (Note that the former four comments are applicable to draft-psenak-ospf-segment-routing-extensions-05 as well.):

1. Terminology inconsistency issues

The first example is about the semantics of the SID. According to the following description in section 2.1 "...SID/Index/Label: according to the V and L flags, it contains...", the SID would be something other than label and index. However,  in the same section, it said "... Multiple Prefix-SIDs Sub-TLVs MAY appear on the same prefix in which case each SID is encoded as a separate Sub-TLV....", here the SID seems to be a generic terminology, which could be index, label or SID. 

The second example is about the length of the SID (here the SID is something other than index and label). In section 2.1, it said "...A variable length SID (e.g.: an IPv6 address SID)...." However, in section 2.3, it said "... SID/Label: if length is set to 3 then the 20 rightmost bits represent a MPLS label.  If length is 4 then the value represents a 32 bits SID..." 

2. The uncertain usage of the 32-bit SID

It said in draft-previdi-6man-segment-routing-header-01 that "In Segment Routing IPv6 the SID is an IPv6 address". Therefore, what's the usage of the 32-bit SID (see section 2.3, it said "... SID/Label: if length is set to 3 then the 20 rightmost bits represent a MPLS label.  If length is 4 then the value represents a 32 bits SID)?

3. The uncertain usage of the 16-octect SID in the Prefix-SID sub-TLV

In IPv6-SR case, since the SID is an IPv6 address, what's the usage of the prefix-SID sub-TLV? It has been said in draft-previdi-6man-segment-routing-header-00 that " When Segment Routing is applied to IPv6, segments are encoded as 128-bit IPv6 addresses.  This implies that, in the IPv6 instantiation of SR, the SID values are in fact the prefixes advertised in the IPv6 control-plane.  Hence there's no need to advertise any additional specific identifier (other than IPv6 prefix) for the purpose of SR. This simplifies the introduction of IPv6 Segment Routing in existing protocols (i.e.: IS-IS, OSPF and BGP). "
I noticed that the above statement has been disappeared in the -01 version. Did that mean that the co-authors of that draft have changed their minds significantly?

4. Suggestion on the algorithm field in the prefix-SID sub-TLV

It seems that using various algorithms in the best path computation could also be applicable to some cases other than SR. For instance, use different algorithms for different topologies [rfc5120]. Therefore, it seems better to decouple the best path computation algorithm advertisement from the SR-specific advertisement. In this way, the algorithm is just coupled with the topology while the labels advertised through the prefix-sid sub-TLVs could be used to determine to which topology the received SR-MPLS packet belongs to. This behavior is much similar to the LDP and the LDP-MT. In other words, the SR-specific IGP extension just plays the role of label distribution protocol which shouldn't have any impact on the path computation behavior. 

5. The lack of MT-ID field in the SID/Label Binding TLV

I had suggested to add an MT-ID field in the SID/Label Binding TLV and Stefano had agreed to that suggestion. But it seems that the MT-ID field has not been added yet.

6. Suggestion on SR-Capabilities Sub-TLV
The SR-Capabilities Sub-TLV is used to advertise: 1) data-plane capability; 2) range of SID/Label values. It seems better to advertise these two capabilities via two separate sub-TLVs, e.g., DP-Capability sub-TLV and SID/Label Range sub-TLV. In the way, the role of SID/Label Range sub-tlv is consistent with the counterpart in OSPF extensions (i.e., SID/Label Range TLV). Anyway, it seems better to keep the ISIS and OSPF extensions for the same function as consistent as possible. 

Best regards,
Xiaohu

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 12 Jun 2014 10:41:43 +0000

Hi Xiaohu,

> The second example is about the length of the SID (here the SID is something other than index and label). In section 2.1, it said "...A variable length SID (e.g.: an IPv6 address SID)...." However,…

I'm not sure I understand where the inconsistency is.

Prefix-SID goes with prefixes. Adj-SID goes with adjacencies.

Both SubTLVs may be value or index and may have local or global scope.

This is the flexibility we want to have.

> It said in draft-previdi-6man-segment-routing-header-01 that "In Segment Routing IPv6 the SID is an IPv6 address". Therefore, what's the usage of the 32-bit SID (see section 2.3, it said "... SID/L…

you're right. I'll fix the text.

> I noticed that the above statement has been disappeared in the -01 version. Did that mean that the co-authors of that draft have changed their minds significantly?

nope. The text you mentioned has been replaced by the following one:

"The Node-SID identifies a node. With SR-IPv6 the Node-SID is an IPv6 
 prefix that the operator configured on the node and that is used as 
 the node identifier. Typically, in case of a router, this is the IPv6 
 address of the node loopback interface. Therefore, SR-IPv6 does not 
 require any additional SID advertisement for the Node Segment. The 
 Node-SID is in fact the IPv6 address of the node."

> It seems that using various algorithms in the best path computation could also be applicable to some cases other than SR. For instance, use different algorithms for different topologies [rfc5120].…

initially, we thought about making the algorithm a generic TLV but 
later preferred to confine it to the SR context.

If there's consensus, I don't mind to enlarge the scope but I'd prefer 
not to re-invent MT.

> I had suggested to add an MT-ID field in the SID/Label Binding TLV and Stefano had agreed to that suggestion. But it seems that the MT-ID field has not been added yet.

I agree with you but since the binding TLV was not originally part of 
the SR proposal (i.e.: it's the merge with Hannes draft) I'd let Hannes 
to comment.

> The SR-Capabilities Sub-TLV is used to advertise: 1) data-plane capability; 2) range of SID/Label values. It seems better to advertise these two capabilities via two separate sub-TLVs, e.g., DP-Cap…

I disagree. Keeping encoding aligned between isis and ospf is NOT a goal. 
What is necessary is to keep consistency between functionalities.

s.

> 
> Best regards,
> Xiaohu
> 
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 12 Jun 2014 14:14:34 +0200

> the SR proposal (i.e.: it's the merge with Hannes draft) I'd let Hannes 

no concerns from my side, we can add a MTID subTLV to specify
what topology an advertised path does belong to.

do you want to send text for the suggested change or shall i give a stab at it ?

/hannes

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Jun 2014 02:05:32 +0000

Hi Stefano,

> -----Original Message-----
> From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
> Sent: Thursday, June 12, 2014 6:42 PM
> To: Xuxiaohu
> Cc: [email-masked]; OSPF List
> Subject: Re: [OSPF] Comments on draft-ietf-isis-segment-routing-extensions-01
> 
> Hi Xiaohu,
> 
> 
> > The following are some comments on
> draft-ietf-isis-segment-routing-extensions-01 (Note that the former four
> comments are applicable to draft-psenak-ospf-segment-routing-extensions-05
> as well.):
> >
> > The first example is about the semantics of the SID. According to the following
> description in section 2.1 "...SID/Index/Label: according to the V and L flags, it
> contains...", the SID would be something other than label and index. However,
> in the same section, it said "... Multiple Prefix-SIDs Sub-TLVs MAY appear on the
> same prefix in which case each SID is encoded as a separate Sub-TLV....", here
> the SID seems to be a generic terminology, which could be index, label or SID.
> >
> > The second example is about the length of the SID (here the SID is something
> other than index and label). In section 2.1, it said "...A variable length SID (e.g.:
> an IPv6 address SID)...." However, in section 2.3, it said "... SID/Label: if length is
> set to 3 then the 20 rightmost bits represent a MPLS label.  If length is 4 then
> the value represents a 32 bits SID..."
> 
> 

If you want to take the "SID" as a generic term which would be interpreted as an MPLS label in the MPLS-SR case and an IPv6 address in the IPv6-SR case, you'd better not list it with index/label in parallel (e.g., a description in section 2.1 "...SID/Index/Label: according to the V and L flags, it contains..." ) . Otherwise, it would be deemed as a particular format of the segment identifier (e.g., a 32-bit SID which was specifically designed for IPv6-SR previously, or a 128-bit SID which is currently designed for IPv6-SR). That's my point.

> > It said in draft-previdi-6man-segment-routing-header-01 that "In Segment
> Routing IPv6 the SID is an IPv6 address". Therefore, what's the usage of the
> 32-bit SID (see section 2.3, it said "... SID/Label: if length is set to 3 then the 20
> rightmost bits represent a MPLS label.  If length is 4 then the value represents a
> 32 bits SID)?
> 
> 
> > In IPv6-SR case, since the SID is an IPv6 address, what's the usage of the
> prefix-SID sub-TLV? It has been said in
> draft-previdi-6man-segment-routing-header-00 that " When Segment Routing is
> applied to IPv6, segments are encoded as 128-bit IPv6 addresses.  This implies
> that, in the IPv6 instantiation of SR, the SID values are in fact the prefixes
> advertised in the IPv6 control-plane.  Hence there's no need to advertise any
> additional specific identifier (other than IPv6 prefix) for the purpose of SR. This
> simplifies the introduction of IPv6 Segment Routing in existing protocols (i.e.:
> IS-IS, OSPF and BGP). "
> > I noticed that the above statement has been disappeared in the -01 version.
> Did that mean that the co-authors of that draft have changed their minds
> significantly?
> 
> 
> "The Node-SID identifies a node. With SR-IPv6 the Node-SID is an IPv6  prefix

If the node-sid is an IPv6 address for sure, you'd better not say " the Node-SID is an IPv6  prefix ". Otherwise, it would cause an unnecessary confusion.

> that the operator configured on the node and that is used as  the node
> identifier. Typically, in case of a router, this is the IPv6  address of the node
> loopback interface. Therefore, SR-IPv6 does not  require any additional SID
> advertisement for the Node Segment. The  Node-SID is in fact the IPv6 address
> of the node."

If so, does it mean that the prefix-sid sub-TLV would not be used in the IPv6-SR case? Or do you still want to use it for some IPv6 prefixes with prefix-len being shorter than 128?

> > It seems that using various algorithms in the best path computation could also
> be applicable to some cases other than SR. For instance, use different algorithms
> for different topologies [rfc5120]. Therefore, it seems better to decouple the
> best path computation algorithm advertisement from the SR-specific
> advertisement. In this way, the algorithm is just coupled with the topology while
> the labels advertised through the prefix-sid sub-TLVs could be used to determine
> to which topology the received SR-MPLS packet belongs to. This behavior is
> much similar to the LDP and the LDP-MT. In other words, the SR-specific IGP
> extension just plays the role of label distribution protocol which shouldn't have
> any impact on the path computation behavior.
> 
> 
> initially, we thought about making the algorithm a generic TLV but later
> preferred to confine it to the SR context.
> 
> If there's consensus, I don't mind to enlarge the scope but I'd prefer not to
> re-invent MT.

A generic algorithm sub-TLV could be useful in some cases other than SR in the future. Take the TE router-id sub-TLV of the CAPABILITY TLV as an example, the routable address contained in such sub-TLV should have not been coupled with the TE purpose since it is now useful in some cases other than TE (note that this was discussed a few weeks ago in the ISIS mailing-list).

> > I had suggested to add an MT-ID field in the SID/Label Binding TLV and Stefano
> had agreed to that suggestion. But it seems that the MT-ID field has not been
> added yet.
> 
> 
> > The SR-Capabilities Sub-TLV is used to advertise: 1) data-plane capability; 2)
> range of SID/Label values. It seems better to advertise these two capabilities via
> two separate sub-TLVs, e.g., DP-Capability sub-TLV and SID/Label Range sub-TLV.
> In the way, the role of SID/Label Range sub-tlv is consistent with the counterpart
> in OSPF extensions (i.e., SID/Label Range TLV). Anyway, it seems better to keep
> the ISIS and OSPF extensions for the same function as consistent as possible.
> 
> 

I agree that the most important goal is to keep consistency between functionalities. However, wouldn't it be better if the consistency of encodings between ISIS and OSPF can be kept as well without any additional cost? At least, it becomes more easy for implementers and operators to read these two drafts if the consistency of encodings can be kept.

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Jun 2014 05:45:37 +0000

Hi Hannes,

> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Thursday, June 12, 2014 8:15 PM
> To: Xuxiaohu
> Cc: OSPF List; [email-masked] list; Stefano Previdi (sprevidi)
> >> I had suggested to add an MT-ID field in the SID/Label Binding TLV and
> Stefano had agreed to that suggestion. But it seems that the MT-ID field has not
> been added yet.
> >
> >
> > the SR proposal (i.e.: it's the merge with Hannes draft) I'd let
> > Hannes to comment.
> 
> 
> no concerns from my side, we can add a MTID subTLV to specify what topology
> an advertised path does belong to.

That would be great.

Best regards,
Xiaohu

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 13 Jun 2014 06:55:39 +0000

> If the node-sid is an IPv6 address for sure, you'd better not say " the Node-SID is an IPv6  prefix ". Otherwise, it would cause an unnecessary confusion.

ok, sorry. I intended a /128 prefix but you're right and I'll fix that.

> If so, does it mean that the prefix-sid sub-TLV would not be used in the IPv6-SR case?

not at this stage.

In the future we may come back and revisit the idea of using 32bit 
SIDs for ipv6 as well.

> Or do you still want to use it for some IPv6 prefixes with prefix-len being shorter than 128?
> 
> I agree that the most important goal is to keep consistency between functionalities. However, wouldn't it be better if the consistency of encodings between ISIS and OSPF can be kept as well without any additional cost?

I disagree.

Protocols are not the same and in the encodings one protocol may 
require additional info while the other already has it so let's 
not try to do something that:

1. is not needed
2. will require substantial effort

Thanks.
s.

> At least, it becomes more easy for implementers and operators to read these two drafts if the consistency of encodings can be kept.
> 
> Best regards,
> Xiaohu
> 
>> s.
>> 
>> 
>>> 
>>> Best regards,
>>> Xiaohu
>>> 
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 17 Jun 2014 07:08:12 +0000

> In the future we may come back and revisit the idea of using 32bit SIDs for ipv6
> as well.

Hi Stefano,

What's the motivation for using 32-bit SIDs, rather than 20-bit MPLS labels for IPv6, especially when the GLOBAL MPLS label concept has been explicitly supported by the draft and encapsulating an MPLS label stack into an IPv6-based tunnel (e.g., MPLS-over-GRE) is a very mature technology?

Best regards,
Xiaohu