Robert,
On 8/26/15 10:49 , Robert Raszuk wrote:
Peter,
Your example is ok for the indexed srgb case. Yes I agree that in such
case what you present seems fine.
But if (as most operators I spoke with) are planning deployment of
absolute srgb why would I need to introduce indexes at all to deal with
per topology blocks rather then just advertise basic index less absolute
blocks to start with.
not sure what absolute SRGB means.
Offsets are used to simplify the configuration and as such are optional.
thanks,
Peter
Thx,
r.
On Wed, Aug 26, 2015 at 10:43 AM, Peter Psenak <[email protected]
<mailto:[email protected]>> wrote:
Hi Stephane,
On 8/26/15 09:46 , [email protected]
<mailto:[email protected]> wrote:
Hi Peter,
Yes I need to allocate a new SRGB, but my index space will be
contiguous and I will be able to use the index 51 in each scope.
configuration wise same can be achieved with the offsets - think of
it as an internal SRGB local to the box. The only difference is what
is advertised.
1. per topology SRGB
4 SRGBs:
100-149 topology 1
150-199 topology 2
200-249 topology 1
250-299 topology 2
prefix51, topology 1 - SID index 51 -> SID 200
prefix51, topology 2 - SID index 51 -> SID 250
What is advertised:
4 SRGBs (as above), prefix51 SID index 51
-----------
2. Per topology offset
SRGB 100-299
4 offsets (local to the box):
0-49 topology 1
50-99 topology 2
100-149 topology 1
150-199 topology 2
prefix51, topology 1 - SID index 51 -> SID 200
prefix51, topology 2 - SID index 51 -> SID 250
What is advertised:
1 SRGB (as above), 2 prefix SIDs - 101, 151
thanks,
Peter
-----Original Message-----
From: Peter Psenak [mailto:[email protected]
<mailto:[email protected]>]
Sent: Wednesday, August 26, 2015 09:28
To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen; Pushpasis Sarkar;
SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain
Hi Stephane,
On 8/26/15 01:28 , [email protected]
<mailto:[email protected]> wrote:
Hi Peter,
As I already pointed to Les, using an offset creates some
holes in index space that we need to manage when extending a
block.
Let's say that we have SRGB [100-199] (to simplify) and you
divide your block in two so you will have topology #1 using
[100-149] and topology #2 using [150-199] using an offset of 50.
Now I need to add a 51th node in my network, I cannot use
index 51 because it will overlap with topology#2 :(, so I
will need to skip indexes from 51 to 100, and restarts my
numbering with index 101. This management of holes is not
automated.
how is this different to the case where you have two per
topology SRGBs of 100-149 and 150-199 and now you need 51st SID?
It is exactly the same problem. You need to allocate a new SRGB.
thanks,
Peter
Best Regards,
Stephane
-----Original Message-----
From: Peter Psenak [mailto:[email protected]
<mailto:[email protected]>]
Sent: Tuesday, August 25, 2015 13:18
To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen; Pushpasis Sarkar;
SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within
a domain
Hi Stephane,
On 8/25/15 12:58 , [email protected]
<mailto:[email protected]> wrote:
Hi Peter,
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.
Could you explain how ? Based on past discussions, it
does not seem to be so easy.
simply by associating an offset and size from SRGP on a per
topology basis.
Example:
SRGB 1600-24000
I would assume that when you start to assign your SIDs for
the default topology, you would not pick random values, but
start from the beginning. So let' assume you are using 16001
to 16500 for nodes in default topology.
Now you need to add a new topology. You configure and offset
of 2k for it, so the advertised SIDs for the new topology
would start from 18001.
If we assume that the 2k would be a reasonable size for each
topology you can have 4 topologies with 2k SIDs per topology.
If for whatever reason you run out of the SID space in any
topology, you can configure another offset for those SIDs
which do not fit into the existing range for such topology.
All of the above is internal to the node and no per topology
SRGB advertisement is required. You advertise unique SID on
a per prefix and per topology basis, but you do not need to
configure each SID manually.
Al you need to configure is the single prefix SID and per
topology offset/size. It gives you the same simplicity for
configuration as per topology SRGB, but without the need to
advertise SRGB per topology.
thanks,
Peter
Best Regards,
Stephane
_____________________________________________________________________
_ ___________________________________________________
Ce message et ses pieces jointes peuvent contenir des
informations
confidentielles ou privilegiees et ne doivent donc pas
etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu
ce message
par erreur, veuillez le signaler a l'expediteur et le
detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration, Orange
decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
This message and its attachments may contain confidential or
privileged information that may be protected by law;
they should not be distributed, used or copied without
authorisation.
If you have received this email in error, please notify
the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for
messages that have been modified, changed or falsified.
Thank you.
______________________________________________________________________
___________________________________________________
Ce message et ses pieces jointes peuvent contenir des
informations
confidentielles ou privilegiees et ne doivent donc pas etre
diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce
message
par erreur, veuillez le signaler a l'expediteur et le
detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration, Orange
decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
This message and its attachments may contain confidential or
privileged information that may be protected by law; they
should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the
sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages
that have been modified, changed or falsified.
Thank you.
.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des
informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si
vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
This message and its attachments may contain confidential or
privileged information that may be protected by law;
they should not be distributed, used or copied without
authorisation.
If you have received this email in error, please notify the
sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that
have been modified, changed or falsified.
Thank you.
.
_______________________________________________
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
