Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

>There is a statement in Section 4:

>" The solution described in this document is backward compatible with
 >  [RFC8919] and [RFC8920]."

>This is FALSE.

>Implementations which do NOT support the new A-bit would ignore it and not use the link attributes advertised >with only the A-bit. So, in order to use it all nodes have to support the A-bit - or at least all nodes on which the >applications which you want to use A-bit advertisements must support it. Otherwise, for a given application, some >nodes will believe a link can be used by that application and other nodes will believe that the link cannot be used by >that application - which is likely to break the deployment of that application.

The draft clearly states that if there are advertisements with specific application bit set, that attribute MUST be picked by the application. So a node that is upgraded to advertise A bit can continue to advertise attributes with
Specific application bit set until all participating nodes in that application are upgraded to understand A bit.
It is quite obvious that until all nodes are upgraded to understand new bit, they cant use it. But as long as the
New bit procedures  ensures and honors the old advertisements, and does not cause inconsistencies between 
Upgraded and not upgraded nodes in the network it is backward compatible. 

For example, if the new A bit procedures mandated the attributes under A bit gets precedence then that would
Not be backward compatible.

Rgds
Shraddha

Juniper Business Use Only

-----Original Message-----
From: Lsr <lsr-bounces@ietf.org> On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, August 21, 2021 12:08 AM
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

[External Email. Be cautious of content]

Draft authors -

Comment #1

Regarding the example discussed in the Introduction, let's see if I understand it correctly.

There are three (possibly more) applications enabled in the network. Let's call them X, Y, and Z.
There are two attribute types being advertised on a given (set of) link(s).

Attribute 1: To be used by X, Y, and Z
Attribute 2: To be used by X and Y only.

If we use existing RFC 8919/8920 rules, here is how this would be advertised for a given link:

ASLA sub-TLV #1:
   SABM = X|Y|Z
   Attribute 1 Value

ASLA sub-TLV #2:
  SABM = X|Y
  Attribute 2 Value

If we use your new proposal with the "A" bit, here is how the advertisements would look:

ASLA sub-TLV #1:
   SABM = A
   Attribute 1 Value

ASLA sub-TLV #2:
  SABM = X|Y
  Attribute 2 Value

I do not see any value add here to your proposal.
???

Perhaps you are thinking about what happens when a fourth application is introduced into the network (let's call it "W").
If we wanted W to also use attribute #1, then using RFC 8919/8920 rules we would alter sub-TLV #1 to include "W":

ASLA sub-TLV #1:
   SABM = W|X|Y|Z
   Attribute 1 Value

Whereas when using the A-bit you could continue to use sub-TLV#1 w A bit unchanged.

But, use of all applications encoding - whether using RFC 8919/8920 zero length ABM or potentially a new "A" bit, has to be done with care. This is discussed in some detail in https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8919.html*section-6.2__;Iw!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D0bYvTkV3P5eLay-Idc_l_ZIaEFgbm5geHR43u3f$
It is not just that a new application wants to use the same link attribute value that allows you to use the "all applications" encoding. It is also necessary for the set of links used by the new application to be identical to the set of links used by the existing applications.
RFC 8919/8920 provides for "all applications" in order to gain encoding efficiency when possible, but because it is not just attribute type/value sharing that is required but also identical set of links/application, the usefulness of such encoding is limited.
Although there may be some situations where it is possible for an "all applications" encoding to be used, it requires some amount of clairvoyance since one does not know what set of links a new application might want to use until it comes time to actually deploy that new application.

Comment #2:

There is a statement in Section 4:

" The solution described in this document is backward compatible with
   [RFC8919] and [RFC8920]."

This is FALSE.

Implementations which do NOT support the new A-bit would ignore it and not use the link attributes advertised with only the A-bit. So, in order to use it all nodes have to support the A-bit - or at least all nodes on which the applications which you want to use A-bit advertisements must support it. Otherwise, for a given application, some nodes will believe a link can be used by that application and other nodes will believe that the link cannot be used by that application - which is likely to break the deployment of that application.

   Les

> -----Original Message-----
> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Ron Bonica
> Sent: Thursday, August 19, 2021 8:35 PM
> To: lsr@ietf.org
> Subject: [Lsr] FW: New Version Notification for 
> draft-hegde-lsr-asla-any-app- 00.txt
>
> Folks,
>
> Please review and comment.
>
>                         Ron
>
>
>
> Juniper Business Use Only
>
> > -----Original Message-----
> > From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> > Sent: Thursday, August 19, 2021 11:31 PM
> > To: Chris Bowers <cbowers@juniper.net>; Robert Raszuk 
> > <robert@raszuk.net>; Ron Bonica <rbonica@juniper.net>; Shraddha
> Hegde
> > <shraddha@juniper.net>; Zhenbin Li <lizhenbin@huawei.com>
> > Subject: New Version Notification for 
> > draft-hegde-lsr-asla-any-app-00.txt
> >
> > [External Email. Be cautious of content]
> >
> >
> > A new version of I-D, draft-hegde-lsr-asla-any-app-00.txt
> > has been successfully submitted by Ron Bonica and posted to the IETF 
> > repository.
> >
> > Name:           draft-hegde-lsr-asla-any-app
> > Revision:       00
> > Title:          The Application Specific Link Attribute (ASLA) Any Application Bit
> > Document date:  2021-08-19
> > Group:          Individual Submission
> > Pages:          6
> > URL:
> > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-he
> > gde-lsr-asla-any-app-00.txt__;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1
> > D0bYvTkV3P5eLay-Idc_l_ZIaEFgbm5geAxsITdt$
> > Status:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-h
> > egde-lsr-asla-any-app__;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D0bYvT
> > kV3P5eLay-Idc_l_ZIaEFgbm5geNWXUEXS$
> > Htmlized:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
> > aft-hegde-lsr-asla-any-app__;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D
> > 0bYvTkV3P5eLay-Idc_l_ZIaEFgbm5geFUeB-LY$
> >
> >
> > Abstract:
> >    RFC 8919 and RFC 8920 define Application Specific Link Attributes
> >    (ASLA).  Each ASLA includes an Application Identifier Bit Mask.  The
> >    Application Identifier Bit Mask includes a Standard Application Bit
> >    Mask (SABM) and a User Defined Application Bit Mask (UDABM).  The
> >    SABM and UDABM determine which applications can use the ASLA as an
> >    input.
> >
> >    This document introduces a new bit to the Standard Application
> >    Identifier Bit Mask.  This bit is called the Any Application Bit
> >    (i.e., the A-bit).  If the A-bit is set, the link attribute can be
> >    used by any application.  This includes currently defined
> >    applications as well as applications to be defined in the future.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D0bYvTkV3P5eLay-Idc_l_ZIaEFgbm
> 5geLZeit_R$

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D0bYvTkV3P5eLay-Idc_l_ZIaEFgbm5geLZeit_R$