Martin -
> -----Original Message-----
> From: Martin Duke <[email protected]>
> Sent: Tuesday, June 09, 2020 9:02 AM
> To: Les Ginsberg (ginsberg) <[email protected]>
> Cc: The IESG <[email protected]>; [email protected]; [email protected];
> Acee Lindem (acee) <[email protected]>; [email protected];
> [email protected]
> Subject: Re: [Lsr] Martin Duke's No Objection on draft-ietf-isis-te-app-14:
> (with COMMENT)
>
> Lee,
>
> Responses inline.
>
> On Mon, Jun 8, 2020 at 9:57 PM Les Ginsberg (ginsberg)
> <[email protected]>
> wrote:
>
> >
> > > ----------------------------------------------------------------------
> > > 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.
> >
>
> I see, thanks, that makes sense.
>
>
> >
> > > - 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.
> >
>
> 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:] 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
> >
> > > - 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
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
