Subject: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

From: Deborah Brungard via Datatracker <[email-masked]>
Date: Wed, 10 Jun 2020 15:16:30 -0700

Deborah Brungard has entered the following ballot position for
draft-ietf-isis-te-app-14: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be simple to resolve - the use of the SR-TE term is
out-of-alignment with other drafts, spring and idr. Suggest: Segment Routing
Traffic Engineering/s/Segment Routing Policy and SRTE/s/SR Policy.

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

I found this document a bit easier to read than the OSPF one. Though it also
seems (implementation) confused on 1:1 association of signaling over a link
with data use of the link and so the confusion on what application to support
on the link. As I noted on the OSPF one, it would be much clearer to simply
discuss the main problem (to me) - the ability to support advertisement of
application specific values?

I don't see any discussion on the dark bandwidth problem or the security
problems identified in RFC8426? It would be helpful if the draft pointed to the
RFC8426 solution.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 11 Jun 2020 15:04:41 +0000

Deborah -

Thanx for your review.

Responses inline.

> -----Original Message-----

> From: Deborah Brungard via Datatracker <[email-masked]>

> Sent: Wednesday, June 10, 2020 3:17 PM

> To: The IESG <[email-masked]>

> Cc: [email-masked]; [email-masked]; [email-masked]; Acee

> Lindem (acee) <[email-masked]>; [email-masked]; Acee Lindem

> (acee) <[email-masked]>

> Subject: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with

> DISCUSS and COMMENT)

[Les:] Peter and I have discussed this suggestion. We have agreed to change “SRTE” to “SR Policy” in both drafts.

[Les:] There are two issues which this draft is addressing – as detailed in the Introduction:

1)Unambiguously indicate which  advertisements are to be used by a given application

2)Support advertisement of application specific values

Both are important.

> problems identified in RFC8426? It would be helpful if the draft pointed to

> the

[Les:] I see RFC8426 and this document as complementary. RFC8426 discusses the operational challenges when multiple applications (specifically RSVP-TE and SR Policy) are deployed in the same network.

This document is defining new encodings in support of application specific advertisements, which eliminate ambiguity as to how to pair link attribute advertisements with applications.

Discussing dark bandwidth issues seems out of scope for this document.

   Les

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 12 Jun 2020 23:15:43 +0000

Hi Les,

On my Discuss, that’s good.

On my comments, I’m still confused then on the scope of the draft. If it was (2) below only, it would seem that this is an extension of current capabilities (my first reading). Considering (1), “unambiguously”, and the use of the terms “legacy” and “all routers are upgraded” in the document, I wonder why this is not considered an update to RFC5305 – is this updating RSVP-TE routers too? If not, and it is only referring to (legacy) SR routers which are doing “legacy advertisements” then I would agree this would not be an update as there is no RFC saying how an SR router should advertise.

Depending on the intention, it would really help to clarify “legacy”, e.g., it is not an RSVP-TE router but a router with SR capabilities still doing “legacy” advertisements. I think Bruno was trying to say this in his rtgdir review. It is really confusing, e.g., here in Section 3, suggest:
Section 3. Legacy Advertisements/s/Legacy SR Advertisements, and “in support of RSVP-TE”/s/”in support of SR” (as it’s an SR “legacy” router)

But if the intention is to upgrade ALL RSVP-TE routers too, and this is an UPDATE to 5305, here can say “in support of RSVP-TE and SR”. Though if this is the intention, it clashes with 6.1 where it says there is no need to do anything for RSVP-TE.

For 6.1, the 2nd bullet, you should add: RSVP-TE is not deployed/s/RSVP-TE is not deployed or planned to be deployed. Here, I agree with Bruno, you really need to provide guidance on “control”, otherwise you will most likely not have interoperability. Suggest: The default SHALL be use of legacy advertisements. Otherwise this is an UPDATE to 5305 as different vendors will choose different defaults.

If this is updating RSVP-TE routers, this should have been shared with TEAS (I don’t recall anything).

Thanks,
Deborah

From: Les Ginsberg (ginsberg) <[email-masked]>
Sent: Thursday, June 11, 2020 11:05 AM
To: BRUNGARD, DEBORAH A <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>; [email-masked]
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

Deborah -

Thanx for your review.

Responses inline.

> From: Deborah Brungard via Datatracker <[email-masked]<mailto:[email-masked]>>

> To: The IESG <[email-masked]<mailto:[email-masked]>>

> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Acee

> Lindem (acee) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Acee Lindem

> (acee) <[email-masked]<mailto:[email-masked]>>

> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=B0HMc26iv-rRpJSj6b79IoD45eROsMXYl_47vjPbzpU&s=Sxxeqg1sPR25hOlFdq6FdXJ9FDoxb36lV9tKE8EC6ZI&e=>

> https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Disis-2Dte-2Dapp_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=B0HMc26iv-rRpJSj6b79IoD45eROsMXYl_47vjPbzpU&s=NU8WByfd9_z3-C2bkJPB9eCdI-EuaRt4JQL5MFWKnEc&e=>

Both are important.

   Les

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 13 Jun 2020 01:05:04 +0000

Hi Deborah,

Point of process…

From: Deborah Brungard <[email-masked]>
Date: Friday, June 12, 2020 at 7:15 PM
To: "Les Ginsberg (ginsberg)" <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Acee Lindem <[email-masked]>, Alvaro Retana <[email-masked]>
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

Hi Les,

RFC 5305 is an IS-IS WG (now LSR WG) document NOT a TEAS document. It doesn’t impact RSVP-TE procedure per se – only the IGP protocol encoding of the attributes which is under the purview of the LSR WG.

Thanks,

Acee

Thanks,
Deborah

Deborah -

Thanx for your review.

Responses inline.

Both are important.

   Les

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Sat, 13 Jun 2020 13:22:22 +0000

Hi Acee,

Thanks- I didn’t mean processed in TEAS, I meant a heads up at least at WG Last Call. They also are doing SR routing (RFC8426).

Ok, if no impact on RSVP-TE routers is the intention, as I noted, the draft should clarify it is discussing legacy SR routers. I agree with you this is then not an RFC update. Most important, the default does need to be specified as off. Otherwise as Bruno noted, this puts a huge burden on the operators and it then is an update.

Thanks,
Deborah

Sent from my iPhone

On Jun 12, 2020, at 9:05 PM, Acee Lindem (acee) <[email-masked]> wrote:

Hi Deborah,

Point of process…

Hi Les,

Thanks,

Acee

Thanks,
Deborah

Deborah -

Thanx for your review.

Responses inline.

Both are important.

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 13 Jun 2020 18:37:55 +0000

Deborah –

Inline.

From: BRUNGARD, DEBORAH A <[email-masked]>
Sent: Friday, June 12, 2020 4:16 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>; [email-masked]
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

Hi Les,

[Les:] “Legacy” refers to routers which do not support the extensions defined in this document.
“Legacy advertisements” are explicitly listed in Section 3.
“Legacy advertisements” have been used (prior to this draft) in support of all of the applications discussed in this draft (RSVP-TE, SRTE (renamed to SR Policy as per your comment), and LFA) because there was nothing else available.
There is no intent to “upgrade RSVP-TE”. The new encodings can be used by RSVP-TE (as discussed in Sections 6.3.4) – but this is not a main motivation for the draft and if it never happens (i.e., RSVP-TE implementations continue to use legacy advertisements) that is fine.

This is introducing new advertisements for link attributes which support per application semantics and provide unambiguous association between link attribute advertisements and applications. This is necessary to address deployments where the constraints defined in Section 6.1 cannot be met.
It is not an update to RFC 5305.
As an analogy, are you suggesting that RFC 5120 should be considered  an update to RFC 5305 because it introduces new forms of IS-Neighbor and Prefix Reachability advertisements?

What the draft mandates is that new applications (i.e., other than RSVP-TE, SR Policy, LFA) MUST use the new advertisements (Section 6.1) . This avoids the introduction of the issues associated with a mixture of legacy/non-legacy routers that can occur with the pre-existing applications.
For existing applications, while we might like to see SR Policy/LFA use the new advertisements, we recognize that this may or may not happen based on the marketplace.
For RSVP-TE, the main motivation to move to new advertisements would be to be able to deprecate the use of legacy advertisements and thereby simplify implementations. But we recognize this isn’t a very compelling motivation and likely won’t happen – or will take many years to happen.

[Les:] Section 6.1 makes explicit the conditions under which legacy advertisements may be used. This is reflecting the operational realities e.g., since legacy advertisements do not provide per application semantics using them when multiple applications are enabled requires congruence for all of the applications enabled.

It also provides guidance to implementors that controls for the types of advertisements which are sent/received will likely be needed.

I see no reason to go beyond what the draft specifies. An implementation which is working and conforms to the published standards in terms of the form of advertisements sent/received is not going to change simply because an RFC says you SHOULD.

[Les:] I leave it to the WG chairs to address this request – to which I have no objection.

   Les

Thanks,
Deborah

From: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, June 11, 2020 11:05 AM
To: BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

Deborah -

Thanx for your review.

Responses inline.

Both are important.

   Les

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 13 Jun 2020 19:58:36 +0000

Hi Deborah,

I hope Les has assuaged your concerns with the RSVP-TE encoding. We have discussed these drafts in the LSR WG extensively and our intention is not to force upgrade. We are encouraging use of the more modern encodings while providing backward compatibility. This is even more important in OSPF where fewer LSAs for the same link will need to be correlated – for OSPFv3 Extended LSAs, all the link information will be advertised in a single LSA.

Thanks,
Acee

From: Deborah Brungard <[email-masked]>
Date: Saturday, June 13, 2020 at 9:22 AM
To: Acee Lindem <[email-masked]>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Alvaro Retana <[email-masked]>
Subject: Re: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

Hi Acee,

Thanks,
Deborah
Sent from my iPhone

Point of process…

Hi Les,

Thanks,

Acee

Thanks,
Deborah

Deborah -

Thanx for your review.

Responses inline.

Both are important.

   Les

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 17 Jun 2020 20:07:13 +0000

Les-

To shortcut the discussion on the need for adding a default for “control”, these two sections are inconsistent as currently worded:

Section 6.1.1
Specifies for SR Policy and/or LFA applications: “This will require implementations to provide controls specifying which type of advertisements are to be sent/processed on receive for these applications.”

Section 6.3.3.

“2)Enable the use of the application specific advertisements on all Routers”

If one is “enabling” then the default is “OFF”? So this document already assumes it. I don’t understand the reluctance to add also to section 6.1.1. When the YANG model is defined, this will be the config default. So either you specify now or later – later, may result in every vendor/platform having a different default if they don’t read section 6.3.3. That will be a major interoperability problem – even potentially among the same vendor for different platforms.

This same comment is for the OSPF document – it needs to specify a default.

More notes below.

Thanks,
Deborah

[Deborah:]
Ok, but I still agree with Bruno – this is very confusing on what is being referenced, especially what needs to be done for RSVP-TE deployments. The addition of the default=off will clarify RSVP-TE deployments remain the same.

[Les:]
[Deborah:]

If this document is similar to RFC5120, why doesn’t it use similar wording? It would be much clearer. RFC5120 abstract says “describes an optional mechanism”. It does not use the confusing terms “upgraded” or “legacy”. The abstract for this document says “This document introduces new link attribute advertisements that address both of these shortcomings.” This document does not say “optional”. It would really help to add similar wording to the abstract. Again, specifying the default “OFF”, will ensure the reader knows these are optional.

[Les:]

[Deborah:]

Maybe some vendors won’t follow an RFC, maybe they will still “work”, but I don’t see that as justification for not clearly defining a control default in one of our RFCs.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 17 Jun 2020 23:18:57 +0000

Deborah –

We have a protocol extension that provides alternative ways of supporting legacy applications.

Under the conditions noted in Section 6.1, implementations have a choice as to which advertisements they use.
There is nothing in the document to specify which choice is the default – nor should there be.
To do so  implies that you believe that an implementation which is otherwise compliant (i.e., it sends/receives TLVs in accordance with the specification) could or should be considered in violation of the specification because it chose to use new advertisements as the default with an option to select legacy advertisements rather than use legacy advertisements as the default with an option to use new advertisements.

Further, what makes sense to be the default – from a user convenience POV - is likely to change over time. Initially the existence of legacy routers will be large and the upgraded routers few. This argues for legacy being the default. But a few years down the road and the numbers will be reversed – in which case the “better” default will be “new”. Declaring conformant implementations in violation simply because they decide to align their defaults with their most common deployment scenarios seems like unreasonable punishment.

There are certainly past examples – not least of which is the introduction of the “extended” TLVs in RFC 5305 - which have followed a similar path. Initially it made sense to default to old style advertisements – but over time it made more sense to default to new advertisements.
Note that RFC 5305 was silent on this – which in my opinion is correct and what we should do here.

I also take issue with your assumption that a default MUST be specified in the corresponding YANG model. I am far from a YANG expert – and will happily defer to those with more experience – but I see no reason why this cannot be modeled as a leaf which can take on one enumerated value – but there need not be a default. It is simply required to have a value.

A few more comments inline.

Sent: Wednesday, June 17, 2020 1:07 PM

Les-

Section 6.1.1

Section 6.3.3.

[Les:] What is being described here is a “hitless transition strategy”. It is wrong to assume that the use of “enable” here means that the default is “disable”.

This is the action taken in Step 2 after you started (Step 1) by using legacy only.

None of this says or implies anything about what defaults are nor what config commands (if any) were needed to place the box in the state specified at Step 1.

This document is not a vendor configuration guide – and I do not want to make it one.

    Les

More notes below.

Thanks,
Deborah

[Les:]

[Les:]

[Deborah:]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 18 Jun 2020 14:21:14 +0000

Hi Les, Deborah,
I agree with Les. Especially since we’ve discussed and evolved these encodings in the LSR WG for over 3 years now. With the zero-length attribute bit mask, we essentially have the equivalent of the legacy advertisements, as well as all the limitations. As long as configuration is provided to dictate which encodings are used, I don’t see that the draft needs to specify the default.
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wednesday, June 17, 2020 at 7:18 PM
To: Deborah Brungard <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Acee Lindem <[email-masked]>, Alvaro Retana <[email-masked]>
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

Deborah –

Les-

Section 6.1.1

Section 6.3.3.

    Les

More notes below.

Thanks,
Deborah

[Les:]

[Les:]

[Deborah:]

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 18 Jun 2020 16:16:29 +0000

Hi Acee, Les,

But the configuration control is not required, it is in small caps “will require”. So there is no guarantee it will be even present. Bruno and myself requested this should be stronger “MUST” or “REQUIRED”. And for “legacy” RSVP-TE applications, recommend a default, OFF, to ensure backward compatibility. Operators always needing to go into their config file (if the control is provided!) and ensure the values are set properly is not very user (operator) friendly or guarantees compatibility.

Just two simple changes (and it aligns section 6.1.1 with 6.3.3). As Bruno noted, this conversation is really frustrating. Especially when consider this is operational input by operators. But it is a familiar standoff - vendors want “flexibility” and operators want compatibility.

I’ll be clearing my Discuss on the ISIS, will also do on OSPF after the revision is uploaded fixing the TE, change to Abstain, saying operators have serious concerns with these documents. And let your AD decide if he wants to continue the discussion. I will be working with my TEAS chairs to ensure we are better aware of TEAS impacting documents being progressed in other groups.

Deborah

From: Acee Lindem (acee) <[email-masked]>
Sent: Thursday, June 18, 2020 10:21 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

Hi Les, Deborah,

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 17, 2020 at 7:18 PM
To: Deborah Brungard <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>, Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

Deborah –

From: BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 17, 2020 1:07 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

Les-

Section 6.1.1

Section 6.3.3.

    Les

More notes below.

Thanks,
Deborah

[Les:]

[Les:]

[Deborah:]