Shraddha -
Please see inline.
> -----Original Message-----
> From: Shraddha Hegde <shraddha=40juniper....@dmarc.ietf.org>
> Sent: Friday, July 15, 2022 5:43 AM
> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Shraddha Hegde
> <shrad...@juniper.net>; lsr@ietf.org
> Subject: RE: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
>
> Les,
>
> Thanks for the reply. Pls see inline..
>
>
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Lsr <lsr-boun...@ietf.org> On Behalf Of Les Ginsberg (ginsberg)
> Sent: Thursday, July 14, 2022 2:32 AM
> To: Shraddha Hegde <shraddha=40juniper....@dmarc.ietf.org>; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-
> 01.txt
>
> [External Email. Be cautious of content]
>
>
> Shraddha -
>
> Thanx for your review and comments.
> Responses inline.
>
> > -----Original Message-----
> > From: Shraddha Hegde <shraddha=40juniper....@dmarc.ietf.org>
> > Sent: Tuesday, July 12, 2022 10:52 PM
> > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; lsr@ietf.org
> > Subject: RE: New Version Notification for
> > draft-ginsberg-lsr-rfc8919bis-01.txt
> >
> > 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.
>
> [LES:] Both documents have the same explicit definition in the Introduction:
>
> "For the purposes of this document, an application is a technology that
> makes use of link attribute advertisements, examples of which are listed
> in..."
>
> The term "application" may have other meanings in other contexts, but
> those meanings are not relevant here.
> We have clearly defined what "application" means when used in this
> document.
> <SH>The definition here is not sufficiently described and very vague.
> You didn't respond to my comment below that there is no clarity whether
> SRv6 would ever qualify for a separate application.
[LES:] Not sure what your point is here.
Neither SR-MPLS nor SRv6 is defined as an application by this document.
But perhaps my answer below will address your concern.
>
> > 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.
> >
> [LES:] I disagree.
> Such text would require clairvoyance. I do not pretend to know what new
> technologies may be defined in the future which could benefit from ASLA
> support.
>
> Note that for a new application to be included in the set of ASLA supported
> standard applications, a draft must be written defining the new application
> and this has to achieve WG consensus.
> So there is a thorough vetting procedure in place already.
>
> <SH> This document defined the application bit SR-TE. It didn't clarify
> whether SR-TE means mpls dataplane as well as SRv6 dataplane. At a
> minimum it needs to be clarified in the document.
[LES:] SR-TE application is dataplane independent . We will add the following
statement in Section 4.1 of RFC 8919 (and Section 5 for RFC 8920):
OLD:
S-bit:
Set to specify Segment Routing Policy.
NEW
S-bit:
Set to specify Segment Routing Policy.
NOTE: This is dataplane independent.
>
> >
> > 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.
> >
> [LES:] Section 6 of RFC8919bis - and more specifically Section 6.3.3 -
> addresses
> this point in detail.
> I do not see that new text is needed.
>
> Comparable text can be found in RFC8920bis Section 12.3.3
>
> <SH>
> "So long as there is any
> legacy router in the network that has any of the applications
> enabled, all routers MUST continue to advertise link attributes using
> legacy advertisements."
>
> Sec 6.3.3 in 8919bis has above statement.
> It just says MUST advertise with legacy but this does not mean it prohibits a
> router
> >From advertising ASLA along with legacy with application bit set. As long as
> the values in ASLA
> Match with legacy advertisements its ok but when they don't match it's
> problematic.
> I clearly see this as a hole that can cause inter-op issues.
[LES:] When Legacy routers are present, advertising different values for link
attributes in ASLA advertisements is an implementation bug. That is clear from
the previous statement in the same paragraph:
"... routers that do not support the extensions defined in this document will
send and receive only legacy link attribute advertisements."
Implementations which deviate from this haven't done adequate testing of their
product before shipping it.
Les
> Les
>
>
> Les
>
> >
> > 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_7OWQ6XlbSNK2EwgaJqAIeyd
> > 1bbeYOilNpT-2QlLXl7KIf7D24NLUlB5e_NMk$
> > Status:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
> > ginsberg-lsr-rfc8919bis/__;!!NEt6yMaO-
> >
> gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd
> > 1bbeYOilNpT-2QlLXl7KIf7D24NLUlMHc2Gn4$
> > Html:
> > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-
> > ginsberg-lsr-rfc8919bis-01.html__;!!NEt6yMaO-
> >
> gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd
> > 1bbeYOilNpT-2QlLXl7KIf7D24NLUlABYFZnP$
> > Htmlized:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> > t-
> > ginsberg-lsr-rfc8919bis__;!!NEt6yMaO-
> >
> gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd
> > 1bbeYOilNpT-2QlLXl7KIf7D24NLUlJxHVgye$
> > Diff:
> > https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-
> > ginsberg-lsr-rfc8919bis-01__;!!NEt6yMaO-
> >
> gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd
> > 1bbeYOilNpT-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_7OWQ6XlbSNK2EwgaJqAIeyd
> > 1bbeYOilNpT-2QlLXl7KIf7D24NLUlGfn5wMH$
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!
> !NEt6yMaO-
> gk!HXAmPIF8bAD6M_W8QIviUQrqPaIvPfT_Q7IDNtOCUAp2VLdGA7saG-
> ysEvIFh5T-szQMzGzO8hSrWFfDWDUTJGowUwA2p1IQ$
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
