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

"Adrian Farrel" <> Wed, 21 January 2015 11:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 442E11A1A22; Wed, 21 Jan 2015 03:57:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KjYjmYEmkMbF; Wed, 21 Jan 2015 03:57:43 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E58411A1A1E; Wed, 21 Jan 2015 03:57:42 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id t0LBveuw013271; Wed, 21 Jan 2015 11:57:40 GMT
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t0LBvb84013235 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2015 11:57:38 GMT
From: "Adrian Farrel" <>
To: "'Cyril Margaria'" <>, <>
References: <012001d0274b$d25f3630$771da290$> <>
In-Reply-To: <>
Date: Wed, 21 Jan 2015 11:57:37 -0000
Message-ID: <011b01d03571$7526d480$5f747d80$>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJNJKbqcA8ICrxY/nQ0vdspVCXFtAG4lZZam8LQ7AA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--22.294-10.0-31-10
X-imss-scan-details: No--22.294-10.0-31-10
X-TMASE-MatchedRID: Ync95tbzDRmnykMun0J1wtxajlW+zwxCC/ExpXrHizwJW4Re2U2py+50 k+nSYSmWO4Z0ZkXCjJsUPsM54RzshHYIQoHEix+qdrpCZsJVIIUpWss5kPUFdGu9/l5WAy7sbOh vQwxZCUumUhnCmPhVLUlKUqmaZWPdzsxad8fKloYzSlmIs9AhOtEA4SsNDgaiXudxyY/AL0eXNa gpKKGTEzmrSBe3bBipItB1q1kmkIKbdVs/uMg2/8H0JgP/bKWSQa2sDHLkQ040QmmUihPzrJ8zj Z45FG+UwOalMNNoWHYYkIWWLQ+ruev/j3sV8W9mW7gz/Gbgpl4/W/kEeVcLFGjSAumzejoRDgvn ApkxBAVSRo6Tk1CHbLtnawFLb7obvYmC3IHzHcj/VoEOchXiKVXKDhjPZTukMKZRiezcUtMgRPl rGC5FrzzIYciYTdEA3KCE1AIrmzWH6FJxCilEmWbzlCg24oq+h+w9Wz/xXDprEoFtNYg0C4ARql 3UMZ6bVgi2vEnHdgKGDG1lR3xKVq+2LFpqaFp51yMJs9mBCcUvfgjwim9BwsUdzAovpQT/eu5z4 syzGYYu6BdQaUaE9nkNrWD+KBWtoayr11+eKrlRKfej56hSbJsqkCVjbLpJAuVirUrNCL+g0ehM cZ850tJpCbWqQKk2C1MkYihD/gEKT+RHLhCkHMqXjImgj58becvjbu/xDjr3qGsw1oZ+zxwz72z DzvkOCMe3Br715Je4Clh+0goxykq+i9GrWzgshsE+u3nnCfAk227IvqakhftHa1P9/19Uo8WMkQ Wv6iXhWDPiI8D3842j49Ftap9EkGUtrowrXLg=
Archived-At: <>
Subject: Re: [CCAMP] AD review of draft-ietf-teas-lsp-attribute-ro
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Jan 2015 11:57:46 -0000

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

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

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

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
>       subobject.
>       The document defining this Attribute specify this specific
>       behavior.

Like it.

Please post the updated version.