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

Hi Stefano,

> -----Original Message-----
> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
> Sent: Thursday, June 12, 2014 6:42 PM
> To: Xuxiaohu
> Cc: isis-wg@ietf.org; OSPF List
> Subject: Re: [OSPF] Comments on draft-ietf-isis-segment-routing-extensions-01
> 
> Hi Xiaohu,
> 
> 
> On Jun 12, 2014, at 12:10 PM, Xuxiaohu wrote:
> > 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..."
> 
> 
> 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.

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.

> > 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)?
> 
> 
> you're right. I'll fix the text.
> 
> 
> > 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?
> 
> 
> 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

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?

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

> > 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.
> 
> 
> 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.
> 
> 
> > 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.
> 
> 
> I disagree. Keeping encoding aligned between isis and ospf is NOT a goal.
> What is necessary is to keep consistency between functionalities.

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

> s.
> 
> 
> >
> > Best regards,
> > Xiaohu
> >
> > _______________________________________________
> > OSPF mailing list
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf