[Lsr] Fw: Re: IPR Poll for WG Adoption for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
Hi Acee & WG, I am not aware of any IPR related to this document. Best Regards, Ran - On Wed, Mar 20, 2024 at 12:04 AM Acee Lindem wrote: Co-Authors, Are you aware of any IPR that applies to draft-chen-lsr-anycast-flag? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the LSR WG mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the LSR WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Acee___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] IPR Poll for draft-gong-lsr-ospf-unreachable-link
Hi Yingzhen & WG， I am not aware of any undisclosed IPR related to this document Best Regards, Ran --- 发件人：Yingzhen Qu 收件人：draft-gong-lsr-ospf-unreachable-link ,lsr ,lsr-chairs 抄 送: (无) 发送时间：2024-03-09 08:58:25 主题：[Lsr] IPR Poll for draft-gong-lsr-ospf-unreachable-link Hi all, There is an IPR disclosure filed for this draft on 3/8/2024: IPR disclosures (ietf.org) Also not all authors have responded to the IPR poll in the adoption call thread, so I'd like to ask all the authors and contributors to answer in this thread. The draft won't progress without answers from all authors and contributors. Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author. Thanks,Yingzhen___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)
Hi Yingzhen & WG， I am not aware of any undisclosed IPR related to this document Best Regards, Ran From: YingzhenQu To: lsr ;lsr-chairs ; Date: 2024年02月23日 13:28 Subject: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24) ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr Hi, This email begins a 2 week WG adoption poll for the following draft: https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/ Please review the document and indicate your support or objections by March 8th, 2024.Authors and contributors, please respond to the list indicating whether you are aware of any IPR that applies to the draft.Thanks, Yingzhen___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)
Hi WG, I support the adoption of this draft as co-author. In some scenarios(For details, see section 2), it is very necessary to advertise unreachable links in OSPF. Best Regards, Ran Original From: YingzhenQu To: lsr ;lsr-chairs ; Date: 2024年02月23日 13:28 Subject: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24) ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr Hi, This email begins a 2 week WG adoption poll for the following draft: https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/ Please review the document and indicate your support or objections by March 8th, 2024.Authors and contributors, please respond to the list indicating whether you are aware of any IPR that applies to the draft.Thanks, Yingzhen___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)
Hi Yingzhen & WG， I am not aware of any IPRs that applies to the draft. . Best Regards, Ran Original From: YingzhenQu To: lsr ;lsr-chairs ; Date: 2024年02月23日 13:28 Subject: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24) ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr Hi, This email begins a 2 week WG adoption poll for the following draft: https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/ Please review the document and indicate your support or objections by March 8th, 2024.Authors and contributors, please respond to the list indicating whether you are aware of any IPR that applies to the draft.Thanks, Yingzhen___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-ospf-prefix-extended-flags-01.txt
Hi Acee， Thank you very much for your reminder. To Tom ：I am very sorry that I did not notice the comment. The draft v02 addresses your comments. Thank you very much for your comments. Please see: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-extended-flags/ Best Regards, Ran Original From: AceeLindem To: 陈然00080434; Cc: lsr ; Date: 2024年01月26日 00:31 Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-ospf-prefix-extended-flags-01.txt Thanks Ran - were you also going to update Section 6 with TBD1 and TBD2 as commented by Tom Petch? Acee > On Jan 25, 2024, at 4:33 AM, chen@zte.com.cn wrote: > > Hi WG， > > This version addresses all comments from the mailist. > Any comments or suggestions are welcome. > > Best Regards, > Ran > > > Original > From: internet-dra...@ietf.org > To: i-d-annou...@ietf.org ; > Cc: lsr@ietf.org ; > Date: 2024年01月25日 17:27 > Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-prefix-extended-flags-01.txt > Internet-Draft draft-ietf-lsr-ospf-prefix-extended-flags-01.txt is now > available. It is a work item of the Link State Routing (LSR) WG of the IETF. > >Title: Prefix Flag Extension for OSPFv2 and OSPFv3 >Authors: Ran Chen > Detao Zhao > Peter Psenak > Ketan Talaulikar > Liyan Gong >Name:draft-ietf-lsr-ospf-prefix-extended-flags-01.txt >Pages: 10 >Dates: 2024-01-25 > > Abstract: > >Within OSPF, each prefix is advertised along with an 8-bit field of >capabilities, by using the Prefix Options (OSPFv3) and the flag >flield in the OSPFv2 Extended Prefix TLV (OSPFv2). However, for >OSPFv3, all the bits of the Prefix Options have already been >assigned, and for OSPFv2, there are not many undefined bits left in >the OSPFv2 Extended Prefix TLV. > >This document solves the problem of insufficient existing flags, and >defines the variable length Prefix Attribute Flags Sub-TLVs for >OSPFv2 and OSPFv3 respectively for the extended flag fields. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-extended-flags/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-extended-flags-01 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-ospf-prefix-extended-flags-01 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-ospf-prefix-extended-flags-01.txt
Hi WG， This version addresses all comments from the mailist. Any comments or suggestions are welcome. Best Regards, Ran Original From: internet-dra...@ietf.org To: i-d-annou...@ietf.org ; Cc: lsr@ietf.org ; Date: 2024年01月25日 17:27 Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-prefix-extended-flags-01.txt Internet-Draft draft-ietf-lsr-ospf-prefix-extended-flags-01.txt is now available. It is a work item of the Link State Routing (LSR) WG of the IETF. Title: Prefix Flag Extension for OSPFv2 and OSPFv3 Authors: Ran Chen Detao Zhao Peter Psenak Ketan Talaulikar Liyan Gong Name:draft-ietf-lsr-ospf-prefix-extended-flags-01.txt Pages: 10 Dates: 2024-01-25 Abstract: Within OSPF, each prefix is advertised along with an 8-bit field of capabilities, by using the Prefix Options (OSPFv3) and the flag flield in the OSPFv2 Extended Prefix TLV (OSPFv2). However, for OSPFv3, all the bits of the Prefix Options have already been assigned, and for OSPFv2, there are not many undefined bits left in the OSPFv2 Extended Prefix TLV. This document solves the problem of insufficient existing flags, and defines the variable length Prefix Attribute Flags Sub-TLVs for OSPFv2 and OSPFv3 respectively for the extended flag fields. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-extended-flags/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-extended-flags-01 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-ospf-prefix-extended-flags-01 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New Version Notification for draft-chen-lsr-anycast-flag-05.txt
Hi WG, This version addresses all comments from the IETF117th meeting. The updates mainly include: 1. Added the use case for AC-flag. 2.Added description of how router will use AC-flag. Any comments or suggestions are welcome. Best Regards, Ran Original From: internet-dra...@ietf.org To: 赵德涛10132546;Ketan Talaulikar ;Peter Psenak ;陈然00080434; Date: 2024年01月25日 15:38 Subject: New Version Notification for draft-chen-lsr-anycast-flag-05.txt A new version of Internet-Draft draft-chen-lsr-anycast-flag-05.txt has been successfully submitted by Ran Chen and posted to the IETF repository. Name: draft-chen-lsr-anycast-flag Revision: 05 Title:Updates to Anycast Property advertisement for OSPFv2 Date: 2024-01-25 Group:Individual Submission Pages:6 URL: https://www.ietf.org/archive/id/draft-chen-lsr-anycast-flag-05.txt Status: https://datatracker.ietf.org/doc/draft-chen-lsr-anycast-flag/ HTMLized: https://datatracker.ietf.org/doc/html/draft-chen-lsr-anycast-flag Diff: https://author-tools.ietf.org/iddiff?url2=draft-chen-lsr-anycast-flag-05 Abstract: Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast and as such the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast identifier. Each prefix is advertised along with an 8-bit field of capabilities,by using the flag flield in the OSPFv2 Extended Prefix TLV [RFC7684], but the definition of anycast flag to identify the prefix as anycast has not yet been defined. This document updates [RFC7684], by defining a new flag in the OSPFv2 Extended Prefix TLV Flags [RFC7684] to advertise the anycast property. The IETF Secretariat___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03
Hi Sharddha， Thanks for your comments. Will rename them according with your comments. Thanks! Best Regards, Ran Original From: ShraddhaHegde To: Peter Psenak ;Acee Lindem ;Lsr ; Cc: draft-chen-lsr-prefix-extended-fl...@ietf.org ; Date: 2023年11月23日 00:16 Subject: Re: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 > 1. It is not clear whether " OSPFv2 Prefix Attributes Sub-TLV" and "OSPFv3 > Prefix Attributes Sub-TLV" > Would allow other sub-tlvs under them in future. If so, the flags should be a > separate sub-sub-TLV under Prefix attributes sub-TLV. If it does not allow > other attributes, pls rename it as " OSPFv2 Prefix flags Sub-TLV" no sub0sub-TLVs, the value portion is just a bitstring like ISIS IPv4/IPv6 Extended Reachability Attribute Flags (rfc7794). Pls rename the " OSPFv2 Prefix Attributes Sub-TLV" to "OSPFV2 Prefix Attribute Flags Sub-TLV" Similarly for OSPFv3 as well. Rgds Shraddha Juniper Business Use Only -Original Message- From: Peter Psenak Sent: Wednesday, November 22, 2023 6:04 PM To: Shraddha Hegde ; Acee Lindem ; Lsr Cc: draft-chen-lsr-prefix-extended-fl...@ietf.org Subject: Re: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 [External Email. Be cautious of content] Hi Shraddha, On 22/11/2023 12:58, Shraddha Hegde wrote: > I support the adoption of the document. > > I have below comments > > 1. It is not clear whether " OSPFv2 Prefix Attributes Sub-TLV" and "OSPFv3 > Prefix Attributes Sub-TLV" > Would allow other sub-tlvs under them in future. If so, the flags should be a > separate sub-sub-TLV under Prefix attributes sub-TLV. If it does not allow > other attributes, pls rename it as " OSPFv2 Prefix flags Sub-TLV" no sub0sub-TLVs, the value portion is just a bitstring like ISIS IPv4/IPv6 Extended Reachability Attribute Flags (rfc7794). > > 2. section 3 has below statement > " This document does not define any flags." > For OSPFv3 this document defines 2 new bits. This text needs to be > updated and IANA section U/UP-flags have been moved here by mistake, they are defined in the UPA dratf. Will be fixed. thanks, Peter > Needs to be updated. > > Rgds > Shraddha > > > Juniper Business Use Only > -Original Message- > From: Lsr On Behalf Of Acee Lindem > Sent: Friday, November 17, 2023 9:27 PM > To: Lsr > Cc: draft-chen-lsr-prefix-extended-fl...@ietf.org > Subject: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 > and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 > > [External Email. Be cautious of content] > > > LSR WG, > > This starts the Working Group adoption call for > draft-chen-lsr-prefix-extended-flags-03. Please send your support or > objection to this list before December 2nd, 2023. The extra week is to allow > for the US Thanksgiving holiday. > > > Thanks, > Acee > ___ > Lsr mailing list > Lsr@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ > _;!!NEt6yMaO-gk!DGBre12MrjIxWhX5kt5kFUqEsrj_psPbViIAnrBl4i9-7wff2Fyrg5 > EIgKXtJdujJ3xKN4aYAomnS4NXOHM$ > > ___ > Lsr mailing list > Lsr@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ > _;!!NEt6yMaO-gk!CHZKllXRW53oZBGLQM6OMuuD4hNd4LBdpKiUSSdltPg2q6Vgit95so > Gd81oq6wmPRzmzejKflaSIFyUS0ZtvOpizQWibXZ4G$ > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)
Hi Acee and WG， I support the adoption as co-author. The feature is really useful and the draft is ready for WG adoption. Best Regards, Ran Original From: AceeLindem To: Lsr ; Cc: draft-chen-lsr-prefix-extended-fl...@ietf.org ; Date: 2023年11月18日 00:02 Subject: WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date) LSR WG, This starts the Working Group adoption call for draft-chen-lsr-prefix-extended-flags-03. Please send your support or objection to this list before December 9th, 2023. The extra week is to allow for the US Thanksgiving holiday. Thanks, Acee___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption IPR Poll for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03
Hi Acee， I am not aware of any IPR associated with this document. Best Regards， Ran Original From:AceeLindem To:draft-chen-lsr-prefix-extended-fl...@ietf.org; Cc:Lsr; Date:2023-11-17 23:49:12 Subject:[Lsr] WG Adoption IPR Poll for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 Co-Authors, Are you aware of any IPR that applies to draft-chen-lsr-prefix-extended-flags-03? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There currently aren’t any IPR declarations on this simple protocol extension - https://datatracker.ietf.org/ipr/search/?submit=draft=draft-chen-lsr-prefix-extended-flags If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the LSR WG mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the LSR WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. As one would hope, there currently aren’t any IPR declarations on this simple protocol extension. https://datatracker.ietf.org/ipr/search/?submit=draft=draft-chen-lsr-prefix-extended-flags Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
Hi WG,Support adoption.Best Regards, Ran -Original Message-From: lsr-boun...@ietf.org On Behalf Of ChristianHoppsSent: Tuesday, January 4, 2022 2:59 PMTo: lsr@ietf.orgCc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org;draft-wang-lsr-stub-link-attributes@ietf.orgSubject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02Hi Folks,This begins a 2 week WG Adoption Call for the following draft:https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/Please indicate your support or objections by January 18th, 2022.Authors, please respond to the list indicating whether you are aware of anyIPR that applies to these drafts.Thanks,Chris.___Lsr mailing listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr___Lsr mailing listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"
Hi Acee and Chris, I'm not aware of any undisclosed IPR related to this document., and I believe this draft is very useful and support WG adoption as co-author. Best Regards, Ran 原始邮件 发件人：ChristianHopps 收件人：lsr@ietf.org; 抄送人：cho...@chopps.org; 日 期 ：2021年05月27日 05:00 主 题 ：[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement" Hi Folks, This begins a 2 week WG Adoption Call for the following draft: https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/ Please indicate your support or objections by June 9th, 2021 Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft. Thanks, Acee and Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] draft-peng-lsr-flex-algo-l2bundles
Hi Peter, Thank you very much for your comments. ##PPas I expressed earlier, my preference would be to keep the flex-algo being based on L3 link information only and not to use L2 link information during the flex-algo computation. There are other ways to solve your problem. But I will let the WG to discuss and decide. Ran:Would you like to provide other ways? Then we can take it as an optional solution and compare with our solution. Best Regards, Ran 原始邮件 发件人：PeterPsenak 收件人：彭少富10053815; 抄送人：lsr@ietf.org; 日 期 ：2021年03月12日 20:04 主 题 ：Re: [Lsr] draft-peng-lsr-flex-algo-l2bundles Hi Shaofu, please see inline (##PP): On 12/03/2021 04:26, peng.sha...@zte.com.cn wrote: > > Hi Peter, > > > Thanks for your important comments. > > It seems that we have a consensus that the use-case described in the > draft is valid. > > I've heard some people say that flex-algo has already supported this > l2-bundles scenario, no additional definition is needed. This seems > that, from the view of some people, the use-case need to be solved > through flex-algo itself. ##PP no, flex-algo does not have any support for l2-bundles at this point. > > The solution currently described in this document may not be mature, but > the direction may not be wrong ? ##PP as I expressed earlier, my preference would be to keep the flex-algo being based on L3 link information only and not to use L2 link information during the flex-algo computation. There are other ways to solve your problem. But I will let the WG to discuss and decide. > > > Others please see inline [PSF]. > > > Regards, > > PSF > > > 原始邮件 > *发件人：*PeterPsenak > *收件人：*lsr@ietf.org; > *日 期 ：*2021年03月09日 18:08 > *主 题 ：**[Lsr] draft-peng-lsr-flex-algo-l2bundles* > Dear authors, > > here are couple of comments to draft-peng-lsr-flex-algo-l2bundles: > > 1. Flex-algo specification as specified in draft-ietf-lsr-flex-algo only > uses L3 link information for path computation. This is consistent with > the regular Algo 0 path computation. My preference would be to keep it > that way. > > *[PSF] There maybe one way not to violate this rule, but more complex. * > > *[PSF] Currently for an L3 link there are multiple Application specific > attributes, is it possible for an application (such as Flex-algo) there > are multiple APP Instance specific attributes ? For example, an > L2-bundle interface can have multiple Flex-algo APP instance delay > metric, for algorithm-128 the delay metric is 10ms (exactly get from the > dynamic detection of member link 1), for algorithm-129 the delay metric > is 20ms (exactly get from the dynamic detection of member link 2), for > algorithm-0 the delay metric get from the dynamic detection of bundles > itself.** However I don't like the this way. Other ways?* ##PP what you are proposing above is a per flex-algo ID link attributes, but I don't believe that is the direction we want to go. It does not scale. > > > 2. Flex-algo is not a replacement for SRTE. The problem that you are > trying to solve can be solved by SRTE with the usage of the L2 Adj-SIDs. > > *[PSF] Flex-algo is constraint based SPF, for the initial purpose, is > SID stack depth optimization for SR-TE path ? It's hard to convince > operators by just saying that "the problem is out the scope of > Flex-algo" when he has already selected Flex-algo *to reduce the number > of Adj-SIDs.** ##PP Flex-algo is constraint based SPF, but so far based on L3 link information only. > > > 3. Usage of the L2 link data for flex-algo path computation is much more > complex than defining the L-flag in the FAD. You would need to deal with > things like: > > a) conflicting information in L3 and L2 link information > b) missing information in L3 or L2 link information > > *[PSF] Yes, more computation rules need be added based on the existing > ones defined in draft-ietf-lsr-flex-algo. I think it's no more complex > than Flex-algo itself.* ##PP the question is how much extra complexity do we want to add for the benefit it brings. We need to consider how frequent is the use case that you describe present in the field and whether existing mechanisms like SRTE, or usage of L3 links instead if L2 bundles in such case, are not sufficient to address the problem. The fact that it is possible to address the problem by flex-algo does not mandate the usage of it. thanks, Peter > > > which would require to define a strict path computation preference rules > and conflict resolutions that all routers would need to follow. I would > argue that this is much easier to be done with SRTE, where the logic to > select the path is a local matter compared to consistency in path > selection that is required for distributed calculation used by flex-algo. > > *[PSF] Unfortunately we are now in the context of Flex-algo, not SR-TE.* > > > thanks, > Peter > > > > > ___ > Lsr
[Lsr] draft-draft-peng-lsr-algorithm-related-adjacency-sid
Hi Tony, Thanks for your comments. The reason why this draft is proposed is that: Currently, the current FA draft only defines that the algorithm identifier is included as part of a Prefix-SID advertisement,that maybe not satisfy some scenarios where multiple algorithm share the same link resource. For example, an SR-TE policy may be instantiated within specific Flex-algo plane, i.e.,the SID list requires to include algorithm related SIDs. An algorithm-unware Adjacency-SID included in the SID list can just steer the packet towards the link, but can not apply different QoS policy for different algorithm. Another example is that the TI-LFA backup path computed in Flex-algo plane may also contain an algorithm-unware Adjacency-SID, which maybe also used in other SR-TE instance that carries other service. This document complement that the algorithm identifier can be also included as part of an Adjacency-SID advertisement for SR-MPLS. Best Regards, Ran___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Comments on draft-ietf-lsr-ospfv3-srv6-extensions
Hi authors, I've read https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/, and this is a useful work. Thanks. But I have a comment : The recommended allocation type in section 12.3 conflicts with the existing allocated type,please see below. Please Check it. Best Regards, Ran___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] //Re: [Teas] "Packet Network Slicing using Segment Routing"
Hi chairs， Thank you very much for your suggestions. I will change the name of the draft, and continue the draft on the teas wG. Regards, Ran Re: [Lsr] [Teas] "Packet Network Slicing using Segment Routing" Lou Berger Mon, 25 March 2019 23:32 UTCShow header Authors, just resubmit with teas in place of lsr, when you do your update based on other feedback you received this week. Thanks, Lou (TEAS co-chair) On 3/25/2019 2:52 PM, Acee Lindem (acee) wrote: > > Hi Authors, > > I read this draft on the plane on the way to Prague and I don’t think > it belongs in LSR. I believe it belongs in TEAs as it is more about > the requirement and framework for TE slicing than it does about adding > the Administrative Instance Identifier (AII) to the OSPF and IS-IS TE > encodings. We will go forward with the presentation on Thursday with > the understanding that LSR will not adopt this work. If it is adopted > in TEAS, we can decide whether to proceed with a small LSR draft with > just the new AIIs or simply provide review and IANA code points in our > registries. > > Thanks, > Acee > >___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
