Re: [OSPF] [spring] fwd: New Version Notification for draft-xu-ospf-global-label-sid-adv-00.txt

[Peter Psenak <[e-mail]>]

Hi Xuxiaohu,

please see inline:

On 2/11/14 03:12 , Xuxiaohu wrote:
> Hi Peter,
>
> Sorry for late response due to a long holiday.
>
>> -----邮件原件-----
>> 发件人: Peter Psenak [mailto:[e-mail]]
>> 发送时间: 2014年1月29日 18:29
>> 收件人: Xuxiaohu
>> 抄送: [e-mail]; [e-mail]
>> 主题: Re: [spring] [OSPF] fwd: New Version Notification for
>> draft-xu-ospf-global-label-sid-adv-00.txt
>>
>> Xuxiaohu,
>>
>> On 1/29/14 10:58 , Xuxiaohu wrote:
>>>
>>>
>>>> -----邮件原件-----
>>>> 发件人: Peter Psenak [mailto:[e-mail]]
>>>> 发送时间: 2014年1月29日 17:24
>>>> 收件人: Xuxiaohu
>>>> 抄送: [e-mail]; [e-mail]
>>>> 主题: Re: [spring] [OSPF] fwd: New Version Notification for
>>>> draft-xu-ospf-global-label-sid-adv-00.txt
>>>>
>>>> Xuxiaohu,
>>>>
>>>> On 1/29/14 10:16 , Xuxiaohu wrote:
>>>>>
>>>>>
>>>>>> -----邮件原件-----
>>>>>> 发件人: Peter Psenak [mailto:[e-mail]]
>>>>>> 发送时间: 2014年1月29日 17:11
>>>>>> 收件人: Xuxiaohu
>>>>>> 抄送: [e-mail]; [e-mail]
>>>>>> 主题: Re: [spring] [OSPF] fwd: New Version Notification for
>>>>>> draft-xu-ospf-global-label-sid-adv-00.txt
>>>>>>
>>>>>> Xiaohu,
>>>>>>
>>>>>> On 1/29/14 09:53 , Xuxiaohu wrote:
>>>>>>> For example, assume a label block {1000, 1999} is allocated for
>>>>>>> prefix
>>>>>> segments by almost all SR routers and a global label 1005 is
>>>>>> allocated to a given prefix segment, for a given seldom SR router
>>>>>> which couldn't preserve the above label block and allocates a
>>>>>> different label block (e.g., {2000, 2999}) instead, a local label
>>>>>> corresponding to that global label (or that prefix segment) could
>>>>>> be calculated through offsetting, i.e., the result is 1005+
>>>>>> (2000-1000)=2005. In this way, there is no need for introducing the
>>>>>> Index concept anymore and therefore the architecture becomes much
>>>>>> easy to understand. More importantly, compared to the index binding
>>>>>> advertisement, the label binding advertised by the IGP is exactly
>>>>>> the same as that in the label forwarding table for those most SR
>>>>>> routers which have allocated the above common label block, which is
>>>>>> much
>>>> beneficial when doing troubleshooting. This approach does not violate
>>>> the strongest MPLS dogma (i.e., labels MUST be local) while!
>>>>>>     taking in
>>>>>> to account the actual situation, IMHO
>>>>>>
>>>>>> above would require the "seldom SR router" to know the offset from
>>>>>> the SRGB used by other routers. How do you envision that to be learned?
>>>>>
>>>>> Hi Peter,
>>>>>
>>>>> I don't think it's a big problem. The common SRGB could either be
>>>>> manually
>>>> configured on the seldom SR router or advertised by the MS.
>>>>
>>>> manual configuration is not an option - just imagine you have
>>>> multiple "seldom SR routers", each having a different label block.
>>>> Now you not only need an offset for "common" block, but also offset
>>>> between label blocks used on these "seldom SR routers".
>>>
>>> Peter,
>>>
>>> Why do you need offset between label blocks used on these seldom SR routers?
>> The common block is the only frame of reference, IMO.
>>
>> let's imagine you have two "seldom SR routers", A and B, directly connected. A is
>> using label block 1000-2000, B is using 2000-3000. For simplicity, let's assume
>> rest of the routers use the block 0-1000.
>>
>> Now let's imagine you have a prefix X, which is advertised with label 25 from a
>> router that uses the common block (0-1000). On A you configure the offset
>> +1000, so it allocate a local label of 1025 for X. Now A wants to send a traffic for
>> X via B. You would have to configure on A the offset of B as +2000 (against the
>> common block) or as +1000 (against the A's block), so when A sends a traffic to
>
> Only against the common block since it is the only frame of reference.

'only' is a bit misleading here. The bottom line is that on each router 
that peers with 'seldom SR' router, there would need to be a specific 
config added - IMHO that is not an acceptable solution.


>
>> B, it will use label 2025.
>> No matter which method of specifying the offset you use, the point is that on A
>> you need to know the offset of all "seldom SR" routers that you may end up
>> sending traffic to - either directly, or indirectly. Such a configuration model does
>> not scale.
>
> Those "seldom SR" routers would advertise their own blocks. And only those "seldom SR" routers need to advertise their own blocks. In this way, there is no need to introduce the index space anymore, and therefore the architecture and the troubleshooting become much simpler given the assumption that only seldom SR routers could not allocate that common block.

I believe it is simpler from both implementation and deployment 
perspective to consistently advertise the block from all routers.

thanks,
Peter
>
> Best regards,
> Xiaohu
>
>>
>>>
>>>> Once you start to advertise it, you are back to the model we have
>>>> already, but you made it even worse with offsets.
>>>
>>> I don't think so. Take the above situation as an example, in the index binding
>> mode, you could allow the most SR routers to advertise its label range starting
>> with zero to achieve the above effect (although it conflicts with the definition of
>> label range). However, for the seldom SR router, what label range should it
>> advertise?
>>
>> the simplest model is for every router (seldom or common) to advertise its label
>> block.
>
>> regards,
>> Peter
>>
>>>
>>> Best regards,
>>> Xiaohu
>>>
>>>> regards,
>>>> Peter
>>>>
>>>>>
>>>>> Best regards,
>>>>> Xiaohu
>>>>>
>>>>>> regards,
>>>>>> Peter
>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Xiaohu
>>>>>
>>>
>