Martin - I hear you.
The reality is that ASLA need not be that complex. In many deployments life is simple. There are a small number of applications using the same set of values on each link. >From an encoding standpoint, all that needs to be done is to send a single >ASLA sub-TLV that lists the applications and the link attributes. The use of ALL applications is only an encoding optimization - it isn't required. In hindsight, maybe we should never have defined it - but it seemed like a nice optimization at the time. But certainly, we should not further complicate things - both for implementations and deployments - by defining yet another encoding option. As you suggest below, this increases the possibility of interoperability issues w/o providing significant benefit. ASLA is needed. There are real world examples where it is necessary to identify on each link which applications are using the advertised link attribute values. Les > -----Original Message----- > From: Lsr <[email protected]> On Behalf Of Martin Horneffer > Sent: Thursday, March 24, 2022 8:18 AM > To: [email protected] > Subject: Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute > (ASLA) Any Application Bit > > Dear WG, > > as we just had this discussion and acoustics in the room didn't appear > to be good I was asked to post my comment to the list: > > Not a comment on the idea of the ANy Application bit per se, nor on Les' > discussion. Rather a ceterum censeo on ASLA in general: > In my opinion this discussion shows that ASLA itself is overly complex. > > Let's just hope this discussion gets resolved quickly, and doesn't > provide yet another source for interoperability issues between vendors. > We already have more than enough of them. > > Best regards, > Martin > > > Am 24.03.22 um 06:05 schrieb Les Ginsberg (ginsberg): > > Folks - > > > > > > > > Now that the slides have been posted for this presentation, I am going to > send some early comments. > > > > I do this because - as usual - the agenda for the meeting is packed and it > > is > likely there will be little time for discussion during the meeting. > > > > Also my comments are lengthy, it would be difficult to present them during > the meeting. > > > > > > > > As always, discussion can occur on the list, but if Shraddha has a chance to > review these comments in the limited time before the meeting and has a > chance to respond to them during her presentation so much the better, but I > am not expecting that. > > > > > > > > COMMENT 1 > > > > > > > > Existing encoding defined in RFCs 8919/8920 is fully functional i.e., the > introduction of ANY application does not add support for deployment > scenarios that could not otherwise be supported. > > > > > > > > COMMENT 2 > > > > > > > > The argument in the presentation is that ANY application encoding adds a > significant amount of efficiency to the encoding. But this requires closer > scrutiny. > > > > > > > > (Aside: The example discussed in the presentation includes the use of link > attributes Maximum reservable link bandwidth(10) and Unreserved > bandwidth(11) - which are link attributes only usable by RSVP-TE application. > > > > As such, they are not candidates to be advertised using either the ANY bit > or the ALL encoding defined in RFCs 8919/8920. > > > > In the examples below I assume the attributes being used are potentially > usable by all applications.) > > > > > > > > Assume we have the following applications: APP1 APP2 APP3 > > > > Assume we have the following link attributes: ATTR1 ATTR2 ATTR3 > > > > > > > > Example 1 (analogous to the example in Shraddha's presentation) > > > > > > > > ATTR1 and ATTR2 have a value usable by all applications. > > > > ATTR3 has two values: > > > > One usable by APP1 and APP2 - call it ATTR3-12 > > > > One usable only by APP3 - call it ATTR3-3 > > > > > > > > Encoding using ANY requires two ASLA sub-TLVs > > > > Sub-TLV1: ANY: Attributes ATTR1 ATTR2 ATTR3-12 > > > > Sub-TLV2: APP3: Attributes ATTR3-3 > > > > > > > > Encoding using RFC 8919 rules requires three ASLA sub-TLVs: > > > > Sub-TLV1: APP1|APP2|APP3: Attributes ATTR1 ATTR2 > > > > Sub-TLV2: APP1|APP2: Attribute ATTR3-12 > > > > Sub-TLV3: APP3: Attributes ATTR3-3 > > > > > > > > ANY encoding saves 5 bytes > > > > > > > > > > > > Example 2 > > > > > > > > All applications share the same attribute value for ATTR1 and ATTR2. > > > > Each application has a unique value for ATTR3. > > > > > > > > Encoding using ANY requires four ASLA sub-TLVs > > > > Sub-TLV1: ANY APP: Attributes ATTR1 ATTR2 > > > > Sub-TLV2: APP1: Attributes ATTR3-1 > > > > Sub-TLV3: APP2: Attributes ATTR3-2 > > > > Sub-TLV4: APP3: Attributes ATTR3-3 > > > > > > > > > > > > Encoding using RFC 8919 rules requires four ASLA sub-TLVs: > > > > Sub-TLV1: APP1|APP2|APP3: Attributes ATTR1 ATTR2 > > > > Sub-TLV2: APP1: Attributes ATTR3-1 > > > > Sub-TLV3: APP2: Attributes ATTR3-2 > > > > Sub-TLV4: APP3: Attributes ATTR3-3 > > > > > > > > Same byte usage for both approaches > > > > > > > > Example 3 > > > > > > > > All applications share the same attribute value for all attributes. > > > > > > > > Encoding using ANY requires one ASLA sub-TLV > > > > Sub-TLV1: ANY APP: Attributes ATTR1 ATTR2 ATTR3 > > > > > > > > Encoding using RFC 8919 rules requires one ASLA sub-TLV: > > > > Sub-TLV1: 0 length SABM: Attributes ATTR1 ATTR2 ATTR3 > > > > > > > > RFC 8919 encoding saves one byte (because it does not have to include any > SABM) > > > > > > > > What is the point of this??? > > > > Simply to demonstrate that ANY encoding does NOT guarantee more > efficient encoding - it depends on the actual deployment scenario. > > > > Suggesting that ANY is always more efficient is FALSE. > > > > > > > > COMMENT 3 > > > > > > > > There are multiple interoperable implementations of RFC 8919 deployed > today. ANY support is of course not included. > > > > Introducing a new form of ASLA advertisement ("ANY") comes with the > following costs: > > > > > > 1)All implementations MUST add support for receiving ANY > > > > 2)Any implementation wanting to send ANY must implement ANY Tx > support (as well as the ALL/Explicit APP defined in RFC 8919.) > > > > 3)As it is not safe to send ANY until all deployed implementations at least > support receiving ANY, implementations wanting to send ANY MUST provide > controls to allow > > the operator to enable/disable the sending of ANY and the operator MUST > track the capabilities of the nodes deployed in the network to determine > when it is safe to enable sending of ANY. > > > > SUMMARY COMMENT > > > > ANY does not provide additional functionality. > > ANY does not guarantee encoding efficiency. > > ANY increases implementation complexity > > ANY increases feature deployment complexity > > > > For me, the costs in implementation/deployment complexity far outweigh > the very minimal efficiency benefits of the new encoding - which are not > even guaranteed to exist in all deployments. > > > > Les > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
