[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints"
From: "Ketan Talaulikar \(ketant\)" <ketant=40cisco.com () dmarc ! ietf ! org>
Date: 2021-05-31 10:43:53
Message-ID: MW3PR11MB4570AF10021EBF0218BC0577C13F9 () MW3PR11MB4570 ! namprd11 ! prod ! outlook ! com
[Download RAW message or body]
Hi Shraddha,
My point is that Generic Metric is not a legacy advertisement and it is application \
specific. Therefore, the place to advertise it is within the ASLA Sub-TLV - this \
applies to both ISIS and OSPF.
The references in RFC8919 and RFC8920 are about legacy advertisements and do not \
apply in this discussion.
Thanks,
Ketan
From: Shraddha Hegde <shraddha@juniper.net>
Sent: 31 May 2021 14:20
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Tony Li <tony.li@tony.li>
Cc: Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>; lsr@ietf.org; \
draft-hegde-lsr-flex-algo-bw-con@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, \
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Ketan,
Pls see inline..
Juniper Business Use Only
From: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Sent: Monday, May 31, 2021 1:14 PM
To: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; Tony Li \
<tony.li@tony.li<mailto:tony.li@tony.li>>
Cc: Acee Lindem (acee) \
<acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; \
lsr@ietf.org<mailto:lsr@ietf.org>; \
draft-hegde-lsr-flex-algo-bw-con@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-con@ietf.org>
Subject: RE: [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]
Hi Shraddha,
When you refer to "a single TE application", it is not clear which one you are \
referring to : RSVP-TE or SR Policy? <Shraddha> It could be either of them
I believe, for ISIS, you are referring to this specific section of RFC8919 : \
https://datatracker.ietf.org/doc/html/rfc8919#section-6.1<https://urldefense.com/v3/__ \
https:/datatracker.ietf.org/doc/html/rfc8919*section-6.1__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_AdZHekgKS$>
There is no ambiguity here. This section is about use of "legacy" advertisement. The \
Generic Metric is a new TLV and hence cannot be considered as "legacy" by any \
interpretation of the word. <Shraddha> For ISIS, I hope you agree that generic metric \
sub-TLV is allowed to get advertised under TLV 22.
Coming to OSPF, the considerations are similar. Additionally we also have to deal \
with different LSA types here.
Please refer to https://datatracker.ietf.org/doc/html/rfc8920#section-12.1<https://url \
defense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-12.1__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_Adc5YCVr4$> \
for the equivalent discussion for OSPF. This section is about "legacy" advertisements \
being in (RSVP) TE Opaque LSAs. If the TE application that you were referring to was \
RSVP-TE, then there is also additional guidance provided here : \
https://datatracker.ietf.org/doc/html/rfc8920#section-12.2.4<https://urldefense.com/v3 \
/__https:/datatracker.ietf.org/doc/html/rfc8920*section-12.2.4__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_AdRkvFDI2$>
Please clarify where RFC8920 describes advertisement of application-specific \
attributes in say OSPFv2 Extended Link LSA other than within the ASLA sub-TLV. \
<Shraddha> From what I understand, you agree that the generic metric sub-TLV should \
be allowed in TE Opaque LSA. You have concerns only on it being allowed in Extended \
Link opaque LSA top level Extended Link TLV right?
Thanks,
Ketan
From: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Sent: 31 May 2021 09:13
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; Tony Li \
<tony.li@tony.li<mailto:tony.li@tony.li>>
Cc: Acee Lindem (acee) \
<acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; \
lsr@ietf.org<mailto:lsr@ietf.org>; \
draft-hegde-lsr-flex-algo-bw-con@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-con@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, \
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Ketan,
Networks that deploy a single TE application and already advertising and using \
attributes from top level TLVs Will benefit from new attributes also coming in the \
same top level TLVs. There is no confusion and ambiguity from a network operators \
perspective and IMO this must be allowed in the protocol.
If the attribute gets advertised in both ASLA and top level TLV, how the receiver \
should process it, has been described in RFC 8919 and 8920 and this draft will refer \
to the same procedures. If you think there is ambiguity in RFC 8919 and RFC 8920, pls \
provide specific cases that are ambiguous.
Rgds
Shraddha
Juniper Business Use Only
From: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Sent: Thursday, May 27, 2021 7:13 PM
To: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; Tony Li \
<tony.li@tony.li<mailto:tony.li@tony.li>>
Cc: Acee Lindem (acee) \
<acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; \
lsr@ietf.org<mailto:lsr@ietf.org>; \
draft-hegde-lsr-flex-algo-bw-con@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-con@ietf.org>
Subject: RE: [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]
Hi Shraddha,
This is a new attribute that we are introducing and we are saying that it has \
application specific semantics. We now have the ASLA mechanics defined in both OSPF \
and ISIS. So why should it not use just the ASLA encoding?
Allowing its advertisement in the existing top-level TLVs in addition to ASLA \
introduces ambiguity for which applications can use it - we get into complications \
that are entirely avoidable.
Thanks,
Ketan
From: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; Tony Li \
<tony.li@tony.li<mailto:tony.li@tony.li>>
Cc: Acee Lindem (acee) \
<acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; \
lsr@ietf.org<mailto:lsr@ietf.org>; \
draft-hegde-lsr-flex-algo-bw-con@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-con@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, \
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Snipped..
1. Since the draft is covering FlexAlgo, I would have expected that Generic Metric \
is carried only in the ASLA and this document specifies usage only for the FA \
application. Later this can be also used/extended for other applications but still \
within ASLA. Keeping an option of advertising both outside and within the ASLA is \
problematic - we will need precedence rules and such. I prefer we avoid this \
complication.
We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA (quite \
correctly) for FlexAlgo application. Peter has confirmed the same. I am simply asking \
to avoid the complications of using Generic Metric in both ASLA and outside it. \
Whatever new "application" we invent to use this generic metric type, can use ASLA so \
that the Generic Metric can be very cleanly shared between applications. The encoding \
allows for using the same value - sharing single advertisement across applications or \
doing a different one per-application. <Shraddha> Generic metric is allowed in ASLA, \
it is also allowed in all traditional TLVs/LSAs where link attributes are advertised. \
This is required so that all the applications, existing and new can make use of \
generic metric.
Juniper Business Use Only
From: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Sent: Wednesday, May 26, 2021 12:09 PM
To: Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>
Cc: Acee Lindem (acee) \
<acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; \
lsr@ietf.org<mailto:lsr@ietf.org>; \
draft-hegde-lsr-flex-algo-bw-con@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-con@ietf.org>
Subject: RE: [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]
Hi Tony,
Please check inline below.
From: Tony Li <tony1athome@gmail.com<mailto:tony1athome@gmail.com>> On Behalf Of Tony \
Li
Sent: 25 May 2021 00:15
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Cc: Acee Lindem (acee) \
<acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; \
lsr@ietf.org<mailto:lsr@ietf.org>; \
draft-hegde-lsr-flex-algo-bw-con@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-con@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, \
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Ketan,
In general, I support the adoption of this document. There is, however, one specific \
point which is not clear to me (8) below that I would appreciate some clarity on \
before adoption.
As the chairs have noted, adoption is binary and not contingent upon rough consensus \
on the content, just on rough consensus on the interest. [KT] I believe the WG has \
(or must have) the ability to determine portions of the proposal to adopt and/or to \
split documents. I have seen this in recent past in other WGs. In any case, it is not \
a point that I wish to argue or debate on - especially in the context of this \
document. My point (8) was clarified and hence I fall in the binary YES in this \
instance.
1. Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF allows 4 \
byte size and so why not the same for ISIS? Elsewhere in the document, I do see MAX \
METRIC being referred to as 4,261,412,864.
Because I'm a lazy sod.
It's far easier to detect metric overflow on three byte values than four byte values. \
True, four byte is not impossible, but it's just quick and easy with three byte \
values. Adding a fourth byte would add range to the metric space, but in practice, \
this seemed like it was not really relevant. Most areas are not a very high diameter \
and the need for detailed metric distinctions has not been that high. Thus, we went \
with a 3 byte metric in RFC 5305 (sec 3.7) and that seems to work. [KT] The Generic \
Metric is by definition something that will get extended in the future and we don't \
know what use-cases might arise. It doesn't seem right to follow in the steps of an \
administratively assigned metric type like the TE metric. Therefore, I suggest to \
make it variable.
[KT] Regarding metric overflow, I think it would be better to leave it to \
implementations on how to deal with it. A guidance similar to below (from \
draft-ietf-lsr-flex-algo) would help handle the condition in a manner that does not \
cause interop issues. Theoretically, it is something that is independent of the size \
of the metric.
During the route computation, it is possible for the Flex-Algorithm
specific metric to exceed the maximum value that can be stored in an
unsigned 32-bit variable. In such scenarios, the value MUST be
considered to be of value 4,294,967,295 during the computation and
advertised as such.
1.
2. Would be good to cover the max-metric considerations for the Generic Metric. \
Similar to https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-1 \
5.3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-fl \
ex-algo-15*section-15.3__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKigDlnfK$>
Fair
1.
2. Since the draft is covering FlexAlgo, I would have expected that Generic Metric \
is carried only in the ASLA and this document specifies usage only for the FA \
application. Later this can be also used/extended for other applications but still \
within ASLA. Keeping an option of advertising both outside and within the ASLA is \
problematic - we will need precedence rules and such. I prefer we avoid this \
complication.
We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA (quite \
correctly) for FlexAlgo application. Peter has confirmed the same. I am simply asking \
to avoid the complications of using Generic Metric in both ASLA and outside it. \
Whatever new "application" we invent to use this generic metric type, can use ASLA so \
that the Generic Metric can be very cleanly shared between applications. The encoding \
allows for using the same value - sharing single advertisement across applications or \
doing a different one per-application.
1.
2. For the newly proposed FAD b/w constraints, I would suggest the following names \
for the constraint sub-TLVs where the b/w value signalled by all is compared with the \
Max Link B/w attribute. This is just to make the meaning, at least IMHO, more clear.
* Exclude Higher Bandwidth Links
* Exclude Lower Bandwidth Links
* Include-Only Higher Bandwidth Links
* Include-Only Lower Bandwidth Links
1. Similar naming for the FAD delay constraints as well would help. Though I can \
only think of the use of "exclude" for links above a certain delay threshold to be \
more practical but perhaps others might eventually be required as well?
Thank you for the suggestions.
1.
2. For the Max B/w Link attribute and its comparison with the FAD b/w constraints, \
I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA - \
https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__ht \
tps:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKlvO8Grj$>, \
in case of ISIS also, it is not really appropriate for use within ASLA \
-https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1<https://urldefense.com/v3 \
/__https:/datatracker.ietf.org/doc/html/rfc8919*section-4.2.1__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKrdBaWXz$>?
I'm sorry, I don't understand this comment.
[KT] In https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#sect \
ion-3.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde \
-lsr-flex-algo-bw-con-02*section-3.2.1__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKn7h1XsO$>
The Maximum Link Bandwidth as advertised by the sub-sub-
TLV 23 of ASLA [RFC \
8920<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920__;!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKiuV4Gz8$>] \
MUST be compared against the Minimum
bandwidth advertised in FAEMB sub-TLV.
And in the https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense. \
com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKlvO8Grj$>
Maximum link bandwidth is an application-independent attribute of the
link that is defined in \
[RFC3630<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630__;!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKgE3htSJ$>]. \
Because it is an application-
independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.
Somewhat similar for ISIS as well.
1.
2. Document should cover the FAPM aspects for the Generic Metric and especially \
the Bandwidth metric.
Nor this one.
[KT] Generic Metric is used for the links. When we get to the computation of \
inter-area or external routes, we will need to get into FAPM. The draft at a minimum \
should discuss the applicability of the Generic Metric and its use as FAPM. Now, if \
we do make the Generic Metric size variable (as suggested above), then we will likely \
need a new TLV for a variable size FAPM equivalent?
1.
2. The document introduces a new Generic Metric type called Bandwidth metric. I've \
been trying to follow some of the discussion related to this on the mailing list - \
about it being cumulative or not. I am perhaps somewhat confused by those \
discussions. The OSPF/ISIS SPT computation has always worked with cumulative link \
(and prefix) metrics. If the computation for the Generic Metric of this new type b/w \
is not going to be cumulative (I thought it is - but not very clear anymore), then \
the document needs to describe the computation algorithm. Is it then hop count based? \
Perhaps I am missing something very basic here and if so, please point me to the text \
in the draft.
I'm sorry if this has been confusing. My understanding is that the metric is \
cumulative. Others had other expectations. [KT] Thanks for this important \
clarification.
Thanks,
Ketan
When there are multiple links with the same bandwidth, and thus the same metric, then \
the total path metric becomes (link metric) * (number of links).
Regards,
Tony
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Lato;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";}
p.msipfooter30b3d538, li.msipfooter30b3d538, div.msipfooter30b3d538
{mso-style-name:msipfooter30b3d538;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle25
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:690884198;
mso-list-template-ids:1024603466;}
@list l0:level1
{mso-level-start-at:7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1
{mso-list-id:882593003;
mso-list-template-ids:1406429282;}
@list l1:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2
{mso-list-id:1249389530;
mso-list-template-ids:653270688;}
@list l2:level1
{mso-level-start-at:6;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3
{mso-list-id:1342395109;
mso-list-template-ids:-1227202804;}
@list l3:level1
{mso-level-start-at:5;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4
{mso-list-id:1462841980;
mso-list-template-ids:-620988694;}
@list l4:level1
{mso-level-start-at:3;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5
{mso-list-id:1539004963;
mso-list-template-ids:1406429282;}
@list l5:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6
{mso-list-id:1747729017;
mso-list-template-ids:-347554782;}
@list l6:level1
{mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7
{mso-list-id:1915315758;
mso-list-template-ids:-1922938086;}
@list l7:level1
{mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-IN" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hi \
Shraddha,<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="mso-fareast-language:EN-US"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span style="mso-fareast-language:EN-US">My point is that Generic \
Metric is not a legacy advertisement and it is application specific. Therefore, the \
place to advertise it is within the ASLA Sub-TLV – this applies to both ISIS \
and OSPF.<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="mso-fareast-language:EN-US"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span style="mso-fareast-language:EN-US">The references in RFC8919 \
and RFC8920 are about legacy advertisements and do not apply in this \
discussion.<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="mso-fareast-language:EN-US"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span \
style="mso-fareast-language:EN-US">Thanks,<o:p></o:p></span></p> <p \
class="MsoNormal"><span \
style="mso-fareast-language:EN-US">Ketan<o:p></o:p></span></p> <p \
class="MsoNormal"><span \
style="mso-fareast-language:EN-US"><o:p> </o:p></span></p> <div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> \
Shraddha Hegde <shraddha@juniper.net> <br>
<b>Sent:</b> 31 May 2021 14:20<br>
<b>To:</b> Ketan Talaulikar (ketant) <ketant@cisco.com>; Tony Li \
<tony.li@tony.li><br> <b>Cc:</b> Acee Lindem (acee) \
<acee=40cisco.com@dmarc.ietf.org>; lsr@ietf.org; \
draft-hegde-lsr-flex-algo-bw-con@ietf.org<br> <b>Subject:</b> RE: [Lsr] LSR WG \
Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and \
Constraints" - draft-hegde-lsr-flex-algo-bw-con-02<o:p></o:p></span></p> </div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">Hi Ketan,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Pls see inline..<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="msipfooter30b3d538" align="center" style="margin:0cm;text-align:center">
<span lang="EN-US" style="font-size:7.0pt;color:black">Juniper Business Use \
Only</span><span lang="EN-US"><o:p></o:p></span></p> <div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Ketan \
Talaulikar (ketant) <<a href="mailto:ketant@cisco.com">ketant@cisco.com</a>> \
<br> <b>Sent:</b> Monday, May 31, 2021 1:14 PM<br>
<b>To:</b> Shraddha Hegde <<a \
href="mailto:shraddha@juniper.net">shraddha@juniper.net</a>>; Tony Li <<a \
href="mailto:tony.li@tony.li">tony.li@tony.li</a>><br> <b>Cc:</b> Acee Lindem \
(acee) <<a href="mailto:acee=40cisco.com@dmarc.ietf.org">acee=40cisco.com@dmarc.ietf.org</a>>;
<a href="mailto:lsr@ietf.org">lsr@ietf.org</a>; <a \
href="mailto:draft-hegde-lsr-flex-algo-bw-con@ietf.org"> \
draft-hegde-lsr-flex-algo-bw-con@ietf.org</a><br> <b>Subject:</b> RE: [Lsr] LSR WG \
Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and \
Constraints" - draft-hegde-lsr-flex-algo-bw-con-02<o:p></o:p></span></p> </div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="line-height:12.0pt;background:#FFEB9C"><b><span \
style="font-size:10.5pt;font-family:Lato;color:black">[External Email. Be cautious of \
content]<o:p></o:p></span></b></p> <p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi Shraddha,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">When you refer to “a single TE application”, it is \
not clear which one you are referring to : RSVP-TE or SR Policy? <o:p></o:p></p>
<p class="MsoNormal"><Shraddha> It could be either of them<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I believe, for ISIS, you are referring to this specific section \
of RFC8919 : <a href="https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html \
/rfc8919*section-6.1__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_AdZHekgKS$">
https://datatracker.ietf.org/doc/html/rfc8919#section-6.1</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There is no ambiguity here. This section is about use of \
“legacy” advertisement. The Generic Metric is a new TLV and hence cannot \
be considered as “legacy” by any interpretation of the \
word.<o:p></o:p></p> <p class="MsoNormal"><Shraddha> For ISIS, I hope you agree \
that generic metric sub-TLV is allowed to get advertised under TLV 22.<o:p></o:p></p> \
<p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Coming to OSPF, the \
considerations are similar. Additionally we also have to deal with different LSA \
types here.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Please refer to <a \
href="https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section \
-12.1__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_Adc5YCVr4$">
https://datatracker.ietf.org/doc/html/rfc8920#section-12.1</a> for the equivalent \
discussion for OSPF. This section is about “legacy” advertisements being \
in (RSVP) TE Opaque LSAs. If the TE application that you were referring to was \
RSVP-TE, then there is also additional guidance provided here : <a \
href="https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section \
-12.2.4__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_AdRkvFDI2$">
https://datatracker.ietf.org/doc/html/rfc8920#section-12.2.4</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Please clarify where RFC8920 describes advertisement of \
application-specific attributes in say OSPFv2 Extended Link LSA other than within the \
ASLA sub-TLV.<o:p></o:p></p> <p class="MsoNormal"><Shraddha> From what I \
understand, you agree that the generic metric sub-TLV should be allowed in TE Opaque \
LSA.<o:p></o:p></p> <p class="MsoNormal">You have concerns only on it being allowed \
in Extended Link opaque LSA top level Extended Link TLV right?<o:p></o:p></p> <p \
class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Ketan<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> \
Shraddha Hegde <<a href="mailto:shraddha@juniper.net">shraddha@juniper.net</a>> \
<br> <b>Sent:</b> 31 May 2021 09:13<br>
<b>To:</b> Ketan Talaulikar (ketant) <<a \
href="mailto:ketant@cisco.com">ketant@cisco.com</a>>; Tony Li <<a \
href="mailto:tony.li@tony.li">tony.li@tony.li</a>><br> <b>Cc:</b> Acee Lindem \
(acee) <<a href="mailto:acee=40cisco.com@dmarc.ietf.org">acee=40cisco.com@dmarc.ietf.org</a>>;
<a href="mailto:lsr@ietf.org">lsr@ietf.org</a>; <a \
href="mailto:draft-hegde-lsr-flex-algo-bw-con@ietf.org"> \
draft-hegde-lsr-flex-algo-bw-con@ietf.org</a><br> <b>Subject:</b> RE: [Lsr] LSR WG \
Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and \
Constraints" - draft-hegde-lsr-flex-algo-bw-con-02<o:p></o:p></span></p> </div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">Ketan,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Networks that deploy a single TE application \
and already advertising and using attributes from top level \
TLVs<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US">Will benefit from \
new attributes also coming in the same top level TLVs. There is no confusion and \
ambiguity<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US">from a \
network operators perspective and IMO this must be allowed in the \
protocol.<o:p></o:p></span></p> <p class="MsoNormal"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoNormal"><span lang="EN-US">If \
the attribute gets advertised in both ASLA and top level TLV, how the receiver should \
process it, has been<o:p></o:p></span></p> <p class="MsoNormal"><span \
lang="EN-US">described in RFC 8919 and 8920 and this draft will refer to the same \
procedures. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">If you think there is ambiguity in RFC 8919 \
and RFC 8920, pls provide specific cases that are ambiguous.<o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US">Rgds<o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US">Shraddha<o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="msipfooter30b3d538" align="center" style="margin:0cm;text-align:center"> <span \
lang="EN-US" style="font-size:7.0pt;color:black">Juniper Business Use \
Only</span><span lang="EN-US"><o:p></o:p></span></p> <div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Ketan \
Talaulikar (ketant) <<a href="mailto:ketant@cisco.com">ketant@cisco.com</a>> \
<br> <b>Sent:</b> Thursday, May 27, 2021 7:13 PM<br>
<b>To:</b> Shraddha Hegde <<a \
href="mailto:shraddha@juniper.net">shraddha@juniper.net</a>>; Tony Li <<a \
href="mailto:tony.li@tony.li">tony.li@tony.li</a>><br> <b>Cc:</b> Acee Lindem \
(acee) <<a href="mailto:acee=40cisco.com@dmarc.ietf.org">acee=40cisco.com@dmarc.ietf.org</a>>;
<a href="mailto:lsr@ietf.org">lsr@ietf.org</a>; <a \
href="mailto:draft-hegde-lsr-flex-algo-bw-con@ietf.org"> \
draft-hegde-lsr-flex-algo-bw-con@ietf.org</a><br> <b>Subject:</b> RE: [Lsr] LSR WG \
Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and \
Constraints" - draft-hegde-lsr-flex-algo-bw-con-02<o:p></o:p></span></p> </div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="line-height:12.0pt;background:#FFEB9C"><b><span \
style="font-size:10.5pt;font-family:Lato;color:black">[External Email. Be cautious of \
content]<o:p></o:p></span></b></p> <p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi Shraddha,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This is a new attribute that we are introducing and we are \
saying that it has application specific semantics. We now have the ASLA mechanics \
defined in both OSPF and ISIS. So why should it not use just the ASLA \
encoding?<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Allowing its advertisement in the existing top-level TLVs in \
addition to ASLA introduces ambiguity for which applications can use it – we \
get into complications that are entirely avoidable.<o:p></o:p></p> <p \
class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Ketan<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> \
Shraddha Hegde <<a href="mailto:shraddha@juniper.net">shraddha@juniper.net</a>> \
<br> <b>Sent:</b> 27 May 2021 18:36<br>
<b>To:</b> Ketan Talaulikar (ketant) <<a \
href="mailto:ketant@cisco.com">ketant@cisco.com</a>>; Tony Li <<a \
href="mailto:tony.li@tony.li">tony.li@tony.li</a>><br> <b>Cc:</b> Acee Lindem \
(acee) <<a href="mailto:acee=40cisco.com@dmarc.ietf.org">acee=40cisco.com@dmarc.ietf.org</a>>;
<a href="mailto:lsr@ietf.org">lsr@ietf.org</a>; <a \
href="mailto:draft-hegde-lsr-flex-algo-bw-con@ietf.org"> \
draft-hegde-lsr-flex-algo-bw-con@ietf.org</a><br> <b>Subject:</b> RE: [Lsr] LSR WG \
Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and \
Constraints" - draft-hegde-lsr-flex-algo-bw-con-02<o:p></o:p></span></p> </div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">Snipped..<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<ol style="margin-top:0cm" start="2" type="1">
<li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l5 \
level1 lfo1"> Since the draft is covering FlexAlgo, I would have expected that \
Generic Metric is carried only in the ASLA and this document specifies usage only for \
the FA application. Later this can be also used/extended for other applications but \
still within ASLA. Keeping an option of advertising both outside and within the ASLA \
is problematic – we will need precedence rules and such. I prefer we avoid this \
complication.<span style="font-size:12.0pt"><o:p></o:p></span></li></ol> <p \
class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We preferred avoiding ASLA.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><i>[KT] The text today does not \
avoid ASLA and in fact requires the use of ASLA (quite correctly) for FlexAlgo \
application. Peter has confirmed the same. I am simply asking to avoid the \
complications of using Generic Metric in both ASLA and outside it. Whatever new \
“application” we invent to use this generic metric type, can use ASLA so \
that the Generic Metric can be very cleanly shared between applications. The encoding \
allows for using the same value – sharing single advertisement across \
applications or doing a different one per-application.</i></b><o:p></o:p></p> <p \
class="MsoNormal"><span lang="EN-US"><Shraddha> Generic metric is allowed in \
ASLA, it is also allowed in all traditional TLVs/LSAs where link attributes are \
advertised.<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US">This is \
required so that all the applications, existing and new can make use of generic \
metric. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="msipfooter30b3d538" align="center" style="margin:0cm;text-align:center">
<span lang="EN-US" style="font-size:7.0pt;color:black">Juniper Business Use \
Only</span><span lang="EN-US"><o:p></o:p></span></p> <div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Ketan \
Talaulikar (ketant) <<a href="mailto:ketant@cisco.com">ketant@cisco.com</a>> \
<br> <b>Sent:</b> Wednesday, May 26, 2021 12:09 PM<br>
<b>To:</b> Tony Li <<a href="mailto:tony.li@tony.li">tony.li@tony.li</a>><br>
<b>Cc:</b> Acee Lindem (acee) <<a \
href="mailto:acee=40cisco.com@dmarc.ietf.org">acee=40cisco.com@dmarc.ietf.org</a>>;
<a href="mailto:lsr@ietf.org">lsr@ietf.org</a>; <a \
href="mailto:draft-hegde-lsr-flex-algo-bw-con@ietf.org"> \
draft-hegde-lsr-flex-algo-bw-con@ietf.org</a><br> <b>Subject:</b> RE: [Lsr] LSR WG \
Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and \
Constraints" - draft-hegde-lsr-flex-algo-bw-con-02<o:p></o:p></span></p> </div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="line-height:12.0pt;background:#FFEB9C"><b><span \
style="font-size:10.5pt;font-family:Lato;color:black">[External Email. Be cautious of \
content]<o:p></o:p></span></b></p> <p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi Tony,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Please check inline below.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Tony \
Li <<a href="mailto:tony1athome@gmail.com">tony1athome@gmail.com</a>> <b>On \
Behalf Of </b>Tony Li<br> <b>Sent:</b> 25 May 2021 00:15<br>
<b>To:</b> Ketan Talaulikar (ketant) <<a \
href="mailto:ketant@cisco.com">ketant@cisco.com</a>><br> <b>Cc:</b> Acee Lindem \
(acee) <<a href="mailto:acee=40cisco.com@dmarc.ietf.org">acee=40cisco.com@dmarc.ietf.org</a>>;
<a href="mailto:lsr@ietf.org">lsr@ietf.org</a>; <a \
href="mailto:draft-hegde-lsr-flex-algo-bw-con@ietf.org"> \
draft-hegde-lsr-flex-algo-bw-con@ietf.org</a><br> <b>Subject:</b> Re: [Lsr] LSR WG \
Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and \
Constraints" - draft-hegde-lsr-flex-algo-bw-con-02<o:p></o:p></span></p> </div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Hi Ketan,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">In general, I support the adoption of this document. There is, \
however, one specific point which is not clear to me (8) below that I would \
appreciate some clarity on before adoption.<span \
style="font-size:12.0pt"><o:p></o:p></span></p> </div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As the chairs have noted, adoption is binary and not contingent \
upon rough consensus on the content, just on rough consensus on the \
interest.<o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><b><i>[KT] I believe the WG has (or must have) the ability to \
determine portions of the proposal to adopt and/or to split documents. I have seen \
this in recent past in other WGs. In any case, it is not a point that I wish to argue \
or debate on – especially in the context of this document. My point (8) was \
clarified and hence I fall in the binary YES in this instance.</i></b><o:p></o:p></p> \
</div> <p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l6 \
level1 lfo2"> Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF \
allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, I do \
see MAX METRIC being referred to as 4,261,412,864.<span \
style="font-size:12.0pt"><o:p></o:p></span></li></ol> </blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Because I’m a lazy sod.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It’s far easier to detect metric overflow on three byte \
values than four byte values. True, four byte is not impossible, but it’s just \
quick and easy with three byte values. Adding a fourth byte would add range to \
the metric space, but in practice, this seemed like it was not really relevant. Most \
areas are not a very high diameter and the need for detailed metric distinctions has \
not been that high. Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) \
and that seems to work.<o:p></o:p></p> <p class="MsoNormal"><b><i>[KT] The Generic \
Metric is by definition something that will get extended in the future and we \
don’t know what use-cases might arise. It doesn’t seem right to follow in \
the steps of an administratively assigned metric type like the TE metric. Therefore, \
I suggest to make it variable.</i></b><o:p></o:p></p> </div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<p class="MsoNormal"><b><i>[KT] Regarding metric overflow, I think it would be better \
to leave it to implementations on how to deal with it. A guidance similar to below \
(from draft-ietf-lsr-flex-algo) would help handle the condition in a manner that does \
not cause interop issues. Theoretically, it is something that is independent of the \
size of the metric.<o:p></o:p></i></b></p> <p \
class="MsoNormal"><b><i><o:p> </o:p></i></b></p> <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:"Courier New";color:black"> \
During the route computation, it is possible for the \
Flex-Algorithm<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:"Courier New";color:black"> \
specific metric to exceed the maximum value that can be stored in \
an<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:"Courier New";color:black"> \
unsigned 32-bit variable. In such scenarios, the value MUST \
be<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:"Courier New";color:black"> \
considered to be of value 4,294,967,295 during the computation \
and<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:"Courier New";color:black"> \
advertised as such.<o:p></o:p></span></p> <p class="MsoNormal"><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l7 \
level1 lfo3"> <span style="font-size:12.0pt"><o:p> </o:p></span></li><li \
class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l7 level1 \
lfo3"> Would be good to cover the max-metric considerations for the Generic Metric. \
Similar to<span class="apple-converted-space"> </span><a \
href="https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr- \
flex-algo-15*section-15.3__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKigDlnfK$"><span \
style="color:#0563C1">https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3</span></a><span \
style="font-size:12.0pt"><o:p></o:p></span></li></ol> </blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Fair<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<ol style="margin-top:0cm" start="2" type="1">
<li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l1 \
level1 lfo4"> <span style="font-size:12.0pt"><o:p> </o:p></span></li><li \
class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l1 level1 \
lfo4"> Since the draft is covering FlexAlgo, I would have expected that Generic \
Metric is carried only in the ASLA and this document specifies usage only for the FA \
application. Later this can be also used/extended for other applications but still \
within ASLA. Keeping an option of advertising both outside and within the ASLA is \
problematic – we will need precedence rules and such. I prefer we avoid this \
complication.<span style="font-size:12.0pt"><o:p></o:p></span></li></ol> \
</blockquote> <div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We preferred avoiding ASLA.<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><i>[KT] The text today does not \
avoid ASLA and in fact requires the use of ASLA (quite correctly) for FlexAlgo \
application. Peter has confirmed the same. I am simply asking to avoid the \
complications of using Generic Metric in both ASLA and outside it. Whatever new \
“application” we invent to use this generic metric type, can use ASLA so \
that the Generic Metric can be very cleanly shared between applications. The encoding \
allows for using the same value – sharing single advertisement across \
applications or doing a different one per-application.</i></b><o:p></o:p></p> \
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <ol style="margin-top:0cm" \
start="3" type="1"> <li class="MsoListParagraph" \
style="margin-top:0cm;margin-bottom:0cm;mso-list:l4 level1 lfo5"> <span \
style="font-size:12.0pt"><o:p> </o:p></span></li><li class="MsoListParagraph" \
style="margin-top:0cm;margin-bottom:0cm;mso-list:l4 level1 lfo5"> For the newly \
proposed FAD b/w constraints, I would suggest the following names for the constraint \
sub-TLVs where the b/w value signalled by all is compared with the Max Link B/w \
attribute. This is just to make the meaning, at least IMHO, more clear.<span \
style="font-size:12.0pt"><o:p></o:p></span></li></ol> <ol style="margin-top:0cm" \
start="4" type="1"> <ol style="margin-top:0cm" start="1" type="a">
<li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l4 \
level2 lfo5"> Exclude Higher Bandwidth Links<span \
style="font-size:12.0pt"><o:p></o:p></span></li><li class="MsoListParagraph" \
style="margin-top:0cm;margin-bottom:0cm;mso-list:l4 level2 lfo5"> Exclude Lower \
Bandwidth Links<span style="font-size:12.0pt"><o:p></o:p></span></li><li \
class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l4 level2 \
lfo5"> Include-Only Higher Bandwidth Links<span \
style="font-size:12.0pt"><o:p></o:p></span></li><li class="MsoListParagraph" \
style="margin-top:0cm;margin-bottom:0cm;mso-list:l4 level2 lfo5"> Include-Only Lower \
Bandwidth Links<span style="font-size:12.0pt"><o:p></o:p></span></li></ol> </ol>
<ol style="margin-top:0cm" start="5" type="1">
<li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l4 \
level1 lfo5"> Similar naming for the FAD delay constraints as well would help. Though \
I can only think of the use of “exclude” for links above a certain delay \
threshold to be more practical but perhaps others might eventually be required as \
well?<span style="font-size:12.0pt"><o:p></o:p></span></li></ol> </blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Thank you for the suggestions.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<ol style="margin-top:0cm" start="5" type="1">
<li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l3 \
level1 lfo6"> <span style="font-size:12.0pt"><o:p> </o:p></span></li><li \
class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l3 level1 \
lfo6"> For the Max B/w Link attribute and its comparison with the FAD b/w \
constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not allowed \
in ASLA -<span class="apple-converted-space"> </span><a \
href="https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section \
-7__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKlvO8Grj$"><span \
style="color:#0563C1">https://datatracker.ietf.org/doc/html/rfc8920#section-7</span></a>,
in case of ISIS also, it is not really appropriate for use within ASLA -<a \
href="https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section \
-4.2.1__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKrdBaWXz$"><span \
style="color:#0563C1">https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1</span></a>?<span \
style="font-size:12.0pt"><o:p></o:p></span></li></ol> </blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I’m sorry, I don’t understand this \
comment.<o:p></o:p></p> <p class="MsoNormal"><b><i>[KT] In <a \
href="https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr \
-flex-algo-bw-con-02*section-3.2.1__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKn7h1XsO$">
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1</a><o:p></o:p></i></b></p>
<p class="MsoNormal"><b><i><o:p> </o:p></i></b></p>
<pre><span style="color:black">The Maximum Link Bandwidth as advertised by the \
sub-sub-<o:p></o:p></span></pre> <pre><span style="color:black"> TLV 23 \
of ASLA [<a href="https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc \
8920__;!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKiuV4Gz8$">RFC \
8920</a>] MUST be compared against the Minimum<o:p></o:p></span></pre> <pre><span \
style="color:black"> bandwidth advertised in FAEMB \
sub-TLV.<o:p></o:p></span></pre> <p \
class="MsoNormal"><b><i><o:p> </o:p></i></b></p> <p class="MsoNormal"><b><i>And \
in the <a href="https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc89 \
20*section-7__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKlvO8Grj$">
https://datatracker.ietf.org/doc/html/rfc8920#section-7</a><o:p></o:p></i></b></p>
<p class="MsoNormal"><b><i><o:p> </o:p></i></b></p>
<pre><span style="color:black">Maximum link bandwidth is an application-independent \
attribute of the<o:p></o:p></span></pre> <pre><span style="color:black"> \
link that is defined in [<a \
href="https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630__;!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKgE3htSJ$" \
title=""Traffic Engineering (TE) Extensions to OSPF Version \
2"">RFC3630</a>]. Because it is an application-<o:p></o:p></span></pre> \
<pre><span style="color:black"> independent attribute, it MUST NOT be \
advertised in the ASLA sub-TLV.<o:p></o:p></span></pre> <p \
class="MsoNormal"><b><i><o:p> </o:p></i></b></p> </div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><i>Somewhat similar for ISIS as \
well.</i></b><o:p></o:p></p> <blockquote \
style="margin-top:5.0pt;margin-bottom:5.0pt"> <ol style="margin-top:0cm" start="6" \
type="1"> <li class="MsoListParagraph" \
style="margin-top:0cm;margin-bottom:0cm;mso-list:l2 level1 lfo7"> <span \
style="font-size:12.0pt"><o:p> </o:p></span></li><li class="MsoListParagraph" \
style="margin-top:0cm;margin-bottom:0cm;mso-list:l2 level1 lfo7"> Document should \
cover the FAPM aspects for the Generic Metric and especially the Bandwidth \
metric.<span style="font-size:12.0pt"><o:p></o:p></span></li></ol> </blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Nor this one.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><i>[KT] Generic Metric is used for the links. When we get to \
the computation of inter-area or external routes, we will need to get into FAPM. The \
draft at a minimum should discuss the applicability of the Generic Metric and its use \
as FAPM. Now, if we do make the Generic Metric size variable (as suggested above), \
then we will likely need a new TLV for a variable size FAPM \
equivalent?</i></b><o:p></o:p></p> </div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<ol style="margin-top:0cm" start="7" type="1">
<li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l0 \
level1 lfo8"> <span style="font-size:12.0pt"><o:p> </o:p></span></li><li \
class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l0 level1 \
lfo8"> The document introduces a new Generic Metric type called Bandwidth metric. \
I’ve been trying to follow some of the discussion related to this on the \
mailing list – about it being cumulative or not. I am perhaps somewhat confused \
by those discussions. The OSPF/ISIS SPT computation has always worked with \
cumulative link (and prefix) metrics. If the computation for the Generic Metric of \
this new type b/w is not going to be cumulative (I thought it is – but not very \
clear anymore), then the document needs to describe the computation algorithm. Is it \
then hop count based? Perhaps I am missing something very basic here and if so, \
please point me to the text in the draft.<span \
style="font-size:12.0pt"><o:p></o:p></span></li></ol> <div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">I’m sorry if this has been confusing. My understanding is \
that the metric is cumulative. Others had other expectations.<o:p></o:p></p> <p \
class="MsoNormal"><b><i>[KT] Thanks for this important clarification. \
<o:p></o:p></i></b></p> <p class="MsoNormal"><b><i><o:p> </o:p></i></b></p>
<p class="MsoNormal"><b><i>Thanks,<o:p></o:p></i></b></p>
<p class="MsoNormal"><b><i>Ketan</i></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">When there are multiple links with the same bandwidth, and thus \
the same metric, then the total path metric becomes (link metric) * (number of \
links).<o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Regards,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Tony<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--===============1411336644311939432==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic