Subject: [Lsr] Martin Duke's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Mon, 08 Jun 2020 17:33:40 -0700

Martin Duke has entered the following ballot position for
draft-ietf-isis-te-app-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I know very little about this, but just checking:
- I trust that a network that mixes routers that use application attributes,
and not, will not lead to long-term routing loops in spite of them not having a
common picture of the network?

- It is odd that a link that advertises a zero-length flags field means support
for RSVP-TE is “ambiguous” (sec 5). What are the implications of this? When is
it OK to use a zero-length flags field given this ambiguity? In a standard, can
we not decide on a meaning to eliminate the uncertainty? I would appreciate
some language here to answer at least the first two questions.

- as the TSVart review points out, the length field wastes 3 bits of 7 because
the maximum length is 8. You could reserve them or even use them to encode
these three legacy applications.

Nits:

Abstract:
In “these link attributes for a given attribute” add a comma after both
instances of attribute(s)

Sec 4 2)Application. Add a space

Sec 5. Missing a period at the end of “existence of link attribute
advertisements”

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 9 Jun 2020 04:57:53 +0000

Martin -

Thanx for your review.
A new version will be published soon - pending resolution of comments from another review - that addresses issues you have raised - subject to my responses inline.

> -----Original Message-----
> From: Lsr <[email-masked]> On Behalf Of Martin Duke via Datatracker
> Sent: Monday, June 08, 2020 5:34 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; Acee Lindem (acee)
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: [Lsr] Martin Duke's No Objection on draft-ietf-isis-te-app-14: (with
> COMMENT)
> 
[Les:] Traffic engineering policies are calculated by the headend/ingress node. Based on the calculation a set of forwarding instructions are imposed on a packet (e.g., MPLS labels) which direct forwarding of the packet towards the destination. Intermediate nodes are unaware of the policy - they simply forward the packet based on the forwarding instruction.  So the fact that intermediate nodes may not themselves process link attribute advertisements does not introduce loops.

> some language here to answer at least the first two questions.
[Les:] The use of zero length application bit mask is discussed in Section 4.2 and Section 6.2. This can be convenient in that one set of link attribute advertisements can be used for all applications and as applications are enabled/disabled the advertisement of link attributes does not have to be modified in any way. But it can also lead to unintended use of link attribute advertisements by an application. This latter point is discussed in Section 6.2.

Section 5 is discussing whether the presence of link attribute advertisements serve to indicate enablement of a given application on the associated link for the three applications defined in this draft (RSVP-TE: yes, SRTE and LFA: no).
The text in Section 5 that you ask about indicates that in the special case where zero length Application Bit Mask is associated with link attribute advertisements, for an application (RSVP-TE) which utilizes link attributes to indicate application enablement, the lack of an explicit application bit introduces ambiguity as to whether the application should be considered enabled on the link or not. This is why we include the cautionary statement:

" This needs to be considered when making use of the "any application"
   encoding."

So I believe the draft does address your concerns.

> these three legacy applications.
[Les:] As indicated in my previous response to this comment, the limitation to 8 bytes maximum was put in late based upon a review comment. There are already implementations of the draft deployed. Changing the format of the fields would result in backwards compatibility issues with these early implementations. The very minor savings in encoding (1 byte maximum) is not significant enough to warrant introducing backwards compatibility issues.

I do appreciate that you (and Kyle) have frugality in mind.

> instances of attribute(s)

[Les:] Done.

> Sec 4 2)Application. Add a space

[Les:] Apologies - but I cannot find an instance in which a space is needed and not already present. Perhaps you could provide more context so I could locate the specific sentence involved. I did search for all occurrences of "Application".

> Sec 5. Missing a period at the end of “existence of link attribute

[Les:] Done.

   Les

> 
> 
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Martin Duke <[email-masked]>
Date: Tue, 9 Jun 2020 09:01:45 -0700

Lee,

Responses inline.

On Mon, Jun 8, 2020 at 9:57 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> [Les:] Traffic engineering policies are calculated by the headend/ingress
> node. Based on the calculation a set of forwarding instructions are imposed
> on a packet (e.g., MPLS labels) which direct forwarding of the packet
> towards the destination. Intermediate nodes are unaware of the policy -
> they simply forward the packet based on the forwarding instruction.  So the
> fact that intermediate nodes may not themselves process link attribute
> advertisements does not introduce loops.
>

I see, thanks, that makes sense.

> > for RSVP-TE is “ambiguous” (sec 5). What are the implications of this?
> When
> > is
> [Les:] The use of zero length application bit mask is discussed in Section
> 4.2 and Section 6.2. This can be convenient in that one set of link
> attribute advertisements can be used for all applications and as
> applications are enabled/disabled the advertisement of link attributes does
> not have to be modified in any way. But it can also lead to unintended use
> of link attribute advertisements by an application. This latter point is
> discussed in Section 6.2.
>
> Section 5 is discussing whether the presence of link attribute
> advertisements serve to indicate enablement of a given application on the
> associated link for the three applications defined in this draft (RSVP-TE:
> yes, SRTE and LFA: no).
> The text in Section 5 that you ask about indicates that in the special
> case where zero length Application Bit Mask is associated with link
> attribute advertisements, for an application (RSVP-TE) which utilizes link
> attributes to indicate application enablement, the lack of an explicit
> application bit introduces ambiguity as to whether the application should
> be considered enabled on the link or not. This is why we include the
> cautionary statement:
>

Thank you for clarifying. Your explanation conforms with my understanding
from reading the document. Maybe this obvious to people in the field, but
under what circumstances would I decline to use "any application" encoding?
I think the draft indicates the first level implications (we don't have
confirmed enablement) but under what circumstances is that OK? If there is
out of band information that it's globally enabled? Or can RSVP-TE function
if it turns out some aren't enabled?

> [Les:] As indicated in my previous response to this comment, the
> limitation to 8 bytes maximum was put in late based upon a review comment.
> There are already implementations of the draft deployed. Changing the
> format of the fields would result in backwards compatibility issues with
> these early implementations. The very minor savings in encoding (1 byte maxi
> mum) is not significant enough to warrant introducing backwards
> compatibility issues.

Yeah, transport guys are famous for fighting for years over a bit :-)

> [Les:] Apologies - but I cannot find an instance in which a space is
> needed and not already present. Perhaps you could provide more context so I
> could locate the specific sentence involved. I did search for all
> occurrences of "Application".
>

It's the fifth line down here:
https://datatracker.ietf.org/doc/html/draft-ietf-isis-te-app-14#section-4

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 9 Jun 2020 19:25:22 +0000

Martin -

> From: Martin Duke <[email-masked]>
> Sent: Tuesday, June 09, 2020 9:02 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; [email-masked];
> Acee Lindem (acee) <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Re: [Lsr] Martin Duke's No Objection on draft-ietf-isis-te-app-14:
> (with COMMENT)
> 
> Lee,
> 
> Responses inline.
> 
[Les:] The use of "any application" is only possible if the same link attribute values can be used by all applications which are in use in that deployment. This is a decision that can only be made based on the deployment.
The discussion of "enablement" is pointing out a possible side effect even if the first set of conditions are met.

To my mind, the use of "any application" is likely NOT the default mode of operation even when the preconditions are met - but this is an implementation choice not subject to standardization.

    Les

> > limitation to 8 bytes maximum was put in late based upon a review
> comment

---

From: Martin Duke <[email-masked]>
Date: Tue, 9 Jun 2020 14:35:22 -0700

On Tue, Jun 9, 2020 at 12:25 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

>
> [Les:] The use of "any application" is only possible if the same link
> attribute values can be used by all applications which are in use in that
> deployment. This is a decision that can only be made based on the
> deployment.
> To my mind, the use of "any application" is likely NOT the default mode of
> operation even when the preconditions are met - but this is an
> implementation choice not subject to standardization.
>

I suspect we are talking past each other, probably due to my ignorance of
this area, and possibly beyond what a non-blocking comment is worth.

Anyway, I can live with not having normative language here, but I would
like to have a little more discussion of the considerations for this
decision -- at least what the consequences are if nodes don't know if the
links support RSVP-TE or not.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 9 Jun 2020 23:40:28 +0000

Martin -

From: Martin Duke <[email-masked]>
Sent: Tuesday, June 09, 2020 2:35 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] Martin Duke's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)

On Tue, Jun 9, 2020 at 12:25 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

I suspect we are talking past each other, probably due to my ignorance of this area, and possibly beyond what a non-blocking comment is worth.

Anyway, I can live with not having normative language here, but I would like to have a little more discussion of the considerations for this decision -- at least what the consequences are if nodes don't know if the links support RSVP-TE or not.

[Les:] When the application bit mask is populated (non-zero length), the set of applications to which the associated link attributes apply is explicit.
When the application bit mask is NOT populated (zero-length), the set of applications to which the associated link attributes apply is implicit. Specifically, any application that is enabled on a node (by application specific configuration which likely is NOT link specific) is allowed to use the attributes. For an application (such as RSVP-TE) where “use” includes the enablement of the application on that link there is a possibility that this is not what was intended. Simply by configuring/advertising a link attribute can then result in unintended use of that link by such an application.
Applications which do NOT depend on link attribute advertisements for enablement do not face this issue. They will use the link (or not) based on other criteria which remain application specific.

This is what we try to capture (more succinctly) in the sentence:

“In the presence of
   an application where the advertisement of link attribute
   advertisements is used to infer the enablement of an application on
   that link (e.g., RSVP-TE), the absence of the application identifier
   leaves ambiguous whether that application is enabled on such a link.”

I don’t know if this helps, but I am trying… 😊

   Les