Re: [CCAMP] AD review of draft-ietf-teas-lsp-attribute-ro

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

Hi Cyril,

Thanks for engaging.

[CCAMP - note just one point wrt draft-ietf-ccamp-wson-signaling]

> >Section 2.3 needs to describe the processing when an ERO Hop Attributes
> >subobject is encountered after a loose hop subobject or a strict hop
> >that is an abstract node?
> >
> >- Is it valid?
> >- Is it assumed to apply to all hops in that loose hop or abstract node?
> >- Or in the case of a loose hop, does it just apply to the named hop
> >  itself?
> >- What about if the preceding subobject is an interface identifier or a
> >  label?
> >
> >I wonder whether reference to 4990 would help at all.
> 
> Following RFC4990, it depends.
> In the context of draft-ietf-teas-rsvp-te-li-lb, a loopback  after a loose
> hop, could be rejected. This should not apply to a label or interface
> In the context of draft-ietf-ccamp-wson-signaling-09, a ResourceBlockInfo
> should target an explicit Hop, but the WavelengthSelection could appear
> after an abstract node or loose hop.
> 
> Future Attributes TLV may apply to interfaces or labels. I think its up to
> the document defining the TLV to scope it.
> For instance the following text could address that:
> Depending on the scope of thea specific Hop attribute TLV, the defining
> document SHOULD describe after which kind of hop they are valid, for
> instance by describing rules similar to [RFC4990] section 6.1.

OK. This is clear. Thanks.

I think *this* I-D needs to make it clear what the expectations are:

1. The sub-object is allowed at any point in the ERO
2. The document that specifies a TLV for the sub-object must make it
   clear where in an ERO a sub-object containing that TLV is allowed and
   not allowed.

That should be an easy edit for you.

> For draft-ietf-teas-rsvp-te-li-lb this could be (restricting the TLV to
> explicit nodes, precluding link ids):
> The Attribute Flags TLV with Loopback Attribute Flag set MUST be present
> after an explicit Hop addressing an TE Router ID identifying a specific
> node or a Link ID identifying an incoming TE link.  it MUST NOT be present
> after a loose,  abstract node, Link ID identifying an outgoing TE link,
> Component Interface ID or Label.

Ah, joy!
Yes. This needs another fix to draft-ietf-teas-rsvp-te-li-lb.
I've made a note in the data tracker and marked that I-D as needing a new
revision.

> For draft-ietf-ccamp-wson-signaling-09, this could be (restricting the
> ResourceBlockInfo to explicit nodes):
> 
>  The WSON Processing HOP Attribute TLV with ResourceBlockInfo MUST be
> present after an explicit Hop addressing an TE Router ID identifying a
> specific node or a Link ID identifying an incoming TE link. it MUST NOT be
> present after a loose, abstract node, Link ID identifying an outgoing TE
> link, Component Interface ID or Label.
> 
> The WSON Processing HOP Attribute TLV with WavelengthSelection only MUST
> be present after an explicit Hop addressing an TE Router ID identifying a
> specific node,  a Link ID identifying an incoming TE link, loose hop,
> abstract node, Link ID identifying an outgoing TE lin or  Component
> Interface ID. it MUST NOT be present after a Label.
> 
> The WavelengthSelection may apply starting at an abstract node, but not
> after a label (as no selection is possible)

Phew, this I-D is still pending my review.
I'll capture that as I process it.
Thanks for doing the work of crafting text.
[I added CCAMP to the recipients of this email so they can see this point]
 
> >3.2.1 has
> >
> >   All such
> >   subobjects MUST be forwarded unmodified by transit LSRs.
> >
> >That is, of course, the general rule, but I assume that there are
> >exceptions.
> >
> >For example, an ASBR may choose to prune the information that is
> >forwarded in an RRO. Similarly, the UNI-N may strip information.
> >
> >I think the point would be that "If a node forwards an RRO subobject
> >for a specific hop, it MUST forward any associated HOP Attributes
> >subobjects."
> >
> >But even this may be too restrictive for a border node that wants to
> >report the chosen path but not expose how the internals of its network
> >are operated. In this case it may want to strip HOP Attributes
> >subobjects from the RRO or even modify them to mask information.
> >
> >Can you add some clarification about all of this?
> 
> Absolutely, for instance changing the MUST in SHOULD, and adding the
> following text:
> 
> "It is noted that a node (e.g. a domain edge node) may edit the RRO to
> prune/modify the RRO, including the RRO Hop Attribute subobject before
> forwarding due to confidentiality policy or other reasons (for instance
> RRO size reduction)."

Perfect.
 
> >I think section 5 is a little optimistic. You are introducing a new
> >mechanism for the control of the behavior on certain nodes on the path
> >of the LSP. Since the control of those nodes may impact the behavior of
> >other LSPs passing the node, some care is needed. For example, setting
> >optical power levels for one lambda can interfere with the signals on
> >other lambdas. Thus, and in general, you have a mechanism that takes
> >control away from the node itself and puts it in the hand of the node
> >that signaled the LSP. This opens up three security possibilities:
> >1. Simple errors in the attributes of an LSP may inadvertently impact
> >   existing LSPs while still allowing this LSP to be set up.
> >2. A malign ingress may signal an LSP down a path and with attributes
> >   chosen to damage other LSPs from other ingresses.
> >3. An attacked Path message may result in damage to other LSPs.
> >
> >The third of these is mitigated somewhat by existing RSVP-TE security
> >mechanisms. The first two (and the third in the case of a subverted
> >node) can only be mitigated by allowing policy to be applied at a node
> >that implements the HOP Attributes it receives in an ERO. A node must be
> >allowed to determine that satisfy the attributes would be inadvisable or
> >against local policy even if practically possible. In these cases the
> >node has a choice to either reject the Path message (but a new error
> >code might be helpful) or to modify the requested attribute (but in this
> >case it might be required to report exactly what it has done, presumably
> >in the RRO).
> 
> I agree in general, the existing text refer to the hop attributes as
> ³functional preferences², as any other RSVP object, this is to be
> considered as ³external input², so subject to policy and sanity check.
> The document does not define how the TLV have to be applied (Just that the
> content must be processed). The aspect of targetting other LSP is, I
> think,  especially valid for WSON, but less applicable for MPLS-TP.
> The same consideration also apply for explicit label control.
> 
> OLD:
> "As any RSVP-TE signaling request, the procedures defined in this
>    document permit the transfer and reporting of functional preferences
>    on specific node.²
> 
> NEW:
> "As any RSVP-TE signaling request, the procedures defined in this
>    document permit the transfer and reporting of functional preferences
> on specific node.
>  The mechanism added in this document does allow more control of LSP
> attributes at a given node. As other inputs, a node should check the Hop
> Attributes against his policies and admission procedures.
> A node may reject the message using existing RSVP error code like "Policy
> Control Failure" or "Admission Control Failure". The node may also,
> depending on the specific TLV procedures, modify the requested attribute.
> "

Perfect.

> I think that Attribute modification is TLV-dependant and should be
> specified in the defining documents.

You should probably also include a statement of this so that people are reminded
to do exactly that.

> >3.2.3 has some SHOULDs and SHOULD NOTs. This always makes me wonder
> > what the exception cases are: under what circumstances MAY an
> > implementation vary from these rules?
> 
> If a specific attribute/document allows it. Wouldn¹t a MUST in that case
> be too restrictive for those documents?
> 
> Would the following text clarify in which case this may be allowed?
> 
> A node MAY use the RRO Hop Attribute to report a LSP Attribute
>    signaled in LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES only if the
>    following conditions are met :
> 
>       Rhe Attribute and its corresponding flag is allowed on both the
>       LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES and LSP Hop Attributes
>       subobject.
> 
>       The document defining this Attribute specify this specific
>       behavior.

Like it.
s/Rhe/The/

Thanks,
Please post the updated version.

Adrian