Subject: Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

From: Christian Hopps <[email-masked]>
Date: Fri, 08 Apr 2022 08:01:26 -0400

Robert Raszuk <[email-masked]> writes:

> Hi Chris,
>
> It seems that there is a subtle but important element on which we may
> have different opinion. 
>
> You said: "has to deploy new software that contains the new Wizbang
> feature, right?"
>
> IMO however we are dealing with case where software already supports
> all required functions on a box. It is just not using it from day
> one. You buy a router with OS features which allow you to build zoo
> of different forwarding paradigms. 
>
> Say day one you see a need to enable flex-algo_1 You enable day one
> links to distribute link attributes required for this. 
>
> Day two you want to define new FAD and flood this enabling new
> flex-algo_2. You reuse already present link attributes entirely or
> partially in flex-algo_2 computation. You do not need to
> touch 100000s of links each time you enable new flex_algo. 

This is purely user interface code, you can do this w/o changing the on the wire standard encoding.

Thanks,
Chris.
[as wg-member]

> That's a selling point to me. 
>
> If we would expect that folks will limit flex-algo to just a few
> maybe this all does not matter. But if we see proposals with rainbow
> of colors each mapped to different flex-algo and perhaps subtle
> forwarding difference (same metric but just a different min threshold
> per each flex-algo) it seems pretty bad idea to explicitly enable
> each app each time such new threshold used to build different
> topology. 
>
> Example: 
>
> link attribute:  delay
>
> applications: 
>
> flex-algo_1 - build topology where max delay does not exceed 10 ms -
> color: premium best effort
> flex-algo_2 - build topology where max delay does not exceed 8 ms - 
> color: black
> flex-algo_3 - build topology where max delay does not exceed 6 ms -
> color: bronze
> flex-algo_4 - build topology where max delay does not exceed 4 ms -
> color: blue
> flex-algo_5 - build topology where max delay does not exceed 3 ms -
> color: silver
> flex-algo_6 - build topology where max delay does not exceed 3 ms -
> color: gold
>
> etc ... 
>
> Now tell me how does it make sense to enable each app on the link
> delay attribute ? 
>
> Cheers,
> Robert
>
>
>
> On Sat, Mar 26, 2022 at 6:42 AM Christian Hopps <[email-masked]>
> wrote:
>
>
>     Robert Raszuk <[email-masked]> writes:
>
>     > Les,
>     >
>     > I don't think this is noise. 
>     >
>     > Your examples are missing key operational consideration .. Link
>     > attribute applicable to ANY application may be advertised well
>     ahead
>     > of enabling such application in a network. 
>     >
>     > So requesting operator to always advertise tuple of app + attr
>     is not
>     > looking forward and makes unnecessary operational burden. 
>
>     [as wg-member]
>
>     Hi Robert,
>
>     Originally this was the argument that sort of put wind in the
>     sails (for me) for this any bit, but some more thinking about how
>     things would really work changed my mind.
>
>     In order for some new feature, let's call it Wizbang, to take
>     advantage of existing any bit marked attributes, the operator
>     still has to deploy new software that contains the new Wizbang
>     feature, right? So the addition of a new Wizbang bit pretty much
>     comes free for the operator.
>
>     So, this draft really is just about making the encoding a bit
>     more efficient.
>
>     I think if we were defining a new encoding, having this
>     functionality makes sense, but we aren't defining a new encoding.
>     The proposal is to change an existing published encoding, and the
>     bar has to be higher for that I think.
>
>     Thanks,
>     Chris.
>     [as wg member]
>
>
>     >
>     > Thx.
>     > R.
>     >
>
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 13 Apr 2022 16:54:04 -0400

All

I support Shraddha’s Any bit draft as I think of the change as am
optimization of existing ASLA RFC 8918 and 8919 taking into account
practical deployment considerations when the application specific attribute
differs and having to set the SABM / UDABM bit mask on every link on the
network.

The focus of RFC 8918 and 8919 is to solve the issue where the application
attribute is different and that is solved with the existing specification.
The zero length bit mask only helps if all the applications use the same
link attribute.  However, now if the link attribute is different for each
application, now you have to set the SABM/UDAM bit mask on every link on
the network.  So I do see that adds operational complexity.

I do have a concern about interoperability for devices supporting ASLA and
those supporting the Any bit.

So now if two applications have different attributes would they set the RFC
8918 and 8919 SADM/UDAM bit for the particular application as well as the
new any bit or would they now just set the any bit.  This is the case where
the application link attribute differs and so need to be advertised as
ASLA.  I see section 4 talks about backwards compatibility but I would
think to conform with ASLA the SADM/UDAM application specific but still
would need to be set with the use of Any bit.

I would think that would still be necessary to disambiguate the application
using the link which was the main goal of ASLA.

As for existing ASLA deployment considerations I think BGP-LS extension for
ASLA draft below would help with PCE centralized controller push of the
ASLA as part of the stateful PCE operation in mix environments with many
applications.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-app-specific-attr-08

Kind Regards

Gyan

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 14 Apr 2022 06:21:29 +0000

Gyan –

With respect, your post has several misunderstandings/inaccurate statements.
I hope you have read my earlier post: https://mailarchive.ietf.org/arch/msg/lsr/JuV6frOi7LD5ybsr2iPTCgTph2w/

Let me try to correct your statements – please see inline.

From: Gyan Mishra <[email-masked]>
Sent: Wednesday, April 13, 2022 1:54 PM
To: Christian Hopps <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Martin Horneffer <[email-masked]>; Robert Raszuk <[email-masked]>; Shraddha Hegde <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

All

I support Shraddha’s Any bit draft as I think of the change as am optimization of existing ASLA RFC 8918 and 8919 taking into account practical deployment considerations when the application specific attribute differs and having to set the SABM / UDABM bit mask on every link on the network.

The focus of RFC 8918 and 8919 is to solve the issue where the application attribute is different
[LES:] This is incorrect – and unfortunately is a common misunderstanding.
From the Introduction to RFC 8919:

“In recent years, new applications that have use cases for many of the link attributes historically used by RSVP-TE have been introduced. Such applications include Segment Routing (SR) Policy [SEGMENT-ROUTING<https://www.rfc-editor.org/rfc/rfc8919.html#I-D.ietf-spring-segment-routing-policy>] and Loop-Free Alternates (LFAs) [RFC5286<https://www.rfc-editor.org/rfc/rfc8919.html#RFC5286>]. This has introduced ambiguity in that if a deployment includes a mix of RSVP-TE support and SR Policy support, for example, it is not possible to unambiguously indicate which advertisements are to be used by RSVP-TE and which advertisements are to be used by SR Policy. If the topologies are fully congruent, this may not be an issue, but any incongruence leads to ambiguity.”

The first problem addressed by ASLA was to be able to identify which application(s) were using a given link attribute advertisement. This has nothing to do with whether a different value/application is required or not.

Once we had the ability to associate an advertisement with specific application(s), we clearly also had the ability to support different values/application for a given link attribute. But that does not mean that it is expected (let alone required) to have unique values/application. In fact, in most deployment cases, there are not different values/application – but there definitely are incongruent set of links per application and potentially incongruent sets of attributes/application on a given link.

It is an unfortunate fact that people get concerned about ASLA because they have a hard time trying to figure out how they could define different values for a given attribute/application. But that isn’t required by ASLA. We have the capability to do that if needed – but it isn’t required – and it is a serious mistake to make the statement you have made.

and that is solved with the existing specification. The zero length bit mask only helps if all the applications use the same link attribute.  However, now if the link attribute is different for each application, now you have to set the SABM/UDAM bit mask on every link on the network.  So I do see that adds operational complexity.
[LES:] The need for SABM does not go away because you have the Any bit. See my original email (referenced above) for examples which demonstrate that.
And “operational complexity” is NOT impacted by the protocol encoding. You, as an operator, have to configure what applications are using what link attribute values on each link. You most certainly do NOT have to configure how this is encoded on the wire (ALL, Individual App bits, or Any). Any configuration model that requires you to do that is fundamentally broken.
What does add operational complexity is the introduction of a third style of encoding (the proposed “Any”) – since you (the operator) have to monitor when it safe to enable use of this encoding.

I do have a concern about interoperability for devices supporting ASLA and those supporting the Any bit.

[LES:] Good that you see that. Though I would remind you that “Any” is an extension to ASLA – not an alternative to ASLA.

So now if two applications have different attributes would they set the RFC 8918 and 8919 SADM/UDAM bit for the particular application as well as the new any bit or would they now just set the any bit.  This is the case where the application link attribute differs and so need to be advertised as ASLA.  I see section 4 talks about backwards compatibility but I would think to conform with ASLA the SADM/UDAM application specific but still would need to be set with the use of Any bit.
[LES:] This paragraph is hard to parse. 😊
Best answer I can give is to read the encoding examples I provided in my original email.
There are currently two encoding syntaxes defined:
1)Explicit SABM mask
2)ALL (0 length SABM) – which has some restrictions

“Any” continues to use ASLA – it is in fact proposed as a bit reserved for it in SABM. It just removes some restrictions which are associated with use of ALL.
But it doesn’t provide any new capability i.e., any deployment scenario can be supported today without using “Any”.
What it does do is introduce added implementation complexity and added deployment complexity.

