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

[Peter Psenak <[e-mail]>]

Hi Acee,

On 7/9/14 11:50 , Acee Lindem wrote:

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

ok, let's discuss during IETF.

thanks,
Peter


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