Internet DRAFT - draft-hegde-lsr-asla-any-app
draft-hegde-lsr-asla-any-app
LSR S. Hegde
Internet-Draft R. Bonica
Intended status: Standards Track C. Bowers
Expires: January 12, 2023 Juniper Networks
R. Raszuk
NTT Network Innovations
Z. Li
Huawei Technologies
D. Voyer
Bell Canada
July 11, 2022
The Application Specific Link Attribute (ASLA) Any Application Bit
draft-hegde-lsr-asla-any-app-02
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2023.
Hegde, et al. Expires January 12, 2023 [Page 1]
Internet-Draft ASLA Any Application Bit July 2022
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. The Any Application Bit . . . . . . . . . . . . . . . . . . . 4
3.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
[RFC8919] and [RFC8920] 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).
Each bit in the SABM represents a standard application while each bit
in the UDABM represents a user defined application. If a bit in the
SABM or UDABM is set, the corresponding application can use the ASLA
as an input. If a bit in the SABM or UDABM is not set, the
corresponding application cannot use the associated ASLA as an input.
According to [RFC8919]:
"If link attributes are advertised associated with zero-length
Application Identifier Bit Masks for both standard applications and
user-defined applications, then any standard application and/or any
user-defined application is permitted to use that set of link
Hegde, et al. Expires January 12, 2023 [Page 2]
Internet-Draft ASLA Any Application Bit July 2022
attributes so long as there is not another set of attributes
advertised on that same link that is associated with a non-zero-
length Application Identifier Bit Mask with a matching Application
Identifier Bit set."
This restriction introduces complexity. For example, assume that a
network runs many applications. All applications use Attribute 1 as
an input. So, it would be convenient to advertise Attribute 1 with a
zero-length SABM / UDABM.
However, Applications X and Y also use Attribute 2 as an input.
Because Applications X and Y required unique values for Attribute 2,
Attribute 2 cannot be advertised with a zero-length SABM. Therefore,
Attribute 1 cannot be advertised with a zero-length SABM / UDABM
either, because Applications X and Y require it. This would result
in having to set the application X and application Y bits on
attribute 1 in the entire network on each link and is operationally
complex.
Zero length bitmasks also introduce LSP packing inefficiency. From
the example above, The attribute 1 has to be repeated for
applications X and Y although application X and Y do not require
different values for these applications. When the attributes get
advertised from IGP into BGP-LS, attributes from zero length bitmasks
of ASLA and ASLA SRLG need to be collated to make it disambiguous.
This collation introduces additional complexity.
When a deployment requires link-attributes to be used by all
applications instead of using the zero-length bitmasks one could use
an ASLA advertisements with all known application bits set. While
this may work well for the current deployments for the current set of
defined applications, it poses challenge when there are new
applications to be deployed. It would require all nodes in the
network to support the new bit and require upgrade.
This document reduces operational complexity by introducing 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.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
Hegde, et al. Expires January 12, 2023 [Page 3]
Internet-Draft ASLA Any Application Bit July 2022
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. The Any Application Bit
A new bit is defined in 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.
If a link advertises an ASLA twice, once with the A-bit set and once
with a more specific Application Identifier Bit set, the indicated
application MUST use the value from the ASLA with the more specific
Application Indicator Bit set.
3.1. IS-IS
IS-IS uses Bit 4 of the SABM to encode the A-bit.
3.2. OSPF
OSPF uses Bit 4 of the SABM to encode the A-bit.
4. Backward Compatibility
The solution described in this document is backward compatible with
[RFC8919] and [RFC8920]. An implementation that does not recognize
the A-bit will process the SABM as specified in [RFC8919] and
[RFC8920].
Implementations MAY advertise attributes under both A bit and with
SABM and UDABM length set to zero for backward compatibility reasons.
When same attributes are received with A bit set as well as in ASLA
with SABM and UDABM set to zero, the attributes MUST be used from the
ASLA with SABM and UDABM set to zero and procedures described in RFC
8919 sec 6.2 MUST be followed.
5. Security Considerations
The security considerations discussed in [RFC8919] and [RFC8920] are
applicable to this document. This document does not introduce any
new security risks.
Hegde, et al. Expires January 12, 2023 [Page 4]
Internet-Draft ASLA Any Application Bit July 2022
6. IANA Considerations
This document requests that IANA add the following entry to the
registry titled "Link Attribute Application Identifiers" under the
"Interior Gateway Protocol (IGP) Parameters" registry:
o Bit: 4
o Name: Any Application (A-bit)
o Reference: This document
7. Acknowledgements
TBD
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
J. Drake, "IS-IS Application-Specific Link Attributes",
RFC 8919, DOI 10.17487/RFC8919, October 2020,
<https://www.rfc-editor.org/info/rfc8919>.
[RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura,
J., and J. Drake, "OSPF Application-Specific Link
Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020,
<https://www.rfc-editor.org/info/rfc8920>.
Authors' Addresses
Shraddha Hegde
Juniper Networks
Exora Business Park
Bangalore, KA 560103
India
Email: shraddha@juniper.net
Hegde, et al. Expires January 12, 2023 [Page 5]
Internet-Draft ASLA Any Application Bit July 2022
Ron Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, Virginia 20171
USA
Email: rbonica@juniper.net
Chris Bowers
Juniper Networks
Email: cbowers@juniper.net
Robert Raszuk
NTT Network Innovations
Email: robert@raszuk.net
Zenbin Li
Huawei Technologies
Email: lizhenbin@huawei.com
Dan Voyer
Bell Canada
Email: daniel.voyer@bell.ca
Hegde, et al. Expires January 12, 2023 [Page 6]
