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 >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>> . >>>>> >>>> >>> . >>> >> > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
