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

["BRUNGARD, DEBORAH A" <[e-mail]>]

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) <[e-mail]> wrote:


Hi Deborah,

Point of process…

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

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



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

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


Deborah -



Thanx for your review.

Responses inline.



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

> From: Deborah Brungard via Datatracker <[e-mail]<mailto:[e-mail]>>

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

> To: The IESG <[e-mail]<mailto:[e-mail]>>

> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Acee

> Lindem (acee) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Acee Lindem

> (acee) <[e-mail]<mailto:[e-mail]>>

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

> DISCUSS and COMMENT)

>

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

> 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/<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=>

>

>

>

> ----------------------------------------------------------------------

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

>

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



>

> ----------------------------------------------------------------------

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

>

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



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

>

[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



>