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

[Anton Smirnov <[e-mail]>]

    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


On 07/08/2014 10:04 PM, Peter Psenak wrote:
> Anton,
>
> please see inline:
>
> On 7/8/14 20:08 , Anton Smirnov wrote:
>>     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.
>
> 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.
>
>>
>> (and similar text for inter-area LSA origination).
>>     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.
>
>> 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.
>>
>
> please see above.
>
>>
>>
>>
>>  > 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.
>
> 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.
>
>>
>>     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
>
> 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.
>
>> 2. Set of objects (i.e. the range) may be different in each sub-TLV thus
>> raising concerns of ambiguity
>
> this does not introduce any more ambiguity then any other encoding which
> includes prefix/mask/count variables.
>
>> 3. Text requires that anchor is advertised only once but there is no
>> 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.
>
>>
>> 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.
>
> 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
>
>
>
>>
>> Anton
>>
>>
>> On 07/03/2014 10:09 AM, Peter Psenak wrote:
>>> Hi Acee,
>>>
>>> please see inline:
>>>
>>> On 7/2/14 19:17 , Acee Lindem wrote:
>>>> 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.
>>>
>>> yes, that is correct. The latter is used mainly during migration from
>>> LDP to SR.
>>>
>>>
>>>
>>>>>>         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.
>>>>>
>>>>> 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.
>>>
>>> still, having a mechanism to compact the advertisements if possible
>>> looks appealing.
>>>
>>>>
>>>>>
>>>>> 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.
>>>
>>> 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.
>>>
>>>>
>>>>>
>>>>> 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.
>>>
>>> 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
>>>
>>>>
>>>>> 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
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>         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.
>>>>>
>>>>>> 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
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Acee
>>>>>>
>>>>>>
>>>>>>
>>>>>> .
>>>>>>
>>>>>
>>>>
>>>> .
>>>>
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ospf
>> .
>>
>