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

[Cyril Margaria <[e-mail]>]

Hi, 

Thanks for your careful review,
Please see inline.

WG feedback is welcomed.

On 03.01.15 06:52, "Adrian Farrel" <[e-mail]> wrote:

>Hi authors,
>
>Thanks for this document, the first from TEAS to reach me for
>publication. I found it to be a simple and clear read. The IANA section
>is clear and well-written.
>
>I have done my usual AD review with the intent to catch any remaining
>issues before issuing IETF last call.
>
>I think my first three points need discussion with the working group.
>The remaining points are relatively small.
>
>While I wait for your discussion or a new revision, I'll put the draft
>into "Revised I-D Needed" state.
>
>Thanks for your work,
>Adrian
>
>---
>
>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.

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.

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)





>
>Note that 3.2 seems to handle all the options for use in the RRO.
>
>---
>
>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)."





>
>---
>
>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.
" 

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

>
>===
>
>Please don't "propose". You intend this document to be published as an
>RFC, so you should "define".

Agree,

>---
>
>3.1 has
>
>   Attributes TLVs  The processed or addition HOP Attributes, using the
>      format defined in Section 2.2 .
>
>Trying to parse this, I think you mean s/addition/additional/

Agree,

>
>---
>
>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.




>
>---
>
>In section 4.2, do you want to add a request to IANA to use the same
>value as assigned in 4.1?

Agree.