Re: [Lsr] Working Group Last Call IPR Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints"
Hi All, I am not aware of any undisclosed IPR related to this document. Thanks, William Britto Juniper Business Use Only From: Acee Lindem Date: Tuesday, 20 February 2024 at 9:19 PM To: William Britto A J Cc: draft-ietf-lsr-flex-algo-bw-...@ietf.org , lsr Subject: Re: [Lsr] Working Group Last Call IPR Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" [External Email. Be cautious of content] All, Note that the original IPR Poll Email is incorrect. There are no IPR disclosures and the link below points to disclosures for Dynamic Flooding and should have been removed when I pasted it. However, I have already received a response from everyone but William Britto. Thanks, Acee > On Feb 19, 2024, at 5:20 PM, Acee Lindem wrote: > > Co-Authors, > > Are you aware of any IPR that applies to > draft-ietf-lsr-flex-algo-bw-con-07.txt? > If so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879, 3669 and 5378 for more details). > > There are a few IPR statements already - > https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-dynamic-flooding__;!!NEt6yMaO-gk!BAN9wgTUIZM5KPtXuyRASoYLr3LooAg8uK3ScvDK4Nt8SfTtbcrzB17bgQxAE5NDstBdn8as_7z3LgLK3W3E7Q$<https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-dynamic-flooding__;!!NEt6yMaO-gk!BAN9wgTUIZM5KPtXuyRASoYLr3LooAg8uK3ScvDK4Nt8SfTtbcrzB17bgQxAE5NDstBdn8as_7z3LgLK3W3E7Q$> > > 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. > > Also, we have six authors and four from the same company. Please verify that > all co-authors should be included as such. > > Thanks, > Acee > ___ > Lsr mailing list > Lsr@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!BAN9wgTUIZM5KPtXuyRASoYLr3LooAg8uK3ScvDK4Nt8SfTtbcrzB17bgQxAE5NDstBdn8as_7z3LgIGbDwR6w$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!BAN9wgTUIZM5KPtXuyRASoYLr3LooAg8uK3ScvDK4Nt8SfTtbcrzB17bgQxAE5NDstBdn8as_7z3LgIGbDwR6w$> ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
I am not aware of any IPR related to this draft. Thanks, William From: Lsr on behalf of Acee Lindem (acee) Date: Thursday, 13 May 2021 at 2:51 AM To: lsr@ietf.org Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02 [External Email. Be cautious of content] Esteemed Members of the LSR WG, This begins a 2 week WG adoption call for the following draft: https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/ Please indicate your support or objection by May 27th, 2021. Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft. Thanks, Chris and Acee Juniper Business Use Only ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
Hi All, Thanks for your valuable comments and feedback. We have tried to address most of them in the new version which has been uploaded now. https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-01 Thanks, William From: Tony Li on behalf of Tony Li Date: Friday, 5 March 2021 at 10:58 PM To: Shraddha Hegde Cc: William Britto A J , lsr@ietf.org , Rajesh M , DECRAENE Bruno IMT/OLN Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints [External Email. Be cautious of content] Hi Shraddha, 8) Section 4.2. You write that an implementation "considers cumulative bandwidth of the parallel links while arriving at the metric for the link”. This seems a bit vague. I think you’re trying to say that in interface group mode the bandwidth of an adjacency is the sum of the bandwidths of the individual links. Typically today, if we have L3 parallel links they are encoded as separate adjacencies, complete with unique interface addresses. How does interface group mode work with that? It continues to work the same way. I mean the topological representation does not change. It is going to be represented as multiple parallel Adjacencies. How the metric is assigned to these links differs in simple mode and interface group mode. In simple mode, single l3 link bandwidth is taken and metric is derived by using either of two modes of metric derivation (reference bw or staircase bandwidth thresholds). In interface group mode, cumulative bandwidth of parallel links is used derive the metric (again either ref bw or staircase method can be used) and same metric is assigned to all parallel links. So just to be very clear: we continue to see multiple, parallel adjacencies advertised. Each of them that has a metric that was computed using the sum of the bandwidths on the parallel links. When one of those links fails, the remainder are then advertised with a revised metric that was computed using the sum of the bandwidths of the remaining links. If this is correct, it would be good to state this very clearly. If you intend something else… please be equally clear. Does each adjacency advertise the same metric based on the total bandwidth of all of the links? In automatic metric calculation method, each node derives the metric based on advertised maximum link bandwidth . In interface group mode, metric is derived based on cumulative bandwidth of parallel links and same metric is assigned for all parallel links. In automatic metric calculation method, metric is not advertised. I don’t understand your last sentence. Section 4 is all automatic metric calculation. Why would you calculate the metric and then not advertise it using the Bandwidth Metric subTLV? In cases where operators do not want to use this automatic metric derivation, they can advertise bandwidth metric. How this bandwidth metric is assigned, whether same metric on all parallel links or different metric and actual metric value is all upto the operator. When bandwidth metric sub-TLV is advertised on a link, simple mode or interface group mode does not come into play for that link. Bandwidth metric advertisement overrides, automatic metric derivation. I see that I have misunderstood a big chunk of your intent here. Please add more clarifying text. How does a node know whether we are using automatic mode or are being explicit in advertising our metrics? Is it on a per-link basis? Do we default to automatic mode if no bandwidth metric is advertised? Is the metric automatically calculated if no bandwidth metric is advertised? What does a remote node use as a bandwidth the compute the bandwidth of a link? I would assUme that it’s a Maximum Link Bandidth subTLV of the ASLA subTLV. If so, please be explicit. If we are to use the bandwidth metric in a FAD, we need to specify that in the FAD. This implies that we would need a new value (or set of values if we want multiple bandwidth metrics) for the Metric-Type field in the FAD subTLV. I see that you’ve added a specific request for this in section 7.1, but it deserves mentioning somewhere in the text as well. Regards, Tony Juniper Business Use Only ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
Hi Gyan, This draft aims to provide the protocol constructs to define a flex-algorithm which is suitable for sending high bandwidth traffic. Flex-Algo is a very useful feature for network consolidation use-cases which requires different metric-types for SPF. We are trying introduce the protocol constructs to simplify the use of metric based on bandwidth via Flex-Algo. This draft does not attempt to do bandwidth management nor reservation like what RSVP does. For LDP based networks that use igp metric relative to bandwidth, Flex-Algo provides an easy alternate. Thanks, William From: Gyan Mishra Date: Saturday, 27 February 2021 at 9:40 PM To: Robert Raszuk Cc: DECRAENE Bruno IMT/OLN , Rajesh M , Shraddha Hegde , William Britto A J , lsr@ietf.org Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints [External Email. Be cautious of content] Hi William & Co-authors >From first read of the draft it does appear your are trying to apply RSVP TE >PCALC path and reserve message link attributes constraints such as concept of >affinity bits to exclude low bandwidth or delay of individual links without >taking into account all of what RSVP TE is reserving of bandwidth in the end >to end path with the Path and Reserve message. As mentioned Looking at >individual links will not provide the end to end path view or bandwidth >requirements for the entire path to be reserved as accomplished by RSVP TE. As Tony and Robert have mentioned I agree this is a good first step but does need more refinement to make useful. Kind Regards Gyan On Sat, Feb 27, 2021 at 7:24 AM Robert Raszuk mailto:rob...@raszuk.net>> wrote: Hi William & co-authors, I read the draft and have two basic questions. 1. Both bw & delay can be used as defined in the draft to construct new forwarding topologies. But how practical such topologies would be in the real life when 40GB links may be heavily occupied with bursty traffic and 10G links can sit idle ? I suppose you are trying to address the case where say 12 gbps holographic stream needs to be sent across a network.. But then I don't think if sending it in a single flow instead of spreading into many sub-flows and use as much as possible ecmp would not be a better option. 2. Likewise how good is my accumulated link delay value if in between there are deep buffer network elements and say egress queuing to each link (which max is unaccounted for in your draft) can significantly alter the end to end delay ? Have you consider to add MAX_EGRESS_QUEUE_DELAY on a per link basis (still as static value). So if some traffic is delay sensitive we will have a much better accuracy not to get into a trap of queuing related delays. Thx a lot, Robert. On Fri, Feb 26, 2021 at 8:37 AM William Britto A J mailto:40juniper@dmarc.ietf.org>> wrote: All, We would like to draw your attention to a new ID: https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!U3HBQwaZL7T4mjz-MUHE7VjFtnOyNghGDh5vwJXUXkHdMxlravmRvJwdZ8sz2YPxkw$> The draft talks about introducing link bandwidth related constraints in Flex-Algorithm which can be used to define a Flex-Algorithm based on bandwidth based metric. Please review. Any questions and comments are welcome. Thanks, William From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> mailto:internet-dra...@ietf.org>> Date: Monday, 22 February 2021 at 10:56 PM To: Bruno Decraene mailto:bruno.decra...@orange.com>>, Rajesh M mailto:mraj...@juniper.net>>, Rajesh M mailto:mraj...@juniper.net>>, Shraddha Hegde mailto:shrad...@juniper.net>>, William Britto A J mailto:bwill...@juniper.net>>, William Britto A J mailto:bwill...@juniper.net>> Subject: New Version Notification for draft-hegde-lsr-flex-algo-bw-con-00.txt [External Email. Be cautious of content] A new version of I-D, draft-hegde-lsr-flex-algo-bw-con-00.txt has been successfully submitted by Shraddha Hegde and posted to the IETF repository. Name: draft-hegde-lsr-flex-algo-bw-con Revision: 00 Title: Flexible Algorithms Bandwidth Constraints Document date: 2021-02-22 Group: Individual Submission Pages: 21 URL: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$> Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$&l
Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
Hi Robert, Thanks for your comments. Currently there are customers who deploy separate networks, of which one could be assigned metrics relative to the interface bandwidths, while other could be based on other parameters like latency, etc. Flex-Algo which facilitates different metric-types for SPF, is a very useful feature for such network consolidation use-cases. We are trying introduce the protocol constructs to simplify the use of metric based on bandwidth via Flex-Algo. Any existing tools and techniques used by operators who configure metric relative to link bandwidth to optimize the network can be used with these Flex-Algo constructs too. The Flex-Algo bandwidth constraints defined here can be used to automatically derive a metric based on reference bw vs link bw; and if required, this can be overridden using the individual link bandwidth-metric sub-TLV. We will make this clear in the next version. RFC 8570 support advertising link delay parameters in ISIS. Protocols like TWAMP support dynamically measuring the delay. Whether egress queueing delay is included in the link delay depends on the measuring mechanism. The Exclude Max Delay sub-TLV introduced in this draft is only meant for pruning out high latency links from a Flex-Algo, and it is upto the operator to define the maximum bounds based on the measuring mechanisms deployed in his network. Thanks, William From: Robert Raszuk Date: Saturday, 27 February 2021 at 5:54 PM To: William Britto A J Cc: lsr@ietf.org , Rajesh M , Shraddha Hegde , DECRAENE Bruno IMT/OLN Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints [External Email. Be cautious of content] Hi William & co-authors, I read the draft and have two basic questions. 1. Both bw & delay can be used as defined in the draft to construct new forwarding topologies. But how practical such topologies would be in the real life when 40GB links may be heavily occupied with bursty traffic and 10G links can sit idle ? I suppose you are trying to address the case where say 12 gbps holographic stream needs to be sent across a network.. But then I don't think if sending it in a single flow instead of spreading into many sub-flows and use as much as possible ecmp would not be a better option. 2. Likewise how good is my accumulated link delay value if in between there are deep buffer network elements and say egress queuing to each link (which max is unaccounted for in your draft) can significantly alter the end to end delay ? Have you consider to add MAX_EGRESS_QUEUE_DELAY on a per link basis (still as static value). So if some traffic is delay sensitive we will have a much better accuracy not to get into a trap of queuing related delays. Thx a lot, Robert. On Fri, Feb 26, 2021 at 8:37 AM William Britto A J mailto:40juniper@dmarc.ietf.org>> wrote: All, We would like to draw your attention to a new ID: https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!WgwtY1NpSXZkAtkBfmMRfgZABaIBWv534VYF7vvI4eGGuMbmdKMK_VpWFKV2Tba5Qg$> The draft talks about introducing link bandwidth related constraints in Flex-Algorithm which can be used to define a Flex-Algorithm based on bandwidth based metric. Please review. Any questions and comments are welcome. Thanks, William From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> mailto:internet-dra...@ietf.org>> Date: Monday, 22 February 2021 at 10:56 PM To: Bruno Decraene mailto:bruno.decra...@orange.com>>, Rajesh M mailto:mraj...@juniper.net>>, Rajesh M mailto:mraj...@juniper.net>>, Shraddha Hegde mailto:shrad...@juniper.net>>, William Britto A J mailto:bwill...@juniper.net>>, William Britto A J mailto:bwill...@juniper.net>> Subject: New Version Notification for draft-hegde-lsr-flex-algo-bw-con-00.txt [External Email. Be cautious of content] A new version of I-D, draft-hegde-lsr-flex-algo-bw-con-00.txt has been successfully submitted by Shraddha Hegde and posted to the IETF repository. Name: draft-hegde-lsr-flex-algo-bw-con Revision: 00 Title: Flexible Algorithms Bandwidth Constraints Document date: 2021-02-22 Group: Individual Submission Pages: 21 URL: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$> Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$<https://url
Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
Hi Tony, Thank you for your comments. Please find replies inline. From: Tony Li on behalf of Tony Li Date: Saturday, 27 February 2021 at 7:26 AM To: William Britto A J Cc: lsr@ietf.org , Rajesh M , Shraddha Hegde , DECRAENE Bruno IMT/OLN Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints [External Email. Be cautious of content] Hi William & co-authors, Thank you for your contribution. It’s definitely interesting. As bandwidth management is one area where FlexAlgo lags legacy traffic engineering, this is definitely one small step in the right direction. But I have many comments… 1) I’ll start with the title: there is MUCH more here than bandwidth constraints. Perhaps this should be generalized somehow? Sorry, I don’t have a constructive suggestion. [William] Agree. We are introducing few ‘definitions’ for a bandwidth based Flex-Algo, along with couple of link constraints which can be used for any type of flex-algo. Any suggestions are welcome. 2) Section 2: I concur that bandwidth is an important consideration in path computation. At a first reading, it is not at all clear to me that it is optimal to somehow transmogrify things into a metric. Why not simply deal with the bandwidth directly? I did (eventually) realize that you did this because you want SPF to somehow select the path with the minimum product of (# links) * bandwidth. I think you need to be explicit about this motivation and also mention that traditional SPF is not set up to deal with a floating point metric. Note that a bandwidth metric is STILL somewhat counter-intuitive to me, as I would expect that you’d mostly want to route things along the highest bandwidth paths, not the lowest ones. More motivation behind the bandwidth metric would be most welcome. [William] We will try to address this in the next version. 3) Section 2.1: To be consistent with the rest of FlexAlgo, shouldn’t this be advertised as part of the Application Specific Link Attributes? [William] Agree. Will add relevant text clarifying the same. 4) Sectiion 2.1: Why are there two octets reserved in this sub-TLV? If you’re hoping for alignment within an IS-IS LSP, you’ve already lost. Nothing in IS-IS is aligned. [William] Apologies. This was an error in the figure. Intention was one octet for Reserved/future flags, hence the Length of 5 octets. Will correct this in the next version. 5) Section 3.1.1: Here you have chosen to refer directly to subTLV 9. To be consistent with the rest of FlexAlgo, should we use subTLV 9 inside of the Application Specific Link Attribute subTLV. [William] Shouldn’t there be only one Max link BW per link applicable for all applications? However, agree that it could still be in a common ASLA. Will add relevant text to clarify this. Also, I believe that it would be more clear to call this the “Minimum Bandwidth subTLV”. The word ‘exclude’ doesn’t seem to add value here and every word makes our acronyms harder. [William] The intent was to be explicit (in the name) that this is an ‘exclude constraint’. Eg: Consider a FAD which has the above mentioned sub-tlv as a constraint along with some admin-group constraints. If a link has a Max Link BW which is greater that the Min BW constraint defined, that alone won’t qualify this link to be part of that Flex-Algo. IOW, this is not a minimum bw constraint to include a link that satisfies the requirement into Flex-Algo, but rather to exclude a link that doesn’t meet the criteria. Having said that, if its more clear without the ‘explicit’ in the name, we can do away with it. We are planning to add a section in the next version of this draft as an extension to section 13 – “Calculation of Flexible Algorithm Paths” of [I-D.ietf-lsr-flex-algo<https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00#ref-I-D.ietf-lsr-flex-algo>]. Will clarify this there. 6) Section 3.1.2: I’m unclear on the utility of this. I can understand optimizing for path delay against the path metric. I can even understand putting an upper bound on the total path delay. I don’t understand why a bound on an individual link delay is important. If my path delay budget is 100ms, then does it matter if it is exceeded in one hop or ten? Could you please provide more motivation here? Also, wouldn’t a FlexAlgo system be advertising the link delay in the Application Specific Link Attributes subTLV? [William] This constraint could be useful in a Flex-Algo whose Metric-type is anything but Link-delay. Here, Link-delay doesn’t influence the ‘cost’ of a link in that Flex-Algo, but can be used to prune out certain links with very high delay from that Flex-Algo. I’ll stop here for now, but I promise you more comments are still to come. [William] Thanks. Looking forward to it. Regards, Tony On Feb 25, 2021, at 11:36 PM, William Britto A J mailto:bwilliam=40juniper@dmarc.ietf.org>> wrote: All, We would like to draw your atten
[Lsr] New draft on Flex-Algorithm Bandwidth Constraints
All, We would like to draw your attention to a new ID: https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00 The draft talks about introducing link bandwidth related constraints in Flex-Algorithm which can be used to define a Flex-Algorithm based on bandwidth based metric. Please review. Any questions and comments are welcome. Thanks, William From: internet-dra...@ietf.org Date: Monday, 22 February 2021 at 10:56 PM To: Bruno Decraene , Rajesh M , Rajesh M , Shraddha Hegde , William Britto A J , William Britto A J Subject: New Version Notification for draft-hegde-lsr-flex-algo-bw-con-00.txt [External Email. Be cautious of content] A new version of I-D, draft-hegde-lsr-flex-algo-bw-con-00.txt has been successfully submitted by Shraddha Hegde and posted to the IETF repository. Name: draft-hegde-lsr-flex-algo-bw-con Revision: 00 Title: Flexible Algorithms Bandwidth Constraints Document date: 2021-02-22 Group: Individual Submission Pages: 21 URL: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$> Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$> Htmlized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3X5nPQbA$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3X5nPQbA$> Htmlized: https://urldefense.com/v3/__https://tools.ietf.org/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD2aqSYcuQ$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD2aqSYcuQ$> Abstract: Many networks configure the link metric relative to the link capacity. High bandwidth traffic gets routed as per the link capacity. Flexible algorithms provides mechanisms to create constraint based paths in IGP. This draft documents a set of bandwidth related constraints to be used in Flexible Algorithms. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat Juniper Business Use Only ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] IPR Poll for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Hi Acee, I am not aware of any IPR, other than the one disclosed by Juniper. Regards, William From: Acee Lindem (acee) Date: Wednesday, 2 December 2020 at 2:51 AM To: draft-bonica-lsr-ip-flexa...@ietf.org Cc: lsr@ietf.org Subject: IPR Poll for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 [External Email. Be cautious of content] Authors, Are you aware of any IPR that applies to draft-bonica-lsr-ip-flexalgo-01? 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 Juniper Business Use Only ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