Note that one thing Shraddha and I agree on is that sending “Any” cannot be enabled until such time as all routers in the network support it at least for receive.
This isn’t “backwards compatibility” as I understand it – so for me the claim in Section 4 isn’t credible. But I am not going to spend cycles arguing over the meaning of the term.

I would think that would still be necessary to disambiguate the application using the link which was the main goal of ASLA.

As for existing ASLA deployment considerations I think BGP-LS extension for ASLA draft below would help with PCE centralized controller push of the ASLA as part of the stateful PCE operation in mix environments with many applications.

[LES:] Thanx for pointing this out. This actually adds to the cost of deploying “Any”. I had previously mentioned the implementation costs to IGPs – but I had overlooked the implementation costs for BGP-LS – which will be paid both on the encoding side and on the consumer client processing code.

Whether you like “Any” or don’t like “Any”, it is fair and accurate to say that adding “Any” support comes with significant implementation costs and significant deployment costs. If it allowed us to support deployment cases that otherwise could not be supported, then such costs might be justified – but it doesn’t.

    Les

Kind Regards

Gyan

On Fri, Apr 8, 2022 at 8:03 AM Christian Hopps <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Chris.
[as wg-member]

> On Sat, Mar 26, 2022 at 6:42 AM Christian Hopps <[email-masked]<mailto:[email-masked]>>
> wrote:
>
>
>     Robert Raszuk <[email-masked]<mailto:[email-masked]>> writes:
>
>     > Les,
>     >
> [email-masked]<mailto:[email-masked]>

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

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

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 14 Apr 2022 03:23:13 -0400

Les

Thanks for the clarification.  The Any versus All was confusing to me in
the presentation, and your examples at the beginning of this thread have
cleared up my confusion regarding ASLA and what Any bit brings to the table.

Responses in-line

On Thu, Apr 14, 2022 at 2:21 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> I hope you have read my earlier post:
> https://mailarchive.ietf.org/arch/msg/lsr/JuV6frOi7LD5ybsr2iPTCgTph2w/
>
>  Gyan> Your post really helps clarify ASLA for me and based on what your
> examples and analysis of Any bit draft, I don’t see any benefits to the
> draft and do agree it does add more complexity.
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Wednesday, April 13, 2022 1:54 PM
> *To:* Christian Hopps <[email-masked]>
> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; Martin Horneffer <
> [email-masked]>; Robert Raszuk <[email-masked]>; Shraddha Hegde <
> [email-masked]>; lsr <[email-masked]>
> *Subject:* Re: [Lsr] IETF13: Comments on The Application Specific Link
> Attribute (ASLA) Any Application Bit
>
>
>
> All
>
>
>
> attribute is different
> *[LES:] This is incorrect – and unfortunately is a common
> misunderstanding.*
>
      Gyan> Ack and thanks for the clarification of my misunderstandings

