Re: [OSPF] regarding draft-ppsenak-ospf-te-link-attr-reuse-00

Hi Ling,

On 1/7/16 03:52 , xuling (F) wrote:
> Hi Acee,
>
> I suggest to advertise SRLG only in the TE opaque LSA, and advertise TE
> capability to help understand whether node is TE enabled. If node isn’t
> TE enabled , SRLG shouldn’t be used for TE application; otherwise, SRLG
> can be used for TE application or for other application purposes.

above would be incompatible with the existing implementations, as there 
is no "TE capability" being used today.

regards,
Peter

>
> the mechanism to advertise TE capability has been well defined in
> draft-ietf-ospf-rfc4970bis.
>
> Best regards,
>
> Ling
>
> Hi Ling,
>
> From: OSPF <ospf-bounces@ietf.org<mailto:ospf-bounces@ietf.org
> <mailto:ospf-bounces@ietf.org%3cmailto:ospf-bounces@ietf.org>>> on
> behalf of "xuling (F)" <xuling3@huawei.com<mailto:xuling3@huawei.com
> <mailto:xuling3@huawei.com%3cmailto:xuling3@huawei.com>>>
>
> Date: Wednesday, January 6, 2016 at 2:28 AM
>
> To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org
> <mailto:ospf@ietf.org%3cmailto:ospf@ietf.org>>>
>
> Subject: [OSPF] regarding draft-ppsenak-ospf-te-link-attr-reuse-00
>
> Hi, all
>
> To make the node that is not TE enabled advertises link attributes for
> other applications, it is worth considering another choice which has
> least change to the protocol and implementation. The method is:
> advertising RI capability TLV in RI LSA when advertising TE LSA. TE
> capability bit in RI capability TLV can indicate whether link attributes
> should become part of TE topology.
>
> In draft-ietf-ospf-rfc4970bis,
>
> ?an OSPF router advertising an OSPF RI LSA MAY include the Router
> Informational Capability TLV?? can be enhanced with: an OSPF router
> advertising an OSPF RI LSA should include Router Informational
> Capability TLV which can inform TE capability bit.
>
> In this case, some improvement needs to be done in
> draft-ietf-ospf-rfc4970bis. These are my personal view.
>
> The intent of RFC 4970 and the BIS version is that the drafts requiring
> new capabilities will define them and request IANA allocation as opposed
> to updating RFC 4970BIS for every new capability.
>
> As for the mechanism, I think this would be rather unwieldy to attempt
> to get SRLG information from different LSAs. Rather, within the OSPF
> Routing Domain, I?d choose to advertise SRLGs either in the TE LSAs or
> the Prefix/Link Attribute LSAs.
>
> Thanks,
>
> Acee
>
> Best regards,
>
> Ling XU
>
> ------------------------------------------------------------------------
>
> xuling
> 华为技术有限公司Huawei Technologies Co., Ltd.
> Company_logo
>
> Phone:
> Fax:
> Mobile:
> Email:
> 地址：深圳市龙岗区坂田华为基地 邮编：518129
> Huawei Technologies Co., Ltd.
> Bantian, Longgang District,Shenzhen 518129, P.R.China
> http://www.huawei.com
>
> ------------------------------------------------------------------------
>
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或
> 群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）
> 本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>