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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
