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

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 3 Jan 2015 11:52:58 -0000

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.

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?

---

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

===

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

---

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/

---

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?

---

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

---

From: Cyril Margaria <[email-masked]>
Date: Wed, 21 Jan 2015 07:30:10 +0000

Hi, 

Thanks for your careful review,
Please see inline.

WG feedback is welcomed.

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

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

>case it might be required to report exactly what it has done, presumably

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.

>RFC, so you should "define".

Agree,

>Trying to parse this, I think you mean s/addition/additional/

Agree,

>the exception cases are: under what circumstances MAY an implementation

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.

>value as assigned in 4.1?

Agree.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 21 Jan 2015 11:57:37 -0000

Hi Cyril,

Thanks for engaging.

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

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

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

> 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]
 
> forwarding due to confidentiality policy or other reasons (for instance

Perfect.
 
> depending on the specific TLV procedures, modify the requested attribute.

Perfect.

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

Like it.
s/Rhe/The/

Thanks,
Please post the updated version.

Adrian

---

From: Lou Berger <[email-masked]>
Date: Wed, 21 Jan 2015 14:17:05 -0500

[ccamp dropped response doesn't concern the WSON draft]
> I've made a note in the data tracker and marked that I-D as needing a new
I think this phrasing is too restrictive as it may be possible to put
some of the identified items into loopback in some technologies, e.g.,
an output interface.  How about:

after:
    The mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used to
address the loopback request
     to the particular node.
add:
     The ingress MUST ensure that the desired  loopback mode is strictly
identified in the ERO.
and
OLD:

   If the bit is set, the node SHOULD try to put the LSP into loopback mode.
NEW
    If the bit is set, the node MUST check that the desired loopback is
strictly
    identified by verifying that the L bit is set to 0 in both the ERO Hop
    Attributes subobject and the prior subobject. The prior subobject
    MUST also be checked to ensure that it provides strict identification.
    Currently, the type value MUST be verified to be less than 32, and
    for type values 1 and 2 the prefix length MUST be 32 and 128
respectively.
    If the desired loopback is not strictly identified the request MUST
be ignored
    and a "Bad EXPLICIT_ROUTE object" error SHOULD be generated.

     Otherwise, the node SHOULD try to put the LSP into loopback mode.

Lou

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 22 Jan 2015 06:26:58 +0000

Hi Lou, 

Thanks a lot for providing the suggested description. I think it specifies a reasonable rule of using the ERO Hop Attributes subobject in the loopback scenario. 

Adrian, if you also like it, I can update the draft accordingly.

Many thanks,
Jie

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Thursday, January 22, 2015 3:17 AM
> To: [email-masked]; 'Cyril Margaria'; [email-masked]
> Cc: [email-masked];
> [email-masked];
> [email-masked]
> Subject: Re: [Teas] AD review of draft-ietf-teas-lsp-attribute-ro
> 
> [ccamp dropped response doesn't concern the WSON draft] On 1/21/2015 6:57
> AM, Adrian Farrel wrote:
> >> > 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!
> > I've made a note in the data tracker and marked that I-D as needing a
> > new revision.
> >
> I think this phrasing is too restrictive as it may be possible to put some of the
> identified items into loopback in some technologies, e.g., an output interface.
> How about:
> 
> after:
>     The mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used to address
> the loopback request
>      to the particular node.
> add:
>     If the bit is set, the node MUST check that the desired loopback is strictly
>     for type values 1 and 2 the prefix length MUST be 32 and 128 respectively.
>     If the desired loopback is not strictly identified the request MUST be
> ignored
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 22 Jan 2015 12:34:02 -0000

Yes, please!
Update and post.
Adrian

> From: Dongjie (Jimmy) [mailto:[email-masked]]
> Sent: 22 January 2015 06:27
> To: Lou Berger; [email-masked]; 'Cyril Margaria'; [email-masked]
draft-ietf-teas-lsp-attribute-
> [email-masked]; [email-masked]
> Subject: RE: [Teas] AD review of draft-ietf-teas-lsp-attribute-ro
> 
> Hi Lou,
> 
> Thanks a lot for providing the suggested description. I think it specifies a
> reasonable rule of using the ERO Hop Attributes subobject in the loopback
> scenario.
> 
address
strictly
respectively.