Authors,
Thanks for the bis version of RFC 8919 and the clarifying text on errata.
The issues raised with respect to the errata have been addressed well in the
bis version.
However, I believe that the bis version is also an opportunity for us to
address any other ambiguities and clarifications and not just restrict it to
the raised errata. RFC 8919 is going to serve as base document for many
future applications /attributes and a clear definition and documentation
is necessary for interoperable implementations as well as for future
evolution of the protocol.
I have below comments on the document
1. The definition of what constitutes an application in the scope of this
document is not
clearly defined in the document. Currently RSVP,SR-TE, LFA, Flex-algo have
been defined
so it appears that any application that uses TE attributes can be
defined as a separate application.
The TE mechanisms like RSVP, SR-TE and flex-algo have been defined as
separate applications
and it appears features having significantly different
forwarding plane is defined as new application. It is not clear if SRv6
would be
qualified as a new application.
LFA for different forwarding planes such as IP, MPLS, SRv6 are not
separate applications
but LFA is defined as a single application.
I have also seen many drafts confusing application specific to be user
application.
I suggest to add a section and describe what is an application clearly
in the draft that should provide
sufficient input on what can be defined as an application from ASLA
context in future.
2. " When SABM or UDABM Length is non-zero and the L-flag is NOT set, all
applications specified in the bit mask MUST use the link attribute
advertisements in the sub-TLV."
Applications such as RSVP, SR-TE, LFA already use legacy advertisements.
This document suggests that if any attribute is advertised with an
application bit set in ASLA
ASLA advertisements MUST be used by that application.
Implementations may support ASLA for only some applications.
I suggest to add below text.
Until all nodes upgraded to support ASLA for a particular application,
different values of link attributes
MUST NOT be advertised for that application in legacy advertisement and ASLA
advertisements.
Rgds
Shraddha
Juniper Business Use Only
-----Original Message-----
From: Lsr <lsr-boun...@ietf.org> On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, June 21, 2022 8:59 AM
To: lsr@ietf.org
Subject: [Lsr] FW: New Version Notification for
draft-ginsberg-lsr-rfc8919bis-01.txt
[External Email. Be cautious of content]
Folks -
Please note V01 of the RFC8919bis draft has been posted.
This version incorporates comments received from Bruno.
Les
-----Original Message-----
From: internet-dra...@ietf.org <internet-dra...@ietf.org>
Sent: Monday, June 20, 2022 8:22 PM
To: John Drake <jdr...@juniper.net>; Les Ginsberg (ginsberg)
<ginsb...@cisco.com>; Peter Psenak (ppsenak) <ppse...@cisco.com>; Stefano
Previdi <stef...@previdi.net>; Wim Henderickx <wim.henderi...@nokia.com>
Subject: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
A new version of I-D, draft-ginsberg-lsr-rfc8919bis-01.txt
has been successfully submitted by Les Ginsberg and posted to the IETF
repository.
Name: draft-ginsberg-lsr-rfc8919bis
Revision: 01
Title: IS-IS Application-Specific Link Attributes
Document date: 2022-06-20
Group: Individual Submission
Pages: 25
URL:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.txt__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlB5e_NMk$
Status:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlMHc2Gn4$
Html:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.html__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlABYFZnP$
Htmlized:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ginsberg-lsr-rfc8919bis__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlJxHVgye$
Diff:
https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ginsberg-lsr-rfc8919bis-01__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlEG5hZVF$
Abstract:
Existing traffic-engineering-related link attribute advertisements
have been defined and are used in RSVP-TE deployments. Since the
original RSVP-TE use case was defined, additional applications (e.g.,
Segment Routing Policy and Loop-Free Alternates) that also make use
of the link attribute advertisements have been defined. In cases
where multiple applications wish to make use of these link
attributes, the current advertisements do not support application-
specific values for a given attribute, nor do they support indication
of which applications are using the advertised value for a given
link. This document introduces new link attribute advertisements
that address both of these shortcomings.
This document obsoletes RFC 8919.
The IETF Secretariat
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlGfn5wMH$
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
