Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[William Britto A J]

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].
 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 attention to a new ID: 
h

[Lsr] When is an IANA Registry Required

[Les Ginsberg (ginsberg)]

Alvaro -



In your review of draft-ietf-lsr-isis-srv6-extensions you requested the authors 
to



"Please ask IANA to set up a registry for the Flags."



in multiple cases e.g., the flags field defined in the new SRv6 Capabilities 
sub-TLV.



This isn't the first time you have made such a request (I believe I argued 
against this in the past and you relented – but only temporarily it seems. 😊 ).

As it is a deviation from historical practice, I think it would be better if 
the WG discussed whether there is a good reason to change our practices rather 
than have this request be made based on the personal preference of the current 
AD.



Historically, we have created IANA registries for identifiers which are likely 
to be needed by a variety of unrelated features supported by the protocol. The 
expectation in these cases is that multiple documents - largely unrelated to 
each other - might need to allocate an ID from the same space.

Obvious examples are TLV/sub-TLV code points.

In the case of flags, there are currently only two such registries:



link-attribute bit values for sub-TLV 19 of TLV 
22



Bit Values for Prefix Attribute Flags 
Sub-TLV



In both of these cases the sub-TLVs were defining a general purpose bit field.  
It was expected (and it has happened) that unrelated documents had a need to 
allocate a bit in these fields.



What we have NOT done, historically, is create a registry for a flags field 
which is not provided as a general purpose mechanism,  but is specifically 
scoped for use only within the context of the feature which defined the 
TLV/sub-TLV. (There are many examples.)

It is expected in these cases that if an additional flag is required, that it 
will be defined in a document directly related to the original feature – either 
a bis version of the original document or a new document which is marked 
specifically as an update to the original document.

Management of the flag space in such cases has never required the overhead of a 
registry.



You seem to want to change that and I would like to know why?

What problem exists that you are trying to solve?



IMO, such a policy is not needed, does not add value, but does add additional 
overhead to what is already a considerable set of hoops which drafts must 
navigate on their way to becoming an RFC.

The number of existing TLV/sub-TLVs which have flags fields is significant – 
and the lack of a registry for these fields has not yet caused any problem.



Appreciate if we could have open discussion on this.



   Les






___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Gyan Mishra]

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  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  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
>>
>>
>>
>> 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 <
>> mraj...@juniper.net>, Rajesh M , Shraddha Hegde <
>> shrad...@juniper.net>, 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$
>> 
>> Status:
>> 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$
>> 
>> Htmlized:
>> 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 rela

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Gyan Mishra]

I support publication.  Not aware of any IPRs.

Thanks

Gyan

On Fri, Feb 26, 2021 at 12:51 PM Stefano Previdi (IETF) 
wrote:

> Hi,
>
> I’m not aware of any IPR related to this draft.
>
> Thanks.
> s.
>
>
> > On Feb 17, 2021, at 4:30 PM, Christian Hopps  wrote:
> >
> > Hi LSR and TEAS,
> >
> > This begins a joint WG last call for:
> >
> >  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
> >
> > Please discuss any issues on the LSR mailing list. The WGLC will end
> March 3, 2021.
> >
> > Authors, please indicate wether you are aware of any IPR related to this
> document to the list.
> >
> > Thanks,
> > Chris, Acee, (Lou and Pavan).
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Teas mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Robert Raszuk]

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  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
>
>
>
> 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 <
> mraj...@juniper.net>, Rajesh M , Shraddha Hegde <
> shrad...@juniper.net>, 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$
> 
> Status:
> 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$
> 
> Htmlized:
> 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
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr