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.
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.
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. Current encoding of Prefix SID Sub-TLV gives
us all the flexibility we need. In addition it matches what ISIS has done.
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
