Hi Peter, Anton, -----Original Message----- From: Peter Psenak <[email protected]> Date: Wednesday, July 9, 2014 at 1:21 AM To: Anton Smirnov <[email protected]>, Ericsson <[email protected]> Cc: OSPF - OSPF WG List <[email protected]> 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 >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/ospf >>>> . >>>> >>> >> . >> > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
