Re: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-inter-layer-ext-12: (with COMMENT)

["Adrian Farrel" <[e-mail]>]

Hej Mirja,
Thanks for the review.

> Minor comments:
> 1) I guess the I flag in the INTER-LAYER Object is actually not needed as
> the present of the INTER-LAYER Object already indicates that inter-layer
> information is requested, but that is not an issue.

I think that this is true in a PCReq, but it may be helpful for an implementation to always include the object but toggle the flag.
But in a PCRep the difference (while semantically the same) can have different inference. Thus...
If a PCReq has the object with I=1 and the PCRep has the object with I=0 we know that the responder considered providing an interlayer path, but did not. If, instead, the object is absent from the PCRep we can't be sure how seriously the responder considered the request (although the result is still a mono-layer path).

> 2) Is the INTER-LAYER Object Flags registry really needed, given the
> limited amount of flag space???

I think so, yes.
The registry is to stop collisions.
I don't see how the size of the range makes much (any) difference.
If you don't have a registry, anyone can grab any bit and there is a requirement that everyone reads every draft to avoid collisions.

> 3) Security Consideration: "Inter-layer traffic engineering with PCE may
> raise new security
>    issues when PCE-PCE communication is done between different layer
>    networks for inter-layer path computation."
>    This text is not very helpful as this section is meant to be used to
> document these new issues.

I'm trying to avoid saying "this should be obvious to one skilled in the art" since that always annoys me when the US patent office says it to me.

We could fill this out as...

OLD
   Inter-layer traffic engineering with PCE may raise new security
   issues when PCE-PCE communication is done between different layer
   networks for inter-layer path computation.  Security issues may also
   exist when a single PCE is granted full visibility of TE information
   that applies to multiple layers.

   Path-Key-based mechanism defined in [RFC5520] MAY be applied to
   address the topology confidentiality between different layers.
NEW 
   Inter-layer traffic engineering with PCE may raise new security
   issues when PCE-PCE communication is done between different layer
   networks for inter-layer path computation because information about
   the networks at different layers will necessarily be exposed in
   computation results.  Furthermore, a PCE in one layer might use 
   computation requests to "probe" for information about the network
   in the other layer. 
   
   Security issues may also exist when a single PCE is granted full 
   visibility of TE information that applies to multiple layers.

   In both cases cited here, the security concerns are to do with 
   exposure of information about a network to parties outside that
   network.  These concerns relate to the privacy of the commercial
   details of a network, but it should also be understood that 
   distributing information about networks extends the attack surface
   for those networks.

   Path-Key-based mechanism defined in [RFC5520] MAY be applied to
   address the topology confidentiality between different layers.
END

Thanks,
Adrian