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

[Peter Psenak <[e-mail]>]

Hi Anton,

please see inline:


On 7/9/14 09:35 , Anton Smirnov wrote:
>     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.

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:
>
> Extended Prefix TLV
>   Prefix/mask; Range

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

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