I believe we still have an opportunity to simplify ASLA as it is not that
widely deployed.
The inter-operability issues are almost always due to unclear and ambiguous
documentation
of standards. All we need is to ensure is that the protocol extensions have
unambiguous documentation.
The two main advantages of Any app are efficiency and simplicity.
The encoding efficiency of any app for common cases has been demonstrated in
the presentation.
The one byte overhead that Les brings about is a distraction. It's a always a
fixed additional one byte
for all vs any ,which is negligible whereas the benefits demonstrated for any
can be more if
more attributes fall in the same category.
Rgds
Shraddha
Juniper Business Use Only
-----Original Message-----
From: Lsr <lsr-boun...@ietf.org> On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, March 24, 2022 9:28 PM
To: Martin Horneffer <maho=40lab.dtag...@dmarc.ietf.org>; lsr@ietf.org
Subject: Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute
(ASLA) Any Application Bit
[External Email. Be cautious of content]
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 <lsr-boun...@ietf.org> On Behalf Of Martin Horneffer
> Sent: Thursday, March 24, 2022 8:18 AM
> To: lsr@ietf.org
> 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
> > Lsr@ietf.org
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls
> > r__;!!NEt6yMaO-gk!V5RKin1YGpQigF3VmYVUWGDYci9sKdmVO2ZnQFcsfnPZLpKnPU
> > SJ-ybjYmWKEQTW$
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!V5RKin1YGpQigF3VmYVUWGDYci9sKdmVO2ZnQFcsfnPZLpKnPUSJ-y
> bjYmWKEQTW$
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!V5RKin1YGpQigF3VmYVUWGDYci9sKdmVO2ZnQFcsfnPZLpKnPUSJ-ybjYmWKEQTW$
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
