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. See inline for #6.
On Jul 2, 2014, at 7:35 AM, Peter Psenak <[email protected]> wrote: > Hi Acee, > > please see inline: > > On 7/1/14 23:00 , Acee Lindem wrote: >> Hi Peter, >> >> I’ve reviewed the OSPF Segment Routing WG draft and have some comments. >> >> 1. Can you describe the usage of algorithm in the Segment Routing >> domain? An SR capable router advertises the algorithms it supports and an >> algorithm is associated with a Prefix-SID. However, the usage of this >> information is not described anywhere and it is guaranteed that there will >> be many different interpretations. > > filsfils-spring-segment-routing-use-cases will be updated to include the > usage of algorithm. > >> >> 2. The usage of the advertised Weight references the “Segment Routing >> Architecture”. However, there is no description of weight usage there. > > weight is used for influencing load-balancing across multiple adj-sid's to > the same node. > > filsfils-spring-segment-routing-use-cases will be updated to include the > usage of weight. > >> >> 3. Section 3.2 - the range advertisement seems a bit unnatural. Why >> is it assumed that all the advertised ranges have the same size? It would >> seem more intuitive that individual ranges are defined by the <size/starting >> SID> tuple. > > there is a typo in the text: > "SID/Label Sub-TLV MAY appear multiple times" will be changed to "SID/Label > Range TLV MAY appear multiple times", which I believe will address your > comment. > >> >> 4. Section 4.2 - Can you please make the P-flag the NP-Flag since the >> set value indicates not to perform the PHP operation? If you want to keep it >> the P-Flag, the set value should mean to perform the PHP. > > sure, will rename to NP-flag > >> >> 5. Section 4.2 and 5.2 - The Segment Routing architecture defines >> adjacency SIDs as having local significance. Yet the L-Flag allows this to >> be encoded as global. Similarly, it would seem that a prefix SID would >> normally have global significance and local significance would be an >> exception (e.g., possibly a loopback address accessible only from the >> advertising OSPF router). > > the architectre draft will be corrected to reflect that both prefix-sid and > adj-sid can be global or local. > >> >> 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. > > 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. > > 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. > 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
