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
