Subject: [Pce] Question on new IRO type

From: Ramon Casellas <[email-masked]>
Date: Tue, 04 Mar 2014 10:32:39 +0100

All,

As elaborated in [1] (see option c)

     1. _Object Ordering_

     Unfortunately RFC5440 does not mention anything regarding sub-object
     ordering, it only says "to specify that the computed path MUST traverse
     a set of specified network elements" and does not include some text in

the spirit of "Objects within an IRO object MUST appear in 
theresultingERO in the same order that they appear in the IRO". Unless I 
ammistaken,this means that, at least in theory, we should not make 
assumptionswhetherthe sub-objects included in the IRO shall appear in 
the resultingERO in the

     same relative ordering. An implementation is free to iterate the IRO
     subobjects, mark the nodes and links that appear in the IRO and execute
     some kind of traveling salesman problem that makes sure that the path
     travereses the referred elements, albeit the order is not guaranteed.

     - The relative object ordering, however, is fundamental in the domain

sequence. This can be made explicit in the new type, i.e. we canclearly

     define new procedures and restrictions for a new object type.

[1] http://www.ietf.org/mail-archive/web/pce/current/msg02580.html

-- 
Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division
Optical Networks and Systems Department -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya
Parc Mediterrani de la Tecnologia (PMT) - Edifici B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 93 645 29 01

---

From: Ramon Casellas <[email-masked]>
Date: Tue, 04 Mar 2014 10:35:58 +0100

> As elaborated in [1] (see option c)
Err, I meant b).  The motivations were mainly:

   1. _Object Ordering_
     2. _Different Scopes_
     3. _Limited Procedures_
     4.  _Strict vs Loose_

R.

---

From: Jonathan Hardwick <[email-masked]>
Date: Wed, 5 Mar 2014 13:52:51 +0000

Ramon, Dhruv,

In my opinion, the existing IRO object should be treated as an ordered sequence of hops.

It is true that RFC 5440 does not make any statement at all about whether the IRO is ordered.  However, we have RFC 5521, which describes the use of the EXRS subobject as follows (section 2.2.2):

   If a PCE parses an IRO and encounters an EXRS [...] the PCE MUST NOT
   produce a path that includes any resource identified by the EXRS
   subobject in the path between the previous abstract node in the IRO
   and the next abstract node in the IRO.

Although this is open to interpretation, I think that this implies that the abstract nodes in the IRO are specified in order.

Instead of creating a new object type for “ordered IRO”, I would prefer to resolve this by clarifying that the IRO in RFC 5440 is ordered.  Your draft and the protocol will be simpler as a result.

If operators have use cases for which an unordered IRO is required, then I think this should be dealt with by creating a new object type for “unordered IRO” (and probably excluding the use of EXRS in that object).  But that would not need to be dealt with by your draft.

Of course, this is just my opinion, and is still open to interpretation as we have said.

Best regards
Jon

From: Ramon Casellas [mailto:[email-masked]]
Sent: 04 March 2014 09:36
To: [email-masked]; Jonathan Hardwick
Subject: Re: [Pce] Question on new IRO type

All,

  1. _Object Ordering_
    2. _Different Scopes_
    3. _Limited Procedures_
    4.  _Strict vs Loose_

R.