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
