Thanks a lot Les for the elaborate explanation
One small addition to what Les mentioned. The functionality proposed by
the draft can be achieved by having a base prefix-SID index and then
configuring an offset (instead of an SRGB) for each topology/algorithm
pair from that base prefix-SID index value. Based on the configured
offset, the router would then calculate the corresponding prefix-SID
index for each topology/algorithm pair and advertise it using existing
mechanisms
Note that the above is NOT a suggestion to use the offset mechanism to
configure prefix-SID indices. The objective is to show that the draft
does not offer enough benefits to warrant all the questions marks that
are outlined in Les's email.
Thanks
Ahmed
On 11/9/2015 1:11 AM, Les Ginsberg (ginsberg) wrote:
Chris -
I have a number of questions - but in order to properly frame them I need to
recount some history - please bear with me.
In the very early days of SR there was a proposal to reserve a fixed label
range on all routers (16000 - 23999) for the use of SR. This seemed workable
but there was concern that the same range would not be available on all routers
so the SR community agreed that we needed to allow the advertisement of a
different SRGB range on each SR capable router.
Then, another concern was raised that a single contiguous range large enough to
meet the SR requirements might not be available on all routers and therefore we
needed to support the advertisement of multiple SRGB ranges from a given node.
This capability has been added - though it has also raised other concerns
regarding how many ranges might be enough and how to deal with inconsistencies
(overlaps) in the advertised ranges should some error occur.
Now, in support of multiple algorithms/topologies, this draft proposes that
algorithm/topology specific SRGBs be advertised - and that to fully get the
benefits of consistent SID assignment for the same prefix across
algorithms/topologies (the major goal of this draft) that all routers be able
to support identical ranges for each algorithm/topology. (Section 5 goes into
this in detail) - and to be able to allocate new ranges for newly configured
algorithms/topologies on demand. Section 6 goes on to suggest that it would be
a wonderful goal if all routers could assign the same base label/range to each
algorithm/topology so that the labels could be derived algorithmically (though
you admit this may not always be possible).
My first question is how do you reconcile this requirement for consistency on
all nodes with the earlier decisions to support inconsistency as regards SRGB
base values/range sizes?
My second question is associated with the assumption of a single "node_index" per node. I
for one would be delighted if we could get agreement on using a single host address/node (or at
least one per AF) for all traffic to that node. But this does not meet the deployment requirements
in all cases and so we support multiple "node_indeces" for a given node. This means that
we do not map SIDs to nodes - we map SIDs to prefixes. So it is conceptually more straightforward
and less problematic to configure SIDs for prefix ranges. This is in fact how SRMS advertisements
are constructed i.e.
(Prefix/Prefix length, Starting SID, Range)
How would you propose to incorporate this style of SID assignment into your
algorithms? Do you assume a maximum number of node-sids required for every node
in the network and require the range for each algorithm/topology be sized large
enough for the worst case? This seems potentially wasteful - especially if a
deployment chooses to use a particular address for a topology as a traffic
differentiator.
My third question relates to the algorithm/topology independence of the SID
assignment that you propose. Throughout the document you assume that you have a
single SID for a given prefix and you simply add the appropriate
algorithm/topology specific SRGB base value to this SID to derive the
forwarding label. However, current protocol advertisements for SIDs include
both algorithm and topology as context for the SID. This reflects the current
SR architecture which has been defined with algorithm/topology as an explicit
context for a SID. Your proposal fundamentally changes this and therefore all
existing encodings of SID advertisements (prefix reachability, SRGB, SRMS
advertisements) would have to be changed in a non-backwards compatible way in
order to support your proposal. Other than definition of a new SRGB
advertisement, you do not discuss this in the draft. How do you intend to
address this major issue?
Les
-----Original Message-----
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Chris Bowers
Sent: Monday, October 05, 2015 12:31 PM
To: spring@ietf.org
Subject: [spring] FW: New Version Notification for draft-bowers-spring-adv-
per-algorithm-label-blocks-02.txt
SPRING WG,
There was quite a lot of discussion in person after we presented draft-
bowers-spring-adv-per-algorithm-label-blocks-01 in Prague, and there was
also much discussion on this list about the issue raised by this draft. We have
made two main additions to this revision of the draft to further this
discussion.
1) We have included discussion of multiple topologies in addition to multiple
algorithms, and we have modified the proposed ISIS extension to handle
both multiple topologies and multiple algorithms.
2) We have tried to accurately describe a proposal, which was outlined on
this list, for managing the assignment of per-topology/per-algorithm node
index values, which we refer to as the "configured offset mapping method".
We welcome feedback from the working group on this draft.
Thanks,
Chris
-----Original Message-----
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, October 05, 2015 2:05 PM
To: Uma Chunduri <uma.chund...@ericsson.com>; Hannes Gredler
<han...@juniper.net>; Pushpasis Sarkar <psar...@juniper.net>; Chris
Bowers <cbow...@juniper.net>; Chris Bowers <cbow...@juniper.net>;
Uma Chunduri <uma.chund...@ericsson.com>; Pushpasis Sarkar
<psar...@juniper.net>; Hannes Gredler <han...@juniper.net>
Subject: New Version Notification for draft-bowers-spring-adv-per-
algorithm-label-blocks-02.txt
A new version of I-D, draft-bowers-spring-adv-per-algorithm-label-blocks-
02.txt
has been successfully submitted by Chris Bowers and posted to the IETF
repository.
Name: draft-bowers-spring-adv-per-algorithm-label-blocks
Revision: 02
Title: Advertising Per-Topology and Per-Algorithm Label Blocks
Document date: 2015-10-05
Group: Individual Submission
Pages: 14
URL: https://www.ietf.org/internet-drafts/draft-bowers-spring-adv-
per-algorithm-label-blocks-02.txt
Status: https://datatracker.ietf.org/doc/draft-bowers-spring-adv-per-
algorithm-label-blocks/
Htmlized: https://tools.ietf.org/html/draft-bowers-spring-adv-per-
algorithm-label-blocks-02
Diff: https://www.ietf.org/rfcdiff?url2=draft-bowers-spring-adv-per-
algorithm-label-blocks-02
Abstract:
When segment routing is used in a network that is controlled by a
link state IGP (such as ISIS or OSPF), each node in the network can
be assigned one or more index numbers, known as "node-SIDs". The
node-SIDs are unique within the network, and are known to all the
nodes in the network. If an ingress node has a data packet to be
sent to an egress node, the ingress node may select a node-SID
corresponding to the egress node, and "translate" that node-SID to an
MPLS label. The MPLS label represents a particular path to the
egress node; the path is determined by applying a routing algorithm
to a particular view of the network topology and a particular set of
metric assignments to the links of that topology. The packet can
then be forwarded by pushing the label on the packet's label stack
and transmitting the packet to the next hop on the corresponding path
to the egress node. This document compares two different procedures
for translating a node-SID to the MPLS label that represents a path
chosen by a particular algorithm operating on a particular topology.
It also specifies the ISIS extensions needed to support one of the
procedures (known as the "per-topology/per-algorithm label block"
procedure).
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
