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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Martin Duke via Datatracker
> Sent: Monday, June 08, 2020 5:34 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; Acee Lindem (acee)
> <[e-mail]>; [e-mail]; [e-mail]
> Subject: [Lsr] Martin Duke's No Objection on draft-ietf-isis-te-app-14: (with
> COMMENT)
> 
> 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?
> 
[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.

> - 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.
> 
[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.

> - 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.
> 
[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.

> Nits:
> 
> Abstract:
> In “these link attributes for a given attribute” add a comma after both
> 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
> advertisements”

[Les:] Done.

   Les

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