Shraddha -
RFCs 8919/8920 were published in October 2020 - and implementations based on
draft versions of those document date back as much as two years before that.
They all are written to support the encoding formats defined in the RFCs.
The introduction of an additional way of encoding the same information is
anything but "simplifying". As I have described below, you are imposing a
requirement for ALL ASLA implementations to support an additional encoding
format - at least for receiving.
This does not simplify implementations - it further complicates them. And it
increases the possibility of interoperability issues.
It also does not simplify deployments. You impose requirements on operators to
track which of the multiple formats are supported by each of the router
versions deployed in their network so they can decide when it is safe to enable
sending of the new format.
For any protocol extension, there are almost always multiple possible syntaxes
which could have been defined to advertise the necessary information. The point
of having a standard is to define an agreed upon format so that
interoperability can be achieved.
Please do not complicate implementations/deployments for a feature which
already has a fully functional standard and multiple implementations deployed
based on that standard.
Les
> -----Original Message-----
> From: Lsr <lsr-boun...@ietf.org> On Behalf Of Shraddha Hegde
> Sent: Friday, March 25, 2022 2:22 AM
> To: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; 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
>
>
> 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
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