> *From the Introduction to RFC 8919:*
>
>
>
> *“In recent years, new applications that have use cases for many of the
> link attributes historically used by RSVP-TE have been introduced. Such
> applications include Segment Routing (SR) Policy [SEGMENT-ROUTING
> <https://www.rfc-editor.org/rfc/rfc8919.html#I-D.ietf-spring-segment-routing-policy>]
> and Loop-Free Alternates (LFAs) [RFC5286
> <https://www.rfc-editor.org/rfc/rfc8919.html#RFC5286>]. This has introduced
> ambiguity in that if a deployment includes a mix of RSVP-TE support and SR
> Policy support, for example, it is not possible to unambiguously indicate
> which advertisements are to be used by RSVP-TE and which advertisements are
> to be used by SR Policy. If the topologies are fully congruent, this may
> not be an issue, but any incongruence leads to ambiguity.”*
>
>
>
> *The first problem addressed by ASLA was to be able to identify which
> application(s) were using a given link attribute advertisement. This has
> nothing to do with whether a different value/application is required or
> not.*
>
> * Gyan> Ack*
>
> *Once we had the ability to associate an advertisement with specific
> application(s), we clearly also had the ability to support different
> values/application for a given link attribute.*
>
     Gyan> Ack

> * But that does not mean that it is expected (let alone required) to have
> unique values/application.*
>
     Gyan> Ack

> * In fact, in most deployment cases, there are not different
> values/application – but there definitely are incongruent set of links per
> application and potentially incongruent sets of attributes/application on a
> given link.*
>
> * Gyan> Ack and agreed that in general not different values/applications
> but possible incongruent links in the topology *
>
> *It is an unfortunate fact that people get concerned about ASLA because
> they have a hard time trying to figure out how they could define different
> values for a given attribute/application.*
>
      Gyan> Ack.  I think that sums it up that when most folks including
myself think of ASLA they think of the not so common use case different
values for a given attribute/application.  Agreed.

> *But that isn’t required by ASLA. *
>
      Gyan> Ack

> *We have the capability to do that if needed – but it isn’t required – and
> it is a serious mistake to make the statement you have made.*
>
> * Gyan>  Understood and am back tracking what I have said  based on  the
> clarification you provided with your original post.  *
>
>
>
> and that is solved with the existing specification. The zero length bit
> mask only helps if all the applications use the same link attribute.
> However, now if the link attribute is different for each application, now
> you have to set the SABM/UDAM bit mask on every link on the network.  So I
> do see that adds operational complexity.
>
> *[LES:] The need for SABM does not go away because you have the Any bit.
> See my original email (referenced above) for examples which demonstrate
> that.*
>

       Gyan>. This was quite confusing and you’d post really helps clarify
for me and I think as well others whom may have the same confusion

> *And “operational complexity” is NOT impacted by the protocol encoding. *
>
      Gyan> Ack

> *You, as an operator, have to configure what applications are using what
> link attribute values on each link. *
>
      Gyan>  Understood.

> *You most certainly do NOT have to configure how this is encoded on the
> wire (ALL, Individual App bits, or Any). Any configuration model that
> requires you to do that is fundamentally broken.*
>
>       Gyan> Ack

> *What does add operational complexity is the introduction of a third style
> of encoding (the proposed “Any”) – since you (the operator) have to monitor
> when it safe to enable use of this encoding.*
>
>  Gyan> Ack as well as possible interoperability issues.   Agreed
>
>
>
> *[LES:] Good that you see that. Though I would remind you that “Any” is an
> extension to ASLA – not an alternative to ASLA.*
>
>  Gyan> Ack and Understood
>
> So now if two applications have different attributes would they set the
> RFC 8918 and 8919 SADM/UDAM bit for the particular application as well as
> the new any bit or would they now just set the any bit.  This is the case
> where the application link attribute differs and so need to be advertised
> as ASLA.  I see section 4 talks about backwards compatibility but I would
> *[LES:] This paragraph is hard to parse. **😊*
>
> *Best answer I can give is to read the encoding examples I provided in my
> original email.*
>

       Gyan> I read the post and that really helped clarify my
understanding.

> *There are currently two encoding syntaxes defined:*
>
> *1)Explicit SABM mask*
>
> *2)ALL (0 length SABM) – which has some restrictions*
>
> * Gyan> Ack*
>
> *“Any” continues to use ASLA – it is in fact proposed as a bit reserved
> for it in SABM. It just removes some restrictions which are associated with
> use of ALL.*
>
      Gyan> Ack

> *But it doesn’t provide any new capability i.e., any deployment scenario
> can be supported today without using “Any”.*
>
>        Gyan> Ack.  Bottom line is that other then the added complexity and
possible interoperability issues there is no functionality gains with Any.
Agreed.  I am going back on what I stated and do not support the Any bit
proposal.  Thank you for the clarification of my misunderstandings.

> *What it does do is introduce added implementation complexity and added
> deployment complexity.*
>
> * Gyan> Ack. Completely agree *
>
> *Note that one thing Shraddha and I agree on is that sending “Any” cannot
> be enabled until such time as all routers in the network support it at
> least for receive.*
>

      Gyan> That would require software upgrade of all devices receiving
the Any bit.

> *This isn’t “backwards compatibility” as I understand it – so for me the
> claim in Section 4 isn’t credible. But I am not going to spend cycles
> arguing over the meaning of the term.*
>
>  Gyan> Ack.
>
>
>
> I would think that would still be necessary to disambiguate the
> application using the link which was the main goal of ASLA.
>
>
>
> As for existing ASLA deployment considerations I think BGP-LS extension
> for ASLA draft below would help with PCE centralized controller push of the
> *[LES:] Thanx for pointing this out. This actually adds to the cost of
> deploying “Any”. I had previously mentioned the implementation costs to
> IGPs – but I had overlooked the implementation costs for BGP-LS – which
> will be paid both on the encoding side and on the consumer client
> processing code.*
>
> *Gyan> Welcome. I agree this adds cost to deployments of Any for encoding
> and receive side client processing code.  Agreed  *
>
> *Whether you like “Any” or don’t like “Any”, it is fair and accurate to
> say that adding “Any” support comes with significant implementation costs
> and significant deployment costs. If it allowed us to support deployment
> cases that otherwise could not be supported, then such costs might be
> justified – but it doesn’t.*
>
> * Gyan>  Completely agree that “Any” in summary  does provide any
> additional functionality that does not exist with ASLA today and at a high
> implementation cost for IGP as well as BGP-LS.  Thank you Les for the
> clarification on my ASLA misunderstandings!*
>

> *    Les*
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*