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

[Alvaro Retana <[e-mail]>]

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.


> 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 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.
>
> This is a worthy Discuss! But I don't know how to resolve it as a document
> author.

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.