Hi Stephane - Why do need to use different label blocks, i.e., for
different topologies? You have two other simpler options:
1. Just allocate SIDs to <prefix, mt_id> tuples. So if a node has SIDs
[1-10], just allocate a unique SID to each unique combinations of tuple.
2. For a node, allocate ranges of SIDs to a topology rather than
trying to allocate SRGBs. Then the SID would map to whatever the label the
offset correspond to in the local node’s SRGB(s).
Thanks,
Acee
On 8/25/15, 7:28 PM, "spring on behalf of [email protected]"
<[email protected] on behalf of [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.
>
>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] 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.
>
>_______________________________________________
>spring mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
