Subject: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-stateful-flags-00: (with DISCUSS and COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Mon, 20 Jan 2020 10:16:42 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-stateful-flags-00: 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-pce-stateful-flags/

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

The acknowledgement to the authors of I-D.ietf-pce-lsp-control-request prompted
me to go take a look at that document and refresh my mind on the fact that it
defines a new flag called LSP-Control Request Flag (C).  I find it hard to
resolve in my mind when it would make sense for the R (LSP REMOVE from rfc8281)
and C flags to be set at the same time.

I couldn't find in rfc8231/rfc8281/I-D.ietf-pce-lsp-control-request or this
document any discussion about the ability (or not) to set more than one Flag at
a time.

In line with it's title, I would like to see this document include rules about
processing of multiple flags.  I know that it is not possible to set out rules
for the interaction of yet-to-be-defined flags, but at least adding text to the
effect of "documents defining additional flags MUST discuss how they interact
with existing flags" would go a long way.

I am balloting DISCUSS because even though this document is not introducing new
issues, the combination of what is defined in
rfc8231/rfc8281/I-D.ietf-pce-lsp-control-request does...and a document titled
"Updated Rules for Processing Stateful PCE Request Parameters Flags" is then
the optimal place to address them.

[Aside: If this DISCUSS is resolved as suggested above, then
I-D.ietf-pce-lsp-control-request, which is on the RFC EDitor's queue, will have
to be updated.]

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

(1) Compatibility

The compatibility issue described at the end of §4 could result in all types of
unforeseen errors or more serious issues; even considering just the one flag
defined in rfc8281: the R flag = LSP REMOVE.  One of the incompatibility
results could be for an rfc8231-only implementation to set the R flag (it has
unknown functionality to the sender), and then for an rfc8281 implementation to
receive the object and remove the LSP.  Not only could this result in
operational issues by removing an LSP that shouldn't have been removed, but
this action could also be considered a denial of service.

This is not a new issue created by this document, but given that the latent
compatibility issues are presented, then a more robust discussion is needed --
I would like to see it in the Security Considerations, but using the
Compatibility Considerations section works for me too.

To be clear on my expectation.  The current text sounds tentative and even
alarming: (paraphrasing) there's an issue that cannot be solved unless we start
over!   It would be nice to then add some text that talks about the potential
effects: taking an unintended action, opening the door for an attacker, etc.

(2) Going back to the specification:

      Flags (32 bits): This document does not define any flags.
      Unassigned flags MUST be set to zero on transmission and MUST be
      ignored on receipt.  Implementations that do not understand any
      particular flag MUST ignore the flag.

Aren't the two Normative sentences redundant?  The most likely reason for a
receiver to not understand a flag is for it to not have it implemented, which
is the same as it considering it not assigned.  Are there cases that I'm
missing which require both statements?  Perhaps s/Unassigned/Unknown and remove
the second sentence.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Jan 2020 03:43:13 -0000

Hello Alvaro,

Thanks for this Discuss. I think you found a hole in draft-ietf-pce-lsp-control-request. It doesn't look like a big hole because if you tried to apply both the C and the R flag, presumably the R flag would get executed making the C flag irrelevant. But I agree that the clarity of how to handle "conflicting" flags is missing.

Now we have to work out how to handle it.

The options seem to be:
1. Set a rule, as you suggest, that documents that define new flags MUST define how to handle the case when the new flags contradict or clash with existing flags. Fix draft-ietf-pce-lsp-control-request according to that rule.
2. Fix draft-ietf-pce-lsp-control-request to clarify how the C flag interacts with other existing flags (specifically the R flag)
3. Define the processing of messages with "conflicting" flags

1.requires a specification and a modification to draft-ietf-pce-lsp-control-request
2. requires a modification to draft-ietf-pce-lsp-control-request
3. requires a specification (that updates 8231)

I agree that this document could be the home for the specification in 1 or 3. But it could also be argued (especially for 3) that a new document with some thought and WG consensus on this new point is required. While the title of this document certainly puts that work in scope, I don't see that we necessarily have to hold back the simple clarification in this document in order to work on the other (perfectly valid) point.

I would also say that documents that apply 2119 language to future documents are not necessarily successful. That is, constraining the authors of future documents is notoriously (but not impossibly) hard. 

That makes me think that options 2 or 3 are best. Option 2 does not require a modification to this document, but does require pulling draft-ietf-pce-lsp-control-request back to fix it. Option 3 does not necessarily require a change to this document *if* a new document is written, and does not require pulling draft-ietf-pce-lsp-control-request back.

This is a worthy Discuss! But I don't know how to resolve it as a document author.

Thanks,
Adrian

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 22 Jan 2020 12:59:04 -0800

On January 21, 2020 at 10:43:16 PM, Adrian Farrel wrote:

Adrian:

Hi!

> Thanks for this Discuss. I think you found a hole in draft-ietf-pce-lsp-control-request.

No, I think I found another hole in rfc8231. ;-)

> It doesn't look like a big hole because if you tried to apply both the C and
> the R flag, presumably the R flag would get executed making the C flag
> irrelevant. But I agree that the clarity of how to handle "conflicting" flags
> is missing.

That's the point, "presumably" is not enough.

> 1. Set a rule, as you suggest, that documents that define new flags MUST
> define how to handle the case when the new flags contradict or clash with
> existing flags. Fix draft-ietf-pce-lsp-control-request according to that rule.
> 2. Fix draft-ietf-pce-lsp-control-request to clarify how the C flag interacts
> with other existing flags (specifically the R flag)
> I agree that this document could be the home for the specification in 1 or 3.
> But it could also be argued (especially for 3) that a new document with some
> thought and WG consensus on this new point is required. While the title of
> this document certainly puts that work in scope, I don't see that we
> necessarily have to hold back the simple clarification in this document in
> order to work on the other (perfectly valid) point.

I suggested option 1 because I have a hard time imagining how to set
up rules for unknown flags...  Of course, the WG may know what those
unknown (to me) flags might be, but if that was the case I would have
expected something more nuanced than "MUST ignore the flag" in this
document.  IOW, the case would have already beed discussed.

I think that option 2 is shortsighted because it only covers the
interaction of the 2 existing flags...and we will end up having this
same discussion when/if a third flag is defined.

> I would also say that documents that apply 2119 language to future documents
> are not necessarily successful. That is, constraining the authors of future
> documents is notoriously (but not impossibly) hard.

I suggested something along the lines of "MUST discuss how they
interact with existing flags", but I'm perfectly fine with "are
expected to discuss...".  The main request (not a constraint!) is to
ask future specifications to consider the interaction -- and to remind
future authors/WG members/etc of the need.

> That makes me think that options 2 or 3 are best. Option 2 does not require a
> modification to this document, but does require pulling
> draft-ietf-pce-lsp-control-request back to fix it. Option 3 does not
> necessarily require a change to this document *if* a new document is written,
> and does not require pulling draft-ietf-pce-lsp-control-request back.
>

I am making assumptions above -- about the WG not knowing what may
come next to be able specify anything longer than a single line, but I
may be wrong.  I would then want the Chairs/AD to consult the WG.

Thanks!

Alvaro.