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 _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
