Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-lsp-control-request-09: (with DISCUSS and COMMENT)

[Dhruv Dhody <[e-mail]>]

Hi Ben,

> >
> > > What kind of feature negotiation is available to check support prior to
> > > using this flag?  After all, if the peer does not implement this
> > > document it will not implement the override of 8231 error handling and
> > > will respond with errors when the D flag is set (or the PLSP-ID of 0
> > > used).  If we have to just "try it and fall back to not using it if we
> > > get errors", that has some associated security considerations as well.
> > >
> >
> > In this case Capability negotiation might be an overkill. We are just
> > adding a new flag; there is a clear error case to work with legacy
> > implementation.
> >
> > Anyways, We can update the security considerations to include this
> > fact. Something like -
> >
> >    Note that, a PCE may not be sure if a PCC supports this feature.  A
> >    PCE would try sending a control request to a 'legacy' PCC, which
> >    would in turn respond with an error as described in Section 4.  So a
> >    PCE would learn this fact only when it wants to take control over an
> >    LSP.
> >
> > Do you see anything else worth highlighting?
>
> If TLS is not used, a MITM could inject an error and cause the PCE to not
> use the feature when it otherwise could be used.  But the consequences of
> that are, I think, not terribly severe, so we don't need to do more than
> note the risk of downgrade.

That can be added.


> > So the key question is that does this 'control request' raises to the
> > level that we make policy a MUST, when RFC 8231/8281 did not...
>
> I think I can accept the SHOULD-level requirement; thanks for the above
> text.
>

Thanks!


> > >    It should be noted that a legacy implementation of PCC, that does not
> > >    support this extension would trigger the error condition as specified
> > >    in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and
> > >    error-value 1 (Attempted LSP Update Request for a non-delegated LSP))
> > > I don't understand this sentence -- what does "as the D Flag would be
> > > unset" mean?  Does it just mean that the PCC treats it as unset because
> > > it has no code to handle the D flag at all?
> > >
> >
> > Suggestion to make this clearer with -
> >
> >    It should be noted that a legacy implementation of PCC that does not
> >    support this extension would trigger the error condition as specified
> >    in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and
> >    error-value 1 (Attempted LSP Update Request for a non-delegated
> >    LSP)), as any control request would have the D Flag (delegate) unset
> >    and it would be considered as attempt to update a non-delegated LSP.
>
> That's an improvement, but only a slight one (or perhaps I'm still
> confused).  The question seems to be not whether the D flag is set (which
> is controlled solely by the PCE), but whether the PCC recognizes that the
> D flag is set (i.e., whether it recognizes the D flag at all).  So perhaps
> "as the D Flag would not be processed, and it would be considered as an
> attempt to update a non-delegated LSP"?
>

I think you mean C flag would not be processed. Just to clarify -

- D flag is defined in RFC 8231 and any PCUpd message would always set
it as per RFC 8231.
- This document defines a new C flag, and ask that D flag must be
unset if the C flag is set.
- A legacy implementation that receives an PCUpd with C=1 and D=0,
would simply ignore the C flag and trigger the error because D flag is
unset.

Let me try again -

   It should be noted that a legacy implementation of PCC that does not
   support this extension would receive an LSP control request: PCUpd
   message with C flag set and D flag (delegate) unset, it would ignore
   the C flag and trigger the error condition for the D flag as
   specified in [RFC8231] (a PCErr with Error-type=19 (Invalid
   Operation) and error-value 1 (Attempted LSP Update Request for a non-
   delegated LSP)).

Thanks!
Dhruv