Hi Ron,
So here is the suggestion ...
Currently the encoded values of SABM are:
SABM (variable length): Standard Application Identifier Bit Mask
(SABM Length * 8) bits
This field is omitted if SABM Length is 0.
0 1 2 3 4 5 6 7 ...
+-+-+-+-+-+-+-+-+...
|R|S|F|X| ...
+-+-+-+-+-+-+-+-+...
R-bit: Set to specify RSVP-TE.
S-bit: Set to specify Segment Routing Policy.
F-bit: Set to specify Loop-Free Alternate (LFA) (includes all LFA
types).
X-bit: Set to specify Flexible Algorithm
How about you write a one page draft to specify bit #4
* A-bit: Set to specify all applications - current and future. *
I am not sure if this is really needed (as one could easily just set all
bits R, S F .... to 1, but maybe when we have 1000 applications and you
have a metric which should apply to all of them you just would be better to
set A-bit and be done ?
On another note as mentioned before I do agree with Shraddha about Flex
Algo just using one bit is not enough. If I run two or N topologies each
should have its own bit. At least SABM should define few for flex algo and
if more is needed we go to UDABM.
Best,
Robert
On Tue, Aug 17, 2021 at 9:58 PM Ron Bonica <[email protected]> wrote:
> Robert,
>
>
>
> The following information types need to be distributed :
>
>
>
> 1. Application Independent Link Attributes
> 1. Mentioned in Section 3.2 of RFC 8919
> 2. Not mentioned in Section 3.2 of RFC 8919
> 2. Application Configuration Information that is associated with an
> interface
> 3. Application Information that is not associated with an interface
>
>
>
> Section 6.1 of RFC 8919 addresses information of Type 1a). Under some
> conditions, it can be advertised as described in RFC 5305. In other
> conditions, it must be advertised as ASLA.
>
>
>
> Information of Type 1b) should by advertised as were the TE attributes
> defined in RFC 5305 (i.e., outside of the ASLA context).
>
>
>
> Information of Type 2 should be advertises as ASLA.
>
>
>
> Information of Type 3 should be considered on an application by
> application basis. For Flexalgo, it should be advertised in the FAD.
>
>
>
>
>
> Ron
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk <[email protected]>
> *Sent:* Tuesday, August 17, 2021 2:52 PM
> *To:* Ron Bonica <[email protected]>
> *Cc:* Acee Lindem (acee) <[email protected]>; [email protected]
> *Subject:* Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW
> Constraints
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Ron,
>
>
>
> Please kindly enlighten me on your line of thinking ...
>
>
>
> Let's consider your list:
>
>
>
> Total physical bandwidth
> Number of LAG elements
> Bandwidth of smallest lag member
> Latency
>
>
>
> Then as a method of distributing them you choose your option 3 which
> reads:
>
>
>
> "Configure this information in a few central places and advertise it to
> all other nodes. The advertisement is not associated with a link. Flexalgo
> uses the FAD in this manner."
>
>
>
> Question:
>
>
>
> How can you configure any of the metrics you enumerated "in a few central
> places" irrespective on how we encode it in IGP ? Isn't each of those
> properties local to each node which needs to be flooded via a domain from
> each node ?
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Aug 17, 2021 at 8:20 PM Ron Bonica <rbonica=
> [email protected]> wrote:
>
> Acee,
>
>
>
> So, let us discuss whether there is a good reason for
> draft-ietf-lsr-flex-algo-con to specify ASLA !
>
>
>
> Link attributes are different from application configuration information.
> Link attributes are properties of a link. They are independent of the
> applications that use them. The following are examples:
>
>
>
> - Total physical bandwidth
> - Number of LAG elements
> - Bandwidth of smallest lag member
> - Latency
>
>
>
> Link attributes do not benefit from ASLA encoding because they are not
> application specific.
>
>
>
> Application configuration information constrains the behavior of an
> application. It can apply to:
>
>
>
> - The application and a link
> - The application only
>
>
>
> Bandwidth reservation applies to an application and a link. For example, a
> link may advertise that it has:
>
>
>
> - X Gbps available for RSVP-TE reservations
> - Y Gbps available for SR Policy reservations
> - Z Gbps available for TI-LFA reservations
>
>
>
> This class of configuration information clearly benefits from ASLA
> encoding, because it is applicable to both the application and the link.
>
>
>
> Some applications (e.g., Flexalgo) can be configured to use a variety of
> link attributes in SPF calculation. No matter how they acquire this
> configuration information, it MUST be the same at each node. Otherwise,
> routing loops may result. Configuration options are:
>
>
>
> 1. Configure this information on each link and advertise link
> attributes with ASLA
> 2. Configure this information on each node that runs the application
> 3. Configure this information in a few central places and advertise it
> to all other nodes. The advertisement is not associated with a link.
> Flexalgo uses the FAD in this manner.
>
>
>
> Neither Option 1 nor Option 2 is very appealing, because it requires
> configuration on each node. Option 3 is better because:
>
>
>
> - It requires configuration on only a few nodes
> - It maintains separation between link attributes and application
> configuration information
> - It can support applications like Flexalgo, where each algorithm may
> use different link attributes to calculate the shortest path
>
>
>
>
> Ron
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Acee Lindem (acee) <[email protected]>
> *Sent:* Friday, August 13, 2021 10:22 AM
> *To:* Ron Bonica <[email protected]>; [email protected]
> *Subject:* Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW
> Constraints
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Speaking as a WG member:
>
>
>
> Hi Ron,
>
> My rationale is #1. The LSR WG developed ASLAs to cover usage of the link
> attributes (including metrics) for different applications and mitigate all
> the vagaries of the original TE link attribute specifications. ASLAs are
> implemented and deployed. I believe it would be a mistake to bifurcate the
> IGP standards with yet another way of encoding link attributes for
> different applications.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr <[email protected]> on behalf of Ron Bonica <
> [email protected]>
> *Date: *Thursday, August 12, 2021 at 3:46 PM
> *To: *"Acee Lindem (acee)" <[email protected]>, "
> [email protected]" <[email protected]>
> *Subject: *Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW
> Constraints
>
>
>
> Acee,
>
>
>
> Please help me to parse your message. It is clear that you want
> draft-ietf-lsr-flex-algo-bw-con to specify ASLA’s. However, your rationale
> is not so clear.
>
>
>
> It is not because RFC 8919 mandates ASLA. In fact, we agree that it would
> be strange for an RFC to include a mandate that precludes future proposals.
>
>
>
> Are any of the following your rationale:
>
>
>
> 1) Because there is a good technical reason for
> draft-ietf-lsr-flex-algo-bw-con to specify ASLA
>
> 2) Because it is possible, but not necessary, for
> draft-ietf-lsr-flex-algo-bw-con to specify ASLA
>
> 3) Because it was the unstated intention of RFC 8919 to include a
> mandate that precludes future proposals (although we agree that this would
> be strange).
>
>
>
> For the purposes of full disclosure, I think discussion regarding the
> first rationale would be fruitful. However, I don’t think very much of the
> second or third rationale.
>
>
>
>
>
> Ron
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Lsr <[email protected]> *On Behalf Of *Acee Lindem (acee)
> *Sent:* Tuesday, August 10, 2021 4:43 PM
> *To:* [email protected]
> *Subject:* [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW
> Constraints
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Speaking as a WG Member:
>
>
>
> In reviewing RFC 8919 and RFC 8920, it is clear that the ASLA mechanism
> was to be used for new link attributes and applications. While the
> documents do not mandate that there never could be a new way to advertise
> link attributes, this was clearly the intent. Indeed, it would be strange
> for an RFC to include a mandate that precluded future proposals. The
> advertisement enablement and deployment sections of these documents
> specifically cover future attributes and applications.
>
>
>
> Given that we have ASLAs as building blocks, I don’t really see a reason
> to introduce the generic metric. The proponents say it isn’t an alternative
> to ASLAs but their examples cite different applications using different
> metric types (i.e., application-specific metrics). Also, given that ASLA
> are used by the base Flex Algo draft, it would be inconsistent to diverge
> for Flex Algo BW constraints.
>
>
>
> Consequently, I would request that draft-ietf-lsr-flex-algo-bw-con-01
> revert to using ASLAs. Based on the LSR Email discussion prior to IETF 111,
> this was definitely the consensus.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!RHy0CI0W3XGSB666m-FN0spgH6Gm-YELP98p2oS9Zp_Rw3S8IQzewz_PyEvq3bOx$>
>
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
