Hi Stephane,
please see inline:
On 8/26/15 12:55 , [email protected] wrote:
Hi Peter,
There are some mix between SIDs and labels in your text.
when I said SID, I meant absolute SID, which in MPLS case becomes a label.
Some comments inline
-----Original Message-----
From: Peter Psenak [mailto:[email protected]]
Sent: Wednesday, August 26, 2015 10:43
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 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
[SLI] I would more think about : prefix51, topology 1 - SID index 51 ->
label 200 ; prefix51, topology 2 - SID index 51 -> label 250
What is advertised:
4 SRGBs (as above), prefix51 SID index 51
[SLI] Agree
-----------
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
[SLI] In this case that's no more an offset, it's more a range of
indexes mapped to others.
it was just one way or representing it, the idea is to split the single
SRGB internally on the box to allow using single index for
configuration. There are certainly other ways of doing it.
It's different from Les's proposal " srgb offset topology 1 1000" which
is just a simple “ADD” operation.
it is the same to what Les proposed, but my example contains multiple
offsets per single topology.
thanks,
Peter
You are creating some indirection table (like for virtual memory
management). It works, but adds some complexity to manage those
indirections.
And so there will be two levels of indirection
Virtual index table for topology#1
Real index table
Label range
[0-49]
[0-49]
[100-149]
[50-99]
[100-149]
[200-249]
Virtual index table for topology#2
Real index table
Label range
[0-49]
[50-99]
[150-199]
[50-99]
[150-199]
[249-299]
Well, managing one level of indirection is already a boring thing from
an operational point of view, adding such complex mapping would not ease it.
When you need to troubleshoot label values (some platforms still have
programming issues unfortunately …), it complexifies …
What is advertised:
1 SRGB (as above), 2 prefix SIDs - 101, 151
thanks,
Peter
>
> -----Original Message-----
> From: Peter Psenak [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]]
>> 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.
>
> .
>
_________________________________________________________________________________________________________________________
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]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
