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
