Subject: [Isis-wg] WG Adoption poll for draft-ginsberg-isis-te-app

From: Christian Hopps <[email-masked]>
Date: Wed, 28 Jun 2017 10:31:18 -0400

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.

---

From: Stefano Previdi <[email-masked]>
Date: Wed, 28 Jun 2017 16:38:46 +0200

Support.

I'm not aware of any IPR.

s.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 28 Jun 2017 16:47:12 +0200

Hi Chris,

I support the adoption.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 28 Jun 2017 14:47:16 +0000

Support. I hope this is the first step towards consensus in supporting
attributes across both IGPs.
Thanks,
Acee

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 28 Jun 2017 14:55:23 +0000

Support as co-author.

I am not aware of any relevant IPR.

    Les

> -----Original Message-----
> From: Christian Hopps [mailto:[email-masked]]
> Sent: Wednesday, June 28, 2017 7:31 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: WG Adoption poll for draft-ginsberg-isis-te-app
> 
> 
> Hi Folks,
> 
> 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.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 28 Jun 2017 15:08:07 +0000

Support the adoption of this draft as WG doc

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: 28 June 2017 20:01
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Isis-wg] WG Adoption poll for draft-ginsberg-isis-te-app

Hi Folks,

Thanks,
Chris & Hannes.

---

From: Chris Bowers <[email-masked]>
Date: Wed, 28 Jun 2017 17:20:35 +0000

ISIS WG,

I oppose adoption of this draft as a working group item.

After the discussion in Chicago, I proposed alternative encodings that use the 
concept of an attribute set that I was hopeful would be incorporated in a merged 
draft on this topic.

These are described in the following email.
 https://www.ietf.org/mail-archive/web/isis-wg/current/msg05081.html

I believe that these alternative encodings have two main advantages over those
proposed in draft-ginsberg-isis-te-app.

First, they are much less disruptive to existing deployments using the existing 
TE attributes, and they provide a less disruptive migration path.

Second, they are more flexible and useful, because they do not attempt to
define specific applications.  

I am happy to publish the alternative encodings as a stand-alone draft.  I did 
not do so initially in the interest of promoting compromise after the discussion in 
Chicago.  However, the basic encodings in draft-ginsberg-isis-te-app have not changed 
significantly.  They do not capture the advantages of the alternative encodings described above.

Given the current lack of compromise reflected in draft-ginsberg-isis-te-app, I think
that the text is not a good basis for working group work on this topic.

Thanks,
Chris

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Wednesday, June 28, 2017 4:31 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Isis-wg] WG Adoption poll for draft-ginsberg-isis-te-app

Hi Folks,

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.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 28 Jun 2017 20:46:42 +0200

Hi Chris, WG,

> define specific applications.

That is precisely the reason which actually makes draft-ginsberg-isis-te-app
superior then your alternatives discussed at last IETF in Chicago.

I highly support adoption of draft-ginsberg-isis-te-app as a WG document.

Kind regards,
Robert Raszuk.

On Wed, Jun 28, 2017 at 7:20 PM, Chris Bowers <[email-masked]> wrote:

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

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 28 Jun 2017 18:58:33 +0000

Support.

- Naiming

> On Jun 28, 2017, at 10:20 AM, Chris Bowers <[email-masked]> wrote:
> 
> ISIS WG,
>

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 28 Jun 2017 12:00:06 -0700

I read quickly through the drafts and I oppose the adoption of draft
https://datatracker.ietf.org/doc/draft-ginsberg-isis-te-app/
<https://datatracker.ietf.org/doc/draft-ginsberg-isis-te-app/> as is. It
introduces a non-orthogonal,  redundant encoding solution [to RFC5305] per
application which is always fun until all the redundancy conflicts in such
encodings occur as they must. The problem as far I see is:

a) we need a _link-property_ which kind of signalling is present and NOT
bunch of confusingly non-orthogonal repeating metric encoding with
hard-coded application values. IMO the problem is better addressed by
https://tools.ietf.org/html/draft-hegde-isis-advertising-te-protocols-02
 currently.
b) the remaining problem of possibly diverging, same metrics _per_
signalling is probably better addressed by a e.g. allowing existing
multiple RFC5305 occurences which are signalling protocol specific (unless
I missed something reading draft hedge)

The two drafts (hedge & ginsberg) should be joined without introducing a
new TLV or hardcoding of existing/future signalling per bit in masks and
brought forward to adoption ...

thanks

--- tony

-- 
*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

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 28 Jun 2017 19:18:26 +0000

Support as co-author
Not aware of IPR related to this draft

On 28/06/2017, 15:31, "Christian Hopps" <[email-masked]> wrote:

    Hi Folks,

    

    Thanks,
    Chris & Hannes.

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 28 Jun 2017 17:39:46 -0700

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 29 Jun 2017 05:07:55 +0000

Tony –

Thanx for the reconsideration.

Some responses inline.

From: Tony Przygienda [mailto:[email-masked]]
Sent: Wednesday, June 28, 2017 5:40 PM
To: Christian Hopps
Cc: [email-masked] list; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] 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.

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

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 ;-)

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.])

[Les:] The draft is defining what applications may make use of a given set of link attribute advertisements. Whether they actually do so is not required to be known.

This is no different than how link attribute advertisements for RSVP-TE are used today. A router advertises whatever has been locally configured, but whether any node in the network actually uses this information to construct an engineered path is unknown.

But, I agree more examples would help the clarity.

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)

[Les:] There is no use of MT – nor do we want to suggest it. Use of a different set of links by different applications is supported by indicating that on a given link “application X” is/is not specified in the bit mask as a possible user of that set of advertisements.

Point 5 isn’t a goal of the draft. We did define a single new SRLG related TLV which does support V4, V6, and unnumbered identifiers rather than follow the RFC 6119/5307 model which required two TLVs so as to minimize the extra code points required.

IS Neighbor advertisements already support all types of link endpoint identifiers.

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?).

[Les:] Backwards compatibility is fully supported – though in cases where the same set of attributes cannot be used by all applications this may require some duplicate advertisements.

What is NOT defined is how to automatically determine when all nodes support the new code points so that the legacy advertisements can be fully deprecated automatically.

I am not sure this is a requirement – an operator can enable this by configuration – but it is something we can consider adding.

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

[Les:] Yes – L-flag works the same way for SRLG advertisements as it does for the IS Neighbor related link attribute advertisements.

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

a) 4b is a requirement

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)

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.

[Les:] This is a completely different solution from what is proposed in either draft – and one which comes with considerable deployment costs. I don’t think this is a solution which would please anyone.

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.

[Les:] I don’t see why 4a is needed. We certainly haven’t needed it for RSVP-TE for the past 15 years. ??

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.

[Les:] This is definitely a non-goal of draft-ginsberg – and we have explained why in earlier posts.

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 …

[Les:] This is a fair point – but seems to fall out of scope for this draft which – as you say – is defining the encoding.

However, it is probably useful to discuss this as a deployment consideration – even if a solution is out of scope for this draft.

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.

[Les:] Thanx again.

    Les

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

Hi Folks,

Thanks,
Chris & Hannes.

_______________________________________________
Isis-wg mailing list
[email-masked]<mailto:[email-masked]>
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

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 29 Jun 2017 06:33:46 +0000

Support.

    -----Original Message-----
    From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
    Sent: Wednesday, June 28, 2017 10:31 AM
    To: [email-masked]
    Cc: [email-masked]; [email-masked]
    Subject: [Isis-wg] WG Adoption poll for draft-ginsberg-isis-te-app

    Hi Folks,

    

    Thanks,
    Chris & Hannes.

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Thu, 29 Jun 2017 06:39:10 +0000

Support

Andrew

Sent from my iPhone

> On Jun 28, 2017, at 10:31 PM, Christian Hopps <[email-masked]> wrote:
> 
> 
> Hi Folks,
>

---

From: "Osborne, Eric" <[email-masked]>
Date: Thu, 29 Jun 2017 11:20:23 +0000

Support.

eric

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Wednesday, June 28, 2017 10:31 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Isis-wg] WG Adoption poll for draft-ginsberg-isis-te-app

Hi Folks,

Thanks,
Chris & Hannes.

---

From: Luay Jalil <[email-masked]>
Date: Thu, 29 Jun 2017 15:57:28 -0500

Support

Regards,
Luay Jalil