Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Les,

Just a short comment on the RSVP-TE part.

We do have a R bit for RSVP-TE in ASLA SABM so I don’t see the need for the advertisement under TLV 22 (et all) in ISIS.

Similar applies for OSPF too, but in that case, there is a separate TE Opaque LSA that is dedicated for RSVP-TE and hence advertisement as a sub-TLV there that may be considered (as per RFC8920). However, even in OSPF it doesn’t make sense to have it as application independent under the OSPFv2 Extended Link LSA as that is not really used by RSVP-TE today.

Thanks,
Ketan

From: Lsr <[e-mail]> On Behalf Of Les Ginsberg (ginsberg)
Sent: 24 July 2021 00:48
To: Gyan Mishra <[e-mail]>; Peter Psenak (ppsenak) <[e-mail]>
Cc: [e-mail]; Ron Bonica <[e-mail]>; Shraddha Hegde <[e-mail]>; [e-mail]; [e-mail]; Acee Lindem (acee) <[e-mail]>
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

Gyan –

I do not see Generic Metric as an application independent link attribute.
It is an attribute that could be used by multiple applications – in which case you would advertise it in ASLA with the logical OR of all of the applications using it.

The only existing example of an application independent attribute is Maximum Link Bandwidth. This is an attribute of the physical link – independent of the application(s) which use it – in which case https://www.rfc-editor.org/rfc/rfc8919.html#section-4.2.1 applies.
If some other attribute is ever defined which has the same characteristic, then I would expect the same advertisement model to be used.

Metric – in all its forms (whether TE, Delay, or now Generic) – is not a property of the physical link. It is – as Peter has described - a value that is configured or computed to be used by one or more applications. I do not see the need to define an application independent method of advertising it.

If one believes that legacy applications such as RSVP-TE will be extended to support Generic Metric, then a valid argument can be made for supporting advertisement of Generic Metric as a direct sub-TLV in TLVs 22 et al as well as ASLA. I would be somewhat surprised if RSVP-TE were extended in this way, but that is up to the marketplace to decide.

   Les

From: Gyan Mishra <[e-mail]<mailto:[e-mail]>>
Sent: Friday, July 23, 2021 11:44 AM
To: Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>
Cc: Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>; Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; Ron Bonica <[e-mail]<mailto:[e-mail]>>; Shraddha Hegde <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt


Peter

How would you advertise Generic metric link attribute in Flex Algo as both ASLA and application independent?

For ASLA you set the bit vector but application independent in ASLA what do you do?

Kind Regards

Gyan

On Fri, Jul 23, 2021 at 4:19 AM Peter Psenak <ppsenak=[e-mail]<mailto:[e-mail]>> wrote:
Hi Ron,

keeping the normative statements aside.

We are defining a Generic Metric TLV.

1. The first and only defined usage at this point is for Flex-algo.

2. Generic Metric is not something that must be defined as application
independent, on the contrary, it's a value that is either assigned by
operator or computed somehow. Advertising application specific values
not only make sense, but would add value. TE metric is an example which
is very close to Generic Metric and is supported in ASLA.

3. Flex-algo is an application from the ASLA framework perspective and
so far is only using ASLA encoded link attributes. It would make sense
to continue to do so for Generic Metric.

4. If you feel you need the Generic Metric also as an application
independent value, I'm fine, although I do not see the immediate use case.

Given the above, would not you thing that advertising Generic Metric in
ASLA make sense?

thanks,
Peter








On 23/07/2021 06:13, Ron Bonica wrote:
> Les,
>
> Please, let us avoid discussion of whether my message is disingenuous. As Acee will agree, discussion of my internal motivations and moral deficiencies is beyond the scope of the LSR WG.
>
> Now, let us address my point and your counter points. My point was that draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919. Nothing more, nothing less.
>
> In your counterpoint #1, you point out tension between draft-ietf-lsr-flex-algo-bw-con and draft-ietf-lsr-flex-algo. While this point deserves discussion, it is orthogonal to my point. It is entirely possible that both of the following statements are true:
>
> - draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919
> - there is tension between draft-ietf-lsr-flex-algo-bw-con and draft-ietf-lsr-flex-algo
>
> In your counterpoint #2, you talk about the "clear intent" of RFC 8919. Section 6.1 of RFC 8919 reduces that intent to a few very clear normative statements. Draft-ietf-lsr-flex-algo-bw-con does not violate any of those normative statements. Therefore, it does not violate RFC 8919.
>
> You may say:
>
> - Section 6.1 should have included more prohibitions
> - The authors had additional prohibitions in mind when they wrote the draft, but failed to add them to Section 6.1
>
> That's all fine, but the community agreed only to the words on the page, not the authors larger intent.
>
>                                                                                                        Ron
>
>
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Les Ginsberg (ginsberg) <ginsberg=[e-mail]<mailto:[e-mail]>>
> Sent: Thursday, July 22, 2021 2:49 PM
> To: Ron Bonica <[e-mail]<mailto:[e-mail]>>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>; Shraddha Hegde <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>
> [External Email. Be cautious of content]
>
>
> Ron -
>
> With respect, it is hard to read your email without feeling that it is disingenuous.
>
> But, let's cover the relevant points nonetheless.
>
> Point #1:
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17*section-12__;Iw!!NEt6yMaO-gk!XOCcoj-YdMkhznRiGAo1oeY1A6HMHuk5BDmsYqHAUf_hYgKb9tlp_Umpu3UxZFFM$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17*section-12__;Iw!!NEt6yMaO-gk!XOCcoj-YdMkhznRiGAo1oeY1A6HMHuk5BDmsYqHAUf_hYgKb9tlp_Umpu3UxZFFM$>  states:
>
> " Link attribute advertisements that are to be used during Flex-
>     Algorithm calculation MUST use the Application-Specific Link
>     Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920]..."
>
> As the new generic-metric is intended for use by flex-algo it needs to conform to this normative statement.
>
> Point #2:
>
> RFC 8919 and 8920 were written to address ambiguities associated with the use of multiple applications.
> The Introduction sections of both documents discuss this in some detail.
>
> The clear intent is to make use of ASLA going forward - not to restrict ASLA only to the set of link attributes defined at the time of the writing of the RFCs. Failure to do so would reintroduce the same set of issues that RFC 8919/8920 were written to address.
> Your attempt to infer that because Generic-Metric was not defined at the time that RFC 8919/8920 were written that the RFCs don’t apply to it makes no sense.
> ASLA is in fact a revision to the link attribute architecture and is meant to be used going forward.
>
> The more appropriate question to ask is why we need to define a legacy style sub-TLV for new link attributes? Ketan has made this point in his post on this thread and I have sympathy with his position.
>
> We do understand that legacy applications such as RSVP-TE may continue to be deployed in networks for some time to come. It is not reasonable to expect that legacy application implementations will be updated to use ASLA, which is why I do not object to defining a legacy style encoding for Generic Metric if folks believe that legacy applications may be enhanced to support new link attributes.
>
> I strongly disagree with your interpretation that ASLA is limited only to the code points defined in RFC 8919/8920.
>
>     Les
>
>
>> -----Original Message-----
>> From: Ron Bonica <rbonica=[e-mail]<mailto:[e-mail]>>
>> Sent: Thursday, July 22, 2021 10:28 AM
>> To: Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>; Les Ginsberg (ginsberg)
>> <[e-mail]<mailto:[e-mail]>>; Shraddha Hegde <[e-mail]<mailto:[e-mail]>>;
>> [e-mail]<mailto:[e-mail]>; Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>;
>> [e-mail]<mailto:[e-mail]>
>> Cc: [e-mail]<mailto:[e-mail]>
>> Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>>
>> Acee,
>>
>> I don't think that draft-ietf-lsr-flex-algo-bw-con violates RFC 8919.
>>
>> Section 6.1 of RFC 8919 says:
>>
>> " New applications that future documents define to make use of the
>>     advertisements defined in this document MUST NOT make use of legacy
>>     advertisements.  This simplifies deployment of new applications by
>>     eliminating the need to support multiple ways to advertise attributes
>>     for the new applications."
>>
>> Section 3 of RFC 8919 defines legacy advertisements. The definition of
>> legacy advertisements does not include new attributes such as generic
>> metric. Therefore draft-ietf-lsr-flex-algo-bw-con does not violate RFC
>> 8919
>>
>> Relevant text from Section 3 of RFC 8919 is included below for convenience.
>>
>>
>> Ron
>>
>>
>> RFC 8919, Section 3
>> ---------------------------
>> 3.  Legacy Advertisements
>>
>>
>> Existing advertisements used in support of RSVP-TE include sub-TLVs
>>     for TLVs 22, 23, 25, 141, 222, and 223 and TLVs for Shared Risk Link
>>     Group (SRLG) advertisement.
>>
>>     Sub-TLV values are defined in the "Sub-TLVs for TLVs 22, 23, 25, 141,
>>     222, and 223" registry.
>>
>>     TLVs are defined in the "TLV Codepoints Registry".
>>
>> 3.1.  Legacy Sub-TLVs
>>
>>     +======+====================================+
>>     | Type | Description                        |
>>     +======+====================================+
>>     | 3    | Administrative group (color)       |
>>     +------+------------------------------------+
>>     | 9    | Maximum link bandwidth             |
>>     +------+------------------------------------+
>>     | 10   | Maximum reservable link bandwidth  |
>>     +------+------------------------------------+
>>     | 11   | Unreserved bandwidth               |
>>     +------+------------------------------------+
>>     | 14   | Extended Administrative Group      |
>>     +------+------------------------------------+
>>     | 18   | TE Default Metric                  |
>>     +------+------------------------------------+
>>     | 33   | Unidirectional Link Delay          |
>>     +------+------------------------------------+
>>     | 34   | Min/Max Unidirectional Link Delay  |
>>     +------+------------------------------------+
>>     | 35   | Unidirectional Delay Variation     |
>>     +------+------------------------------------+
>>     | 36   | Unidirectional Link Loss           |
>>     +------+------------------------------------+
>>     | 37   | Unidirectional Residual Bandwidth  |
>>     +------+------------------------------------+
>>     | 38   | Unidirectional Available Bandwidth |
>>     +------+------------------------------------+
>>     | 39   | Unidirectional Utilized Bandwidth  |
>>     +------+------------------------------------+
>>
>>         Table 1: Sub-TLVs for TLVs 22, 23, 25,
>>                   141, 222, and 223
>>
>>
>>
>> Juniper Business Use Only
>>
>> -----Original Message-----
>> From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of Acee Lindem (acee)
>> Sent: Tuesday, July 20, 2021 1:21 PM
>> To: Les Ginsberg (ginsberg) <ginsberg=[e-mail]<mailto:[e-mail]>>;
>> Shraddha Hegde <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;
>> ppsenak=[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
>> Cc: [e-mail]<mailto:[e-mail]>
>> Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>>
>> [External Email. Be cautious of content]
>>
>>
>> Speaking as WG member:
>>
>> I agree with Les. The Generic Metric MUST be advertised as an ASLA for
>> usage in Flex Algorithm. Additionally, it may be advertised as a
>> sub-TLV in IS- IS link TLVs. However, the latter encoding really
>> shouldn't be used for new applications (at least that is my reading of RFC 8919).
>>
>> For OSPF, I'd certainly hope one wouldn't originate additional LSAs
>> when an ASLA can support the legacy applications with the ASLA mask.
>>
>> Thanks,
>> Acee
>>
>>
>
>

_______________________________________________
Lsr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lsr
--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347