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

[Acee Lindem <[e-mail]>]

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. 

       2. The usage of the advertised Weight references the “Segment Routing Architecture”. However, there is no description of weight usage there.

       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.  

       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.

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

       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. 

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

       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? So rules are primarily for the population of the forwarding plane. Right? 

       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? 

Thanks,
Acee