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

[Acee Lindem <[e-mail]>]

Hi Peter, Anton, 

-----Original Message-----
From: Peter Psenak <[e-mail]>
Date: Wednesday, July 9, 2014 at 1:21 AM
To: Anton Smirnov <[e-mail]>, Ericsson <[e-mail]>
Cc: OSPF - OSPF WG List <[e-mail]>
Subject: Re: [OSPF] Comments
draft-ietf-ospf-segment-routing-extensions-00.txt

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

Is this the only downside of a separate range top-level TLV? If so, then
it seems this would provide a cleaner encoding.I don¹t like allowing range
attributes and single prefix attributes to be mixed. Even with the current
encoding, we are going to have to handle the ambiguity of overlapping
ranges so I don¹t see a separate top-level TLV and adding more complexity.

Thanks,
Acee 


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