Subject: [OSPF] Comments draft-ietf-ospf-segment-routing-extensions-00.txt

From: Acee Lindem <[email-masked]>
Date: Tue, 1 Jul 2014 21:00:40 +0000

Hi Peter, 

I’ve reviewed the OSPF Segment Routing WG draft and have some comments. 

       1. Can you describe the usage of algorithm in the Segment Routing domain? An SR capable router advertises the algorithms it supports and an algorithm is associated with a Prefix-SID. However, the usage of this information is not described anywhere and it  is guaranteed that there will be many different interpretations. 

       2. The usage of the advertised Weight references the “Segment Routing Architecture”. However, there is no description of weight usage there.

       3. Section 3.2 - the range advertisement seems a bit unnatural. Why is it assumed that all the advertised ranges have the same size? It would seem more intuitive that individual ranges are defined by the <size/starting SID> tuple.  

       4. Section 4.2 - Can you please make the P-flag the NP-Flag since the set value indicates not to perform the PHP operation? If you want to keep it the P-Flag, the set value should mean to perform the PHP.

       5. Section 4.2 and 5.2 - The Segment Routing architecture defines adjacency SIDs as having local significance. Yet the L-Flag allows this to be encoded as global.  Similarly, it would seem that a prefix SID would normally have global significance and local significance would be an exception (e.g., possibly a loopback address accessible only from the advertising OSPF router). 

       6. Section 4.2 - I really don’t like having his sub-TLV redefine the subsuming top-level TLV as a range of prefixes of the same length rather than a single prefix. Although this is my first serious reading of the draft, this encoding seems really unwieldy and, in practice, I’d expect the range size always advertised as 1. We can discuss this more in Toronto. 

       7. Section 4.2 - Shouldn’t the reference for the mapping server be the “Segment Routing Architecture” rather than the “Segment Routing Use Cases”? In general, the usage of a mapping server and the scope of assignment needs to be described better somewhere (not in the OSPF encoding document). 

       8. Section 6 - It would seem that an entity calculating a multi-area SR path would need access to the topology for all the areas and the SID would need to be globally assigned? Right? So rules are primarily for the population of the forwarding plane. Right? 

       9. Section 6.2 - In standard OSPF, inter-area summary propagation only applies to inter-area routes learned over the backbone. Is this any different? 

Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Wed, 02 Jul 2014 13:35:02 +0200

Hi Acee,

please see inline:

>         1. Can you describe the usage of algorithm in the Segment Routing domain? An SR capable router advertises the algorithms it supports and an algorithm is associated with a Prefix-SID. Howeve…

filsfils-spring-segment-routing-use-cases will be updated to include the 
usage of algorithm.

>         2. The usage of the advertised Weight references the “Segment Routing Architecture”. However, there is no description of weight usage there.

weight is used for influencing load-balancing across multiple adj-sid's 
to the same node.

filsfils-spring-segment-routing-use-cases will be updated to include the 
usage of weight.

>         3. Section 3.2 - the range advertisement seems a bit unnatural. Why is it assumed that all the advertised ranges have the same size? It would seem more intuitive that individual ranges are…

there is a typo in the text:
"SID/Label Sub-TLV MAY appear multiple times" will be changed to 
"SID/Label Range TLV MAY appear multiple times", which I believe will 
address your comment.

>         4. Section 4.2 - Can you please make the P-flag the NP-Flag since the set value indicates not to perform the PHP operation? If you want to keep it the P-Flag, the set value should mean to p…

sure, will rename to NP-flag

>         5. Section 4.2 and 5.2 - The Segment Routing architecture defines adjacency SIDs as having local significance. Yet the L-Flag allows this to be encoded as global.  Similarly, it would seem…

the architectre draft will be corrected to reflect that both prefix-sid 
and adj-sid can be global or local.

>         6. Section 4.2 - I really don’t like having his sub-TLV redefine the subsuming top-level TLV as a range of prefixes of the same length rather than a single prefix. Although this is my first…

an example where the range would be more then 1 is a mapping server 
case. This helps you to advertise SIDs for loopback addresses of all 
routers in a non-SR capable part of the network, assuming they are 
allocated from the contiguous address space. Instead of advertising 
hundreds of mappings for each /32 address, you can compact it to a 
single advertisement.

What you need in such case is component prefix/length plus the number of 
components - OSPF Extended Prefix TLV gives you the component info and 
Prefix SID Sub-TLV "Range Size' gives you the number of components.

We could have defined a separate top level TLV in OSPF Extended Prefix 
LSA for the advertisement of range of components, but it looks to me 
that would be an overkill. Current encoding of Prefix SID Sub-TLV gives 
us all the flexibility we need. In addition it matches what ISIS has done.

>         7. Section 4.2 - Shouldn’t the reference for the mapping server be the “Segment Routing Architecture” rather than the “Segment Routing Use Cases”? In general, the usage of a mapping server…

will fix the reference

>
>         8. Section 6 - It would seem that an entity calculating a multi-area SR path would need access to the topology for all the areas and the SID would need to be globally assigned? Right?

correct.

> So rules are primarily for the population of the forwarding plane. Right?

for advertisement/propagation of SIDs and for forwarding plane programming.

>         9. Section 6.2 - In standard OSPF, inter-area summary propagation only applies to inter-area routes learned over the backbone. Is this any different?

no, the mechanism is the same as for type-3s.

thanks,
Peter

> .

---

From: Acee Lindem <[email-masked]>
Date: Wed, 2 Jul 2014 17:17:19 +0000

Hi Peter, 
It seems there are two distinct deployment scenarios - one where SR routers are given a range and policy and allocate their own SIDs and another where a mapping server does it for the routing domain. 
See inline for #6. 

On Jul 2, 2014, at 7:35 AM, Peter Psenak <[email-masked]> wrote:

> filsfils-spring-segment-routing-use-cases will be updated to include the usage of algorithm.
> 
>> 
> weight is used for influencing load-balancing across multiple adj-sid's to the same node.
> 
> filsfils-spring-segment-routing-use-cases will be updated to include the usage of weight.
> 
>> 
> "SID/Label Sub-TLV MAY appear multiple times" will be changed to "SID/Label Range TLV MAY appear multiple times", which I believe will address your comment.
> 
>> 
> the architectre draft will be corrected to reflect that both prefix-sid and adj-sid can be global or local.
> 
>> 
> an example where the range would be more then 1 is a mapping server case. This helps you to advertise SIDs for loopback addresses of all routers in a non-SR capable part of the network, assuming they are allocated from the contiguous address space. Instead of advertising hundreds of mappings for each /32 address, you can compact it to a single advertisement.

I’ve seen loopbacks allocated sequentially in a few networks but many more where there weren’t. 

> 
> What you need in such case is component prefix/length plus the number of components - OSPF Extended Prefix TLV gives you the component info and Prefix SID Sub-TLV "Range Size' gives you the number of components.

I understood it but I don’t like the sub-TLV extending the specification of the higher level TLV. I especially don’t like it since the top-level TLV is a generic mechanism to advertise attributes.  When additional attributes are defined, it begs the of whether or not they apply solely to the prefix or to the range. 

> 
> We could have defined a separate top level TLV in OSPF Extended Prefix LSA for the advertisement of range of components, but it looks to me that would be an overkill.

I would have preferred that. When the SID attributes are embedded (OSPFv3 and ISIS), I think the semantics are even more unnatural since reachability MAY be advertised for the prefix while SID mapping is being advertised for the range. 

> Current encoding of Prefix SID Sub-TLV gives us all the flexibility we need. In addition it matches what ISIS has done.

I haven’t seen any discussion of the draft on the ISIS list other than the revision updates. 

Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Thu, 03 Jul 2014 10:09:32 +0200

Hi Acee,

please see inline:

> It seems there are two distinct deployment scenarios - one where SR routers are given a range and policy and allocate their own SIDs and another where a mapping server does it for the routing domai…

yes, that is correct. The latter is used mainly during migration from 
LDP to SR.

> I’ve seen loopbacks allocated sequentially in a few networks but many more where there weren’t.

still, having a mechanism to compact the advertisements if possible 
looks appealing.

> I understood it but I don’t like the sub-TLV extending the specification of the higher level TLV. I especially don’t like it since the top-level TLV is a generic mechanism to advertise attributes.…

high level TLV advertise a single prefix/mask. It's the sub-TLV which 
may extend the applicability to the range if required, so the scope is 
defined by each sub-TLV.

> I would have preferred that. When the SID attributes are embedded (OSPFv3 and ISIS), I think the semantics are even more unnatural since reachability MAY be advertised for the prefix while SID mapp…

I had the same reservations at the beginning :)
But there is no problem really. Prefix-SID sub-TLV never advertises any 
reachability, whether it advertises a single SID or a range of SIDs. For 
Prefix-SID sub-TLV, prefix from the higher level TLV has a meaning of 
"start" and Prefix-SID sub-TLV always carry its own "size" - just a 
different interpretation of the data from the higher level TLV.

Please note that SID range is quite different from the address range we 
are used to from summarization. SID range requires three parameters 
(address/mask and count), compared to two parameter (address/mask) that 
traditional address range uses. As a result, Extended prefix TLV as such 
can not cover the SID range, because it only has address/mask. Defining 
a top-level TLV for a SID range itself does not really fit into Extended 
Prefix LSA and having a new LSA for it is not an option I would say. So 
the current encoding looks like a good compromise to me.

thanks,
Peter

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 3 Jul 2014 10:01:52 +0000

> -----Original Message-----
> From: OSPF [mailto:[email-masked]] On Behalf Of Peter Psenak
> Sent: Thursday, July 03, 2014 4:10 PM
> To: Acee Lindem
> Cc: OSPF List
> Subject: Re: [OSPF] Comments
> draft-ietf-ospf-segment-routing-extensions-00.txt
> 
> Hi Acee,
> 
> please see inline:
> 
> > It seems there are two distinct deployment scenarios - one where SR routers
> are given a range and policy and allocate their own SIDs and another where a
> mapping server does it for the routing domain.
> 
> yes, that is correct. The latter is used mainly during migration from LDP to SR.

The mapping server could actually be used to advertise global SIDs for all the SR-capable nodes as well (see http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00). In this way, the potential risk of global SID allocation collision can be avoided. 

Best regards,
Xiaohu

---

From: Anton Smirnov <[email-masked]>
Date: Tue, 08 Jul 2014 20:08:12 +0200

Hi Peter,
    in current text ranges are not required to be processed and I think 
this kills their potential usage:

    If multiple Prefix-SIDs are advertised for the same prefix, the
    receiving router MUST use the first encoded SID and MAY use the
    subsequent ones.

(and similar text for inter-area LSA origination).
    Subsequent prefixes may be used or may be ignored. And if they are 
ignored then it is originator's fault, receiver has all rights to ignore 
them. If the mapping server wants to ensure every router installs prefix 
attributes then it has no choice but to break the range and advertise 
each prefix individually.
    So IMO ranges processing must be required on every step, otherwise 
they will never be used.

 > may extend the applicability to the range if required, so the scope is

    That what makes ranges counter intuitive. Intuitive hierarchy is 
object on the top and then subordinate items describing properties of 
the object:

Object ---
          |
          |- attribute1
          |- attribute2

But the current scheme does not define object at the top of the 
hierarchy, real object is defined together with property:

Anchor ---
          |
          |- range-of-objects-and-attribute1
          |- range-of-objects-and-attribute2

There are three problems with this representation:
1. Anchor (i.e. top level TLV) is not enough to determine which objects 
(i.e. prefixes) are affected and which are not
2. Set of objects (i.e. the range) may be different in each sub-TLV thus 
raising concerns of ambiguity
3. Text requires that anchor is advertised only once but there is no 
requirement that ranges advertised for different anchors cannot overlap

It would have been more logical to define range in the "OSPF Extended 
Prefix TLV" header itself, not in each sub-TLV. This specifies the 
object (i.e. the range) in the topmost TLV and resolves problems 
mentioned above.

Anton

On 07/03/2014 10:09 AM, Peter Psenak wrote:
>> It seems there are two distinct deployment scenarios - one where SR
>> routers are given a range and policy and allocate their own SIDs and
>> another where a mapping server does it for the routing domain.
>
>>>>         6. Section 4.2 - I really don’t like having his sub-TLV
>>>> redefine the subsuming top-level TLV as a range of prefixes of the
>>>> same length rather than a single prefix. Although this is my first
>>>> serious reading of the draft, this encoding seems really unwieldy
>>>> and, in practice, I’d expect the range size always advertised as 1.
>>>> We can discuss this more in Toronto.
>>>
>>> What you need in such case is component prefix/length plus the number
>>> of components - OSPF Extended Prefix TLV gives you the component info
>>> and Prefix SID Sub-TLV "Range Size' gives you the number of components.
>>
>> I understood it but I don’t like the sub-TLV extending the
>> specification of the higher level TLV. I especially don’t like it
>> since the top-level TLV is a generic mechanism to advertise
>> attributes.  When additional attributes are defined, it begs the of
>> whether or not they apply solely to the prefix or to the range.
>
>>> We could have defined a separate top level TLV in OSPF Extended
>>> Prefix LSA for the advertisement of range of components, but it looks
>>> to me that would be an overkill.
>>
>> I would have preferred that. When the SID attributes are embedded
>> (OSPFv3 and ISIS), I think the semantics are even more unnatural since
>> reachability MAY be advertised for the prefix while SID mapping is
>> being advertised for the range.
>
>>> Current encoding of Prefix SID Sub-TLV gives us all the flexibility
>>> we need. In addition it matches what ISIS has done.
>>
>>>>         7. Section 4.2 - Shouldn’t the reference for the mapping
>>>> server be the “Segment Routing Architecture” rather than the
>>>> “Segment Routing Use Cases”? In general, the usage of a mapping
>>>> server and the scope of assignment needs to be described better
>>>> somewhere (not in the OSPF encoding document).
>>>
>>> will fix the reference
>>>
>>>>
>>>>         8. Section 6 - It would seem that an entity calculating a
>>>> multi-area SR path would need access to the topology for all the
>>>> areas and the SID would need to be globally assigned? Right?
>>>
>>> correct.
>>>
>>>>         9. Section 6.2 - In standard OSPF, inter-area summary
>>>> propagation only applies to inter-area routes learned over the
>>>> backbone. Is this any different?
>>>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: Peter Psenak <[email-masked]>
Date: Tue, 08 Jul 2014 22:04:51 +0200

Anton,

please see inline:

>     receiving router MUST use the first encoded SID and MAY use the

I do not see any connection between ranges and the above text. Above 
text says that if there are multiple prefix SIDs advertised, for a 
single prefix, every implementation MUST process at least the first one. 
Typically only a single SID will be advertised for each prefix 
regardless of the range being 1 or more.

>     Subsequent prefixes may be used or may be ignored. And if they are

there are no subsequent prefixes. Each prefix is advertised in a 
separate top level TLV and will have it's own prefix-SID sub-TLV, only 
belonging to that prefix.

>     So IMO ranges processing must be required on every step, otherwise

please see above.

>  > may extend the applicability to the range if required, so the scope is

the way to look at it is that the top-level TLV always advertises a 
single prefix in a form of prefix/length. Nested sub-TLVs have their own 
data, which are interpreted based on the sub-TLV specification, they do 
not change what is in the top-level TLV. The fact that some sub-TLV has 
a count variable and use the prefix/mask as starting point makes no 
impact on the top-level data.

> (i.e. prefixes) are affected and which are not

actually it is enough. We are not changing or replacing the top-level 
data. We are just using it differently - for prefix-SID sub-TLV the 
prefix/length in the top-level TLV is used as a 'start' object.

> raising concerns of ambiguity

this does not introduce any more ambiguity then any other encoding which 
includes prefix/mask/count variables.

> requirement that ranges advertised for different anchors cannot overlap

actually there is no reason why they can not overlap. We have overlaps 
today with prefix/mask semantics as well and we deal with them.

> object (i.e. the range) in the topmost TLV and resolves problems

we wanted to preserve the prefix/length semantics well known from 
current OSPF. Making size mandatory would be a significant deviation 
from the current OSPF spec.

Prefix-SID 'count' semantics is something specific to the SID and is 
more of an exception and IMHO should not force us to to deviate from 
representation we are used to work with.

thanks,
Peter

---

From: Anton Smirnov <[email-masked]>
Date: Wed, 09 Jul 2014 09:35:07 +0200

Hi Peter,
    I don't understand your answers. Let me give an example of encoding:

Extended Prefix TLV
  192.0.2.1/32
     Prefix SID Sub-TLV
      Range 2
     SID/Label Binding sub-TLV
      Range 4

Extended Prefix TLV
  192.0.2.4/32
     Prefix SID Sub-TLV
      Range 1
     SID/Label Binding sub-TLV
      Range 1

This is valid encoding per current text and it expands into:

192.0.2.1 - 1 SID 1 Binding
192.0.2.2 - 1 SID 1 Binding
192.0.2.3 - 1 Binding
192.0.2.4 - 1 SID 2 Bindings

Obviously this encoding is very difficult to work with because ranges 
are different for attributes, because prefix 192.0.2.4/32 is served by 
two ranges.

It is more logical to define range as part of top-level TLV:

Extended Prefix TLV
  Prefix/mask; Range
     Prefix SID Sub-TLV
      SID
     SID/Label Binding sub-TLV
      Binding

Anton

---

From: Peter Psenak <[email-masked]>
Date: Wed, 09 Jul 2014 10:21:34 +0200

Hi Anton,

please see inline:

>     I don't understand your answers. Let me give an example of encoding:

the fact you have two SIDs or two Bindings for a single prefix is not a 
result of the current encoding. Moving the 'range' to top level TLV is 
not going to address it - you can have a top level TLV with 
192.0.2.1/32/4 and 192.0.2.4/32/1 resulting in the exactly the same 
situation.

> It is more logical to define range as part of top-level TLV:

as I mentioned in the previous email, we want to preserve the prefix 
representation by prefix/length in top-level TLV as that is sufficient 
for almost all attributes. If people do not like the range in the Prefix 
SID and SID/Label Binding sub-TLVs, then I prefer to define a new top 
level TLV that would be used to advertise attributes for a prefix block, 
which would be represented by prefix/length/count. I'm afraid it will 
not be used for anything except the Prefix SID & SID/Label Binding 
sub-TLV though - history shows we never needed such prefix block in the 
past.

thanks,
Peter