Les,
There is clearly a valid case for having attributes common to all
applications. Duplicating those on a per application is perhaps a way, but
is this the most efficient way encoding wise ?
Thx,
R.
On Fri, Mar 25, 2022 at 1:02 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com>
wrote:
> Robert –
>
>
>
> As I have stated in my original comments:
>
>
>
> <snip>
>
> 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.
>
> <end snip>
>
>
>
> I don’t think there is anything else that needs to be said.
>
>
>
> Les
>
>
>
> *From:* Robert Raszuk <rob...@raszuk.net>
> *Sent:* Friday, March 25, 2022 4:53 AM
> *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com>
> *Cc:* Shraddha Hegde <shrad...@juniper.net>; Martin Horneffer <
> m...@lab.dtag.de>; lsr@ietf.org
> *Subject:* Re: [Lsr] IETF13: Comments on The Application Specific Link
> Attribute (ASLA) Any Application Bit
>
>
>
>
>
> I am afraid not .. I am exploring how to solve requirement. Proposed
> method is natural and reuses ASLA encoding. There is apparently a wall this
> proposal is facing.
>
>
>
> So trying to see how to bypass that wall (or jump over it).
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
>
>
> On Fri, Mar 25, 2022 at 12:50 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Robert –
>
>
>
> I find your post a non-sequitar.
>
>
>
> ASLA ANY is NOT discussing advertising a new attribute. It is discussing a
> new format for the ASLA sub-TLV container inside of which link attribute
> values are advertised.
>
>
>
> You are off-topic with your post.
>
>
>
> Les
>
>
>
>
>
> *From:* Robert Raszuk <rob...@raszuk.net>
> *Sent:* Friday, March 25, 2022 4:41 AM
> *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com>
> *Cc:* Shraddha Hegde <shrad...@juniper.net>; Martin Horneffer <
> m...@lab.dtag.de>; lsr@ietf.org
> *Subject:* Re: [Lsr] IETF13: Comments on The Application Specific Link
> Attribute (ASLA) Any Application Bit
>
>
>
> Hi Les,
>
>
>
> Let me clarify if I read you correctly ...
>
>
>
> Are you saying that because quoted RFCs have been published in Oct 2020 no
> one has a right to define any new standard link attributes any more as
> implementations are closed ? Including those which would be common to all
> applications on a link ?
>
>
>
> So if anyone would like to add their own new attributes one needs to
> define new sub-TLV codepoint to encode it outside of ASLA ? If so please
> state it then we could update the draft accordingly.
>
>
>
> Yes deployment of those is a challenge, but I am afraid this is a
> challenge with every protocol extensions unless we use mechanism like
> capabilities which will assist in an automated way.
>
>
>
> Thx,
>
> Robert.
>
>
>
>
>
> On Fri, Mar 25, 2022 at 11:39 AM Les Ginsberg (ginsberg) <ginsberg=
> 40cisco....@dmarc.ietf.org> wrote:
>
> 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
> <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_
> <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__
> <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
>
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
