Robert,
On 8/25/15 13:14 , Robert Raszuk wrote:
Peter,
If on a given node I run OSPF and ISIS and I advertise differe SRGB
block with each of them what is really "per node scope"
per node means per IGP. Nobody can prevent you to advertise different
SRGBs in different IGPs.
thanks,
Peter
Each igp thinks it is per node in their understanding of what the node
is, but between them I see no relation at all.
It would be rather a mistake to assue both igp have congruent base
topologies which such condition seems not easy to avoid if you treat
block as something sitting above both of them.
Thx,
R.
On Aug 25, 2015 12:53 PM, "Peter Psenak" <[email protected]
<mailto:[email protected]>> wrote:
Robert,
On 8/25/15 11:50 , Robert Raszuk wrote:
So as long you can also configure multiple SRGBs per node the
discussion
is over :)
the discussion is not about advertising multiple SRGBs, but about
the scope of the SRGB advertisement - currently it is a per node.
The fact that you can advertise multiple SRGBs does not change its
scope.
thanks,
Peter
But that perhaps is a topic outside of IETF and one should express
preferences directly with their vendors.
Thx Peter !
R.
On Aug 25, 2015 11:44 AM, "Peter Psenak" <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
On 8/25/15 11:36 , Robert Raszuk wrote:
Peter,
In first sentence you say "single block" in second one
you say
"multiple
blocks" so which one it is ?
you can advertise multiple SGRBs per node.
Peter
Thx,
R.
On Aug 25, 2015 11:25 AM, "Peter Psenak"
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> wrote:
Robert,
On 8/25/15 11:05 , Robert Raszuk wrote:
Peter,
"You can partition it in many ways, but the
block is
just one."
As you recall mpls architecture does not have such
limitation.
You can
have per interface overlapping label space.
Likewise to me SRGB blocks for MT or MI do not
need to be
continuos what
your earlier suggestion regarding offset would
result with.
So I think the crux of this entire debate is
this: are we
allowing non
continous SRGB pools per node or not (say one per
topology).
No matter how many partitions you have, still it's
a single
block
consisting of multiple partitions.
Yes, we are allowing non continuous SRGB per node
- you can
advertise multiple SRGB blocks per node - please
see the
OSPF/ISIS
SR extensions.
thanks,
Peter
If not what you and Les are saying may indeed
be ok,
however for
deployment flexibility I would rather tend to
opt for it.
Best,
R.
On Aug 25, 2015 9:48 AM, "Peter Psenak"
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
<mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>> wrote:
Hi Eric,
please see inline:
On 8/24/15 17:08 , Eric C Rosen wrote:
> [Peter] What you need is a different
label for same
prefix per
> MTID/algorithm - that we agree on. To
achieve
that you
either need
> single SID and per MTID/algorithm SRGB or
single SRGB
with per
> MTID/algorithm SIDs.
>
> Peter, my reading of the architecture
is that a
prefix-SID is
"global"
> and that an SRGB is per-node.
Prefix SID has a prefix scope, SRGB has a
node scope.
>
> This seems to be at odds with the way the
control plane
encodings
have
> been defined, which suggests that
either the
architecture or the
> encodings needs adjustment.
I do not see any odds with the encodings.
Current IGP
encoding supports
SRGB per each instance of the IGP.
>
> Recall that this discussion started with a
claim that
even one
SRGB per
> algorithm was in violation of the
architecture.
SR architecture never claimed per
algorithm SRGB.
>
> If we assume that the signaling drafts
capture
what the
architecture is
> supposed to have said, then I see the
following
issues.
>
> 1. If a new topology is added by use
of the MT
features
of an
IGP, then
> a new set of prefix-SIDs must be
provisioned. This
seems like a
major
> provisioning task. The alternative
would be to
have an
SRGB per
> topology; then when you add a new
topology, you
only
have one
quantity
> to provision (or one per platform
perhaps). I
hear some
hand-waving
> about how easy it is to provision new
prefix-SIDs for
every new
> topology, but ...
I will keep repeating myself that such
provisioning can be made
automatic, so the above point is not really
convincing to me.
>
> 2. The multi-topology feature of an
IGP is just
one way
of setting up
> multiple "underlays". If you set up two
underlays by
using two
> instances of OSPF, you can assign a
SRGB to each
underlay. If
you set
> up two underlays by using two
topologies in one
instance
of OSPF, you
> can't. Why the difference? I find
this really
confusing -- exactly
> what is the scope of uniqueness of a
prefix-SID
supposed
to be?
the difference is because SRGB is a node
property
and SID
is a prefix
property. Each prefix can have many
attributes and
SID is
just another
prefix attribute. It's similar to prefix
metric,
which has
a per
topology scope. SRGB is like any other node
capability.
This actually
fits very well in the existing IGP
architecture - node
capabilities are
never per topology. At the end you only
have a
single label
block on a
device. You can partition it in many
ways, but the
block is
just one.
>
> [Peter] The SR architecture from the
very beginning
assumed per
> MTID/algorithm SID, not per
MTID/algorithm SRGB
and IGP
encoding has
> been designed with that in mind.
>
> Can you point to a place in the
architecture
document
where it
says that
> SIDs are only "global" per MTID/algorithm
and/or that
SRGBs are
> per-algorithm?
form
draft-ietf-spring-segment-routing-04.txt:
"SR Global Block (SRGB): local property
of an SR
node."
"IGP-prefix Segment, Prefix-SID: an
IGP-Prefix
Segment is
an IGP
segment attached to an IGP prefix.
Above makes it clear to me that SRGB has
a per node
property and is
advertised by IGP as such. Prefix-SID is
a prefix
property
and as such
can be advertised per MTID topology, as
any other
prefix
attribute.
IGP encodings for OSPF and ISIS have been
designed
by a
team of people
from multiple vendors and some of them
contributed
to the SR
architecture document as well - the fact
that we
designed
the IGP
encoding the way it is clearly indicates
what was
the common
understanding of the SR architecture.
We can surely improve the wording in the SR
architecture
document if you
feel so.
>
> [Peter] If you add MTID and algorithm
in SRGB
as well,
you end up
with
> the MTID and algorithm fields at two
different
TLVs for
the same
> topology - inside SRGB and inside the
Prefix SID
sub-TLV, which is
> clearly redundant.
>
> I don't really understand what problem
is being
stated
above.
the problem is that you create an
overlap, where
both SRGB and
prefix-SID would be carrying the same
values. I
suppose you
agree that
we do not need these fields to be
associated with
both SRGB
and SIDs.
>
> [Pushpasis] I am trying give both
options to a
operator
(i.e. Single
> SRGB with per-topology SID-index as
well as single
SID-index with
> per-topology SRGB). Depending on which
one the
operators
prefer,
one of
> them becomes redundant.
>
> [Peter] I'm not sure we want to advertise
redundant data
to allow
more
> configuration flexibility. From both
architecture and
encoding
> perspective it's preferable to pick single
approach.
>
> I see this issue differently. We
already allow
(but do not
require) a
> different SRGB to be assigned to each
instance
of each
routing
> algorithm;
no, we don't. SRGB scope is IGP instance.
There is no
algorithm there.
> but a different SRGB cannot be
assigned to each
topology
of a
> given instance of a given algorithm. This
means there
are already
> multiple ways of assigning SIDs/SRGBs,
with some
restrictions
that don't
> seem to make much sense.
>
> Also I don't think it's a good
trade-off to limit
configuration
> flexibility in order to simplify an
encoding.
>
> [Peter] please bear in mind that there are
implementations out
there in
> the field with the existing encoding.
>
> I'm sure any changes could be made in
a backwards
compatible manner.
to change the existing encoding one would
need a
strong
reason. I do not
see anything which can not be done with the
existing encodings.
thanks,
Peter
>
> [Peter] If you move the MTID/algorithm
fields from
Prefix SID to
SRGB,
> what is the MTID/algorithm fields in
prefix SID
used
for? Having the
> MTID/algorithm fields in both Prefix
SID and
SRGB would be
redundant and
> confusing.
>
> Tthe encoding could be designed to not
only be
backwards
compatible, but
> also to give unambiguous semantics to all
combinations.
>
>
>
>
>
_______________________________________________
spring mailing list
[email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
