On Jan 28, 2014, at 9:53 AM, Xuxiaohu wrote:
> Hi Peter,
>
>> -----邮件原件-----
>> 发件人: Peter Psenak [mailto:[email protected]]
>> 发送时间: 2014年1月28日 16:15
>> 收件人: Xuxiaohu
>> 抄送: [email protected]; [email protected]; [email protected]
>> 主题: Re: [OSPF] fwd: New Version Notification for
>> draft-xu-ospf-global-label-sid-adv-00.txt
>>
>> Xiaohu,
>>
>>
>> please see inline (##PP):
>>
>>
>> On 1/28/14 04:46 , Xuxiaohu wrote:
>>> Hi Peter,
>>>
>>>> -----邮件原件-----
>>>> 发件人: Peter Psenak [mailto:[email protected]]
>>>> 发送时间: 2014年1月27日 18:08
>>>> 收件人: Xuxiaohu
>>>> 抄送: [email protected]; [email protected]
>>>> 主题: Re: [OSPF] fwd: New Version Notification for
>>>> draft-xu-ospf-global-label-sid-adv-00.txt
>>>>
>>>> Xiaohu,
>>>>
>>>> On 1/27/14 10:49 , Xuxiaohu wrote:
>>>>> Hi Peter,
>>>>>
>>>>>> -----邮件原件-----
>>>>>> 发件人: Peter Psenak [mailto:[email protected]]
>>>>>> 发送时间: 2014年1月27日 16:41
>>>>>> 收件人: Xuxiaohu
>>>>>> 抄送: [email protected]; [email protected]
>>>>>> 主题: Re: [OSPF] fwd: New Version Notification for
>>>>>> draft-xu-ospf-global-label-sid-adv-00.txt
>>>>>>
>>>>>> Xiaohu,
>>>>>>
>>>>>>
>>>>>> 1. draft-psenak-ospf-segment-routing-extensions has already defined
>>>>>> the mapping server functionality - please read the section 4.2 and
>>>>>> 6.1
>>>>>
>>>>> According to the description about mapping servers (see below) which
>>>>> is in -01
>>>> version of the use case draft but is removed in -02 version of that
>>>> draft, it seems that the mapping server is deemed to advertise the
>>>> mappings on behalf of non-SR-capable routers. In contrast, my draft
>>>> proposes to allow the mapping server to allocate and advertise mappings on
>> behalf of SR-capable routers.
>>>> Those two distinct design goals cause different implications on the
>>>> implementation and usage.
>>>>
>>>> that is not true. MS as we support it with existing drafts can be
>>>> used to advertise SID/label for SR capable routers.
>>>
>>> This above argument may be true for the OSPF extension for SR draft since
>>> the
>> Prefix-SID are attached to OSPFv2 Extended Prefix Opaque LSA which is not
>> used for building the normal IP routing table. But I doubt whether the above
>> argument is still true for the ISIS extension for SR draft since the
>> Prefix-SID
>> Sub-TLV is attached to the Extended IP Reachability TLV which is exactly
>> used for
>> building the normal IP routing table, according to the existing description
>> of that
>> draft.
>>
>> ##PP
>> in ISIS, you can use SID/Label Binding TLV to advertise SID/label for prefix
>> for
>> which you do not want to advertise IP reachability.
>
> In the SID/Label Binding TLV, the MT-ID information is missed. I wonder why
> not directly reuse the extended IP reachability TLVs to carry the Label/SID
> bindings by setting the Metric field to a value larger than MAX_PATH_METRIC
> (i.e., 0xFE000000).
we evaluated that option a while ago and discarded because of the complexity.
So, today in ISIS, the SID is advertised with:
. an optional TLV inside TLV135
. the binding TLV
let's keep it simple.
> According to the following specification as defined in [RFC5305] "...If a
> prefix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000,
> see paragraph 3.0), this prefix MUST NOT be considered during the normal SPF
> computation. This allows advertisement of a prefix for purposes other than
> building the normal IP routing table...".
>
> In addition, as stated in the section 2.2 of Prefix-SID Sub-TLV, "The 'Prefix
> SID' is an index to determine the actual SID/label value inside the set of
> all advertised SID/label ranges of a given router. " In section 2.1 of
> SID/Label Sub-TLV, it said "... The SID/Label Sub-TLV is present in multiple
> Sub-TLVs defined in this document and contains a SID or a MPLS Label". In the
> section 2.4 of SID/Label Binding TLV, it said "...X-Flag: Index flag. Set if
> the value of the SID/Label Sub-TLV carries an index. Unset if the value of
> the SID/Label Sub-TLV carries a local SID/Label. " Does the above description
> seem conflicting?
yes, I have updated the drafts and will submit them soon. There's no
mention of the X-flag anymore.
> Furthermore, in case the SID/Label Sub-TLV carries a "local" SID/Label, does
> that mean this Sub-TLV is not suitable for a mapping server to advertise the
> global ID (of whatever format) for a given prefix?
a mapping server is used for advertising prefix labels/SIDs which are
global (even if translated into MPLS data plane this means a local label).
Local SIDs are adjacencies/interfaces which are not advertised by
the mapping server.
s.
>
> Best regards,
> Xiaohu
>
>> regards,
>> Peter
>>
>>
>>>
>>> Best regard,
>>> Xiaohu
>>>
>>>>> "The mappings advertised by an SR mapping server result from local
>>>>> policy information configured by the operator. IF PE3 had been SR
>>>>> capable, the operator would have configured PE3 with node segment
>>>>> 103. Instead, as PE3 is not SR capable, the operator configures that
>>>>> policy at the SRMS and it is the latter which advertises the
>>>> mapping."---quoted from -01 version of the use case draft.
>>>>>
>>>>>> 2. TLVs that you defined in section 3 and 4 are very close to those
>>>>>> defined in draft-psenak-ospf-segment-routing-extensions and have
>>>>>> the exact same functionality as the ones defined in
>>>>>> draft-psenak-ospf-segment-routing-extensions
>>>>>
>>>>> If I understand your draft correctly, the prefix SID sub-TLV defined
>>>>> in your draft is intended to advertise index, rather than SID or
>>>>> global label. In contrast, the Label Binding
>>>> Sub-TLV and SID Binding Sub-TLV defined in my draft are intended to
>>>> advertise global labels and SIDs respectively. Besides, the Label
>>>> Binding Sub-TLV and SID Binding sub-TLV are just intended for label
>>>> or SID distribution without any correlation with the algorithm and
>>>> MT-ID, which is different from the prefix SID sub-TLV, IMHO.
>>>>
>>>> you can advertise an absolute value of the label/SID with existing
>>>> TLVs
>>>> - simply advertise the label/sid range starting from 0. MT-ID and
>>>> algorithm fields of 0 means default topology and SPT tree, which is what
>>>> you
>> want anyway.
>>>
>>>>>
>>>>>> 3. The only new sub-TLV you defined is Label Request Sub-TLV.
>>>>>>
>>>>>> First, given that we already have OSPF SR draft, you should have
>>>>>> defined this as a sub-TLV of the OSPF Extended Prefix TLV that is
>>>>>> defined in draft-psenak-ospf-segment-routing-extensions.
>>>>>
>>>>>> Second, you proposed to use Opaque LSA that is flooded either area
>>>>>> or domain wide as a request mechanism between the router and
>>>>>> mapping server. This means that all routers in an area/domain would
>>>>>> have to store and maintain such 'request' LSAs, even though they
>>>>>> would never use them locally. I seriously question if flooding of
>>>>>> the LSA is the right
>>>> mechanism to achieve what you want.
>>>>>
>>>>> Agree that it may not be attractive in the OSPF case. However, this
>>>>> choice may
>>>> be attractive in the IS-IS case since the label/SID request
>>>> information can be carried in the IP reachability advertisement.
>>>> Anyway, as said in the draft, the advertisement of label/SID request is
>>>> just
>> one option.
>>>>
>>>> I do not see how ISIS is different - LSP is still flooded with area scope.
>>>>
>>>> regards,
>>>> Peter
>>>>
>>>>>
>>>>> Best regards,
>>>>> Xiaohu
>>>>>
>>>>>> regards,
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 1/27/14 04:34 , Xuxiaohu wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Any comments are welcome.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Xiaohu
>>>>>>>
>>>>>>>> -----邮件原件-----
>>>>>>>> 发件人: [email protected] [mailto:[email protected]]
>>>>>>>> 发送时间: 2014年1月21日 13:53
>>>>>>>> 收件人: Mach Chen; Mach Chen; Xuxiaohu; Xuxiaohu
>>>>>>>> 主题: New Version Notification for
>>>>>>>> draft-xu-ospf-global-label-sid-adv-00.txt
>>>>>>>>
>>>>>>>>
>>>>>>>> A new version of I-D, draft-xu-ospf-global-label-sid-adv-00.txt
>>>>>>>> has been successfully submitted by Xiaohu Xu and posted to the
>>>>>>>> IETF
>>>>>> repository.
>>>>>>>>
>>>>>>>> Name: draft-xu-ospf-global-label-sid-adv
>>>>>>>> Revision: 00
>>>>>>>> Title: Advertising Global Labels or SIDs Using OSPF
>>>>>>>> Document date: 2014-01-21
>>>>>>>> Group: Individual Submission
>>>>>>>> Pages: 7
>>>>>>>> URL:
>>>>>>>> http://www.ietf.org/internet-drafts/draft-xu-ospf-global-label-si
>>>>>>>> d-
>>>>>>>> ad
>>>>>>>> v-00.txt
>>>>>>>> Status:
>>>>>>>> https://datatracker.ietf.org/doc/draft-xu-ospf-global-label-sid-a
>>>>>>>> dv
>>>>>>>> /
>>>>>>>> Htmlized:
>>>>>>>> http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00
>>>>>>>>
>>>>>>>>
>>>>>>>> Abstract:
>>>>>>>> Segment Routing (SR) is a new MPLS paradigm in which each
>>>>>> SR-capable
>>>>>>>> router is required to advertise global MPLS labels or Segment
>> IDs
>>>>>>>> (SID) for its attached prefixes by using link-state IGPs, e.g.,
>>>>>>>> OSPF.
>>>>>>>> One major challenge associated with such global MPLS label or
>> SID
>>>>>>>> advertisement mechanism is how to avoid a given global MPLS
>>>>>>>> label
>>>> or
>>>>>>>> SID from being allocated by different routers to different
>> prefixes.
>>>>>>>> Although such global label or SID allocation collision problem
>> can be
>>>>>>>> addressed through manual allocation , it is error-prone and
>>>>>>>> nonautomatic therefore may not be suitable in large-scale
>>>>>>>> SR
>>>> network
>>>>>>>> environments. This document proposes an alternative
>>>>>>>> approach
>>>> for
>>>>>>>> allocating and advertising global MPLS labels or SIDs via OSPF so
>> as
>>>>>>>> to eliminate the potential risk of label allocation collision.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>>>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>>>>>>>>
>>>>>>>> The IETF Secretariat
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OSPF mailing list
>>>>>>> [email protected]
>>>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>>>
>>>>>
>>>
>
> _______________________________________________
> OSPF mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
