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

Ling,

the fundamental flaw in your idea is that you are making the TE 
capability a node property, which is incorrect. TE topology is 
represented by links and as such needs to have per link granularity.

regards,
Peter

On 1/13/16 08:58 , xuling (F) wrote:
> Hi Peter,
>
> the mechanism in draft-ietf-ospf-rfc4970bis maybe highly expect to be used once well defined. If it works, we don't need to define a new mechanism to solve the first issue, maybe for new mechanism incompatible problem would also occur.
>
>
> Best regards,
> Ling
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 11 Jan 2016 08:33:12 +0100
> From: Peter Psenak <ppsenak@cisco.com>
> To: "xuling (F)" <xuling3@huawei.com>, "ospf@ietf.org" <ospf@ietf.org>
> Subject: Re: [OSPF] regarding draft-ppsenak-ospf-te-link-attr-reuse-00
> Message-ID: <56935AB8.5010202@cisco.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> 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
>>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>
>
> ------------------------------
>
> End of OSPF Digest, Vol 119, Issue 5
> ************************************
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
> .
>