Re: WG Adoption poll for draft-ginsberg-isis-te-app

After some prodding by multiple people I went and looked somewhat closer @
the 2 docs to form a more qualified opinion ;-)


Meta-observation: I see two different albeit partially overlapping problems
that the documents are solving. Let me distill it to a list of requirements
without judging first


1. SRTE/LFA may need a different set of extended metrics (that’s what I
call RFC5305) than RSVP-TE. More generic, new applications may come in the
future and need TLV22/222 metric values per application OR may share the
same value.

2. The application topologies may be incongruent

3. Backwards compatibility is necessary, i.e. extensions (if any) should be
able to “roll forward” without a “flag day”

4. An advertisement should indicate whether an application _provides_ any
of the extended metrics

4a. An advertisement should indicate whether an application _uses_ any of
the extended metrics

4b. An advertisement indicates whether an application _is enabled/active_
on the link

5. Unify the RFC6119,RFC5307 link identification


Now, observations to specific drafts, draft-ginsberg-isis-te-app-03 first


a) I was blatantly wrong (did I read an early version or just flew too
fast, who knows in the daily struggle of surviving’ the onslaught of
documents ;-) and this draft does NOT define an orthogonal encoding but
tries to subtly dis-entangle from one set of extended metrics into per
application metrics. As usual, Les kept me firm but straight ;-)

b) 4b is a NON-requirement.

c) 4a seems to be a requirement but it doesn’t seem to be met (unless the
set of sub-TLVs in application specific sub-TLV indicates that only THOSE
are used by the application [unless the L-flag is set which seems to imply
that the generic ones are ‘inherited’ but ‘overwritten’. I think some
examples would be helpful here to show what the combinations of sub-TLV and
L-bit on/off really mean for the application on a router understanding it
and one that doesn’t have the extensions.])

d) draft seems to satisfy 1/2/4 and 3 and 5 only partially  (2 by using MT
if the topology has to be restricted)

e) to support 3 fully a node capability would be necessary indicating
whether a router understands the new sub-TLV for 22/23/141/222/223 or maybe
I missed something how redundant info can satisfy 3 (then again, when do
you know that ALL routers support it and can stop advertising redundant
info?).

f) the problem how a router would be dealing with application specific SLRG
while TLV138 and TLV139 are present @ the same time does not seem to be
addressed (or maybe the L-bit allows backwards compatibility here but I
didn’t think through all the combinations and examples would be helpful
again).


Looking @ draft-hegde-isis-advertising-te-protocols-02 on the other hand I
see


a) 4b is a requirement

b) 1,2,4,5 are not addressed

c) 4a is addressed by
https://www.ietf.org/mail-archive/web/isis-wg/current/msg05081.html (but to
be fair not part of the original draft itself)


Ultimately, I would venture to observe that


a) the whole 1/2/3/4/5 problem seems to me easily addresses by using a MT
per application if one is willing to accept this relationsship. It allows
fully orthogonal application deployment (show different values in 222,223)
and fully coupled (show same values in 222,223). The complexity of such a
solution seems significantly lower than adding all those additional, fairly
convoluted encoding machinery in both cases.


b) 4a can be addressed by other means like administrative group (with some
limitations due to the 4 octet size) or in case of MT the presence of an MT
may indicate that the protocol is enabled.
draft-hegde-isis-advertising-te-protocols-02
is indicating this.


*So, my take after having spent the time dissecting it? Well, those draft
address different requirements and we would have to argue what is the set
we want to address and whether we want to address them in a single draft. *


I do think that 4b should be addressed.


If I'm not mistaken interaction of e.g. BW indications and how they
interplay is something worth talking about. Running RSVP-TE and SR on same
link both with some bandwidth guarantees without exceeding the link seems
not addressed to me at all.   Arguably it’s not part of the syntactic
encoding but syntax without semantics is misleading at worst and
meaningless at best …


*With all that, I do retract my objection to WG adoption and take no
position except encouraging the authors to follow several suggestions
extended in this email. *

On Wed, Jun 28, 2017 at 7:31 AM, Christian Hopps <[email protected]> wrote:

>
> Hi Folks,
>
> The authors have requested the IS-IS WG adopt
>
>     https://datatracker.ietf.org/doc/draft-ginsberg-isis-te-app/
>
> as a working group document. Please indicate your support or no-support
> for taking on this work.
>
> Authors: Please indicate your knowledge of any IPR related to this work
> to the list as well.
>
> Thanks,
> Chris & Hannes.
>
> _______________________________________________
> Isis-wg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/isis-wg
>
>


-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky

_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg