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.
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-sid-
ad
v-00.txt
Status:
https://datatracker.ietf.org/doc/draft-xu-ospf-global-label-sid-adv
/
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
