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 <[email protected]>
To: "xuling (F)" <[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [OSPF] regarding draft-ppsenak-ospf-te-link-attr-reuse-00
Message-ID: <[email protected]>
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 <[email protected]<mailto:[email protected]
<mailto:[email protected]%3cmailto:[email protected]>>> on
behalf of "xuling (F)" <[email protected]<mailto:[email protected]
<mailto:[email protected]%3cmailto:[email protected]>>>
Date: Wednesday, January 6, 2016 at 2:28 AM
To: OSPF WG List <[email protected]<mailto:[email protected]
<mailto:[email protected]%3cmailto:[email protected]>>>
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
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
------------------------------
Subject: Digest Footer
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
------------------------------
End of OSPF Digest, Vol 119, Issue 5
************************************
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
