[Pce] Comments / review of draft-dhody-pce-pcep-domain-sequence-00

Ramon Casellas <ramon.casellas@cttc.es> Mon, 15 August 2011 19:17 UTC

Return-Path: <ramon.casellas@cttc.es>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A764411E80E2 for <pce@ietfa.amsl.com>; Mon, 15 Aug 2011 12:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5x+hloWXSsv for <pce@ietfa.amsl.com>; Mon, 15 Aug 2011 12:17:15 -0700 (PDT)
Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id 0488811E80D7 for <pce@ietf.org>; Mon, 15 Aug 2011 12:17:14 -0700 (PDT)
Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7FJHJhU027235; Mon, 15 Aug 2011 21:17:24 +0200
Received: from [192.168.0.193] (unknown [95.62.145.63]) by castor (Postfix) with ESMTP id EBD362FC246; Mon, 15 Aug 2011 21:17:19 +0200 (CEST)
Message-ID: <4E4970BE.6040002@cttc.es>
Date: Mon, 15 Aug 2011 21:17:18 +0200
From: Ramon Casellas <ramon.casellas@cttc.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110809 Thunderbird/6.0
MIME-Version: 1.0
To: pce@ietf.org, Dhruv Dhody <dhruvd@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Mon, 15 Aug 2011 21:17:20 +0200 (CEST)
X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197
Subject: [Pce] Comments / review of draft-dhody-pce-pcep-domain-sequence-00
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pce>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 19:17:16 -0000

Dear Dhruv, all PCErs

Please find below a (rather long, apologies in advance) review and 
comments for
draft-dhody-pce-pcep-domain-sequence-00. First and foremost, I believe 
the draft
addresses a couple of much-needed extensions, namely, area sub-objects 
encoding
and domain sequences. Following chairs suggestion to foster discussion, I am
sending directly to the main mailing list.

Comments and discussions welcome :)


Encoding of a Domain Sequence
================================

I agree that using the Include Route Object (IRO) is a natural choice rather
than adding a new object class. However, I have some doubts as detailed 
below.
I may have missed previous discussions on this topic.
For the actual encoding, basically the options we have are:

a) Keep the RFC5440 IRO object (Object class 10, object type 1)

b) Use a new IRO object (Object class 10, object type 2) i.e. "the
request includes/refers to a domain sequence". In this case:

b.1. that replaces current one with better defined semantics and scenarios

b.2. that complements (can be together with) current one, requires 
changes in
the PCEP request grammar.

c) Propose a new object class i.e. DOMAIN_SEQUENCE

It isn't clear to me which option is best. The reasons for this are several.
The first option, which is the one proposed in the draft has, imho, some
drawbacks, some of them due to the strictest interpretation of IRO as 
defined in
RFC5440.

     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 the 
resulting
     ERO in the same order that they appear in the IRO". Unless I am 
mistaken,
     this means that, at least in theory, we should not make assumptions 
whether
     the sub-objects included in the IRO shall appear in the resulting 
ERO 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 can 
clearly
     define new procedures and restrictions for a new object type.


     2. _Different Scopes_

     - Using  new object or different object types easily differentiates two
     different scopes. This was already done with RFC5440 BANDWIDTH 
object, so type 2
     means "bandwidth for re-optimization", or with draft-ietf-pce-gmpls 
with the
     ENDPOINTS / BANDWIDTH object since it was mentioned that the strictest
     interpretation of RFC5440 forbids this object to have TLVs. With a
     different type or class one IRO(10,1) can refer to objects to be 
included
     within the current domain and the other IRO(10,2) strictly to the
     domain sequence.

     - It is easier for an implementation to check type 1 for algorithmic
     constraints and to check type 2 for domain sequence and "next PCE" 
resolution.
     In a typical implementation, this may be done at different places. 
In other
     words, a PCE may be able to support a domain sequence which is used 
for next
     PCE resolution  / BRPC / etc. but may not be support an element 
based IRO since
     e.g. the backend algorithms may be based on some CSPF or Dijkstra path
     computation. What should this PCE do? a new class or new type could 
help. For
     example, a new type can clearly state that a IRO (10,2) with the 
p-bit set
     means, for example, that Domain sequence must be honored, and that 
elements
     within a TE domain MAY be honored.


     3. _Limited Procedures_

     - Nothing is said in IRO and XRO objects what the procedures are when a
     sub-object is not found. In XRO the straighforward option is to simply
     ignore the unknown subobject. It is not clear to me what should be the
     default procedure for an unkonwn IRO subobject. It could be ignored or
     it could trigger an error. If we apply this to the domain sequence, I
     would say that an unknown subobject at this level should trigger some
     kind of high level error, like "PCE domain chain broken" or similiar

     - An IRO object with a p-bit (mandatory) set, means that the object 
must
     be processed so, imho, means that the resulting ERO must contain the
     elements in the IRO. This can be enforced / checked with the subobjects
     are TED elements, but it is not clear how to proceed with Areas and AS.

     - Does not support areas, and nothing is said regarding the order of
     areas and AS.

     4.  _Strict vs Loose_
     - RFC 5440 clearly states "The L bit of such sub-object has no meaning
     within an IRO". If we now allow domain sequences, is there any use case
     where having loose objects makes sense? For example, one may have
     AS domain sequence with some AS being "loose". This is somehow against
     current IRO.


Option c) has also several drawbacks, notably that it could end up somehow
redundant with IRO if we want to be able to specify domain sequences 
while also
imposing also border nodes and/or inter-domain links.  I think that my 
personal
preference would be using a new IRO object type (e.g.  2) which could be
extended to include Areas, AS, clarify ordering, improve semantics and 
better
define procedures. This new IRO "replaces" or "extends" the old IRO and may
appear where IRO(10,1) appears. A single intra domain PCE could use 
"regular"
IRO, while the new type conveys "multi-domain information". If the 
preferred
option is to keep (10,1) the draft should clarify procedures but this could
somehow contradict RFC5440? As stated above, my main driver to suggest 
another
type is the previous work where a new type has been added where RFC5440 was
strict.



Area encoding
===================

     The following encoding is proposed for Area IDs:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |      Area Id (4 bytes)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Area Id (continued)           |           Resvd               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     //                        ISIS Area ID                         //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     However, with the additional constraint for ISIS: "The Length MUST 
be at least
     4, and MUST be a multiple of 4." This implies that there will be 
padding at the
     end, or a reserved field, which is not clear neither from the text 
or the
     figure. An alternetive proposed encoding would be (uint32_t alignment):


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Area Id (4 bytes)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                        ISIS Area ID                         //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     If, as Adrian mentioned in some old mail, 4-byte ASes need to be
     taken into account

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Ext AS Id (4 bytes)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Scenarios
=======================

I believe that the draft should also address or just mention those cases 
where
there are additional restrictions or constraints covering which border nodes
(ABRs, ASBRs) or border links (InterAS links) while defining a domain 
sequence.

e.g. AS100, IPv4 prefix, AS200

e.g. Area0, ABR1, Area1


In Section3.3.1 It is somehow confusing to mention that Both AS are made of
area 0, somehow mixing "deployment scenarios" and "examples". I think that a
domain sequence made of AS only subobjects is independent of whether the 
ASes
are, in turn, divided into IGP areas or not. In other words, a domain 
sequence
composed of only AS is only a high level description of the domains that the
path must traverse, regardless of the areas. The domain sequence may or 
may not
incude IGP areas .

Maybe the draft needs a formal section that details how the domain 
sequence is
encoded, before jumping into deployment scenarios / examples. A rough draft,
not checked, and to be discussed would be as follows:

For reference, current RFC5440 basically is

IRO ::= <element-list>
element-list ::= <element> [<element-list>]
element := <ipv4prefix> | <ipv6prefix> | <unnum_ifid> | <AS subobject>

If we want to clearly define ordering and preferred format, a proposed 
grammar
could be of the form

IRO ::= <inter-AS IRO> | <intra-AS IRO>  | <intra-area IRO>

1) inter-AS IRO   ::= [<intra-AS IRO>] <AS-list>

     An inter-AS IRO is composed of a part regarding the current AS
     followed by one or more AS parts

2) intra-AS IRO   ::= [ <AS> ] <area-list>

     An Intra-AS IRO is optionally qualified by an AS subobject
     followed by one or more area IROs.

3) intra-Area IRO ::= <area>

     An Intra Area IRO is optionally qualified by an area subobject
     followed by one or more intra-area (i.e. TE domain) elements.

where

4) <AS-list> ::= <AS> [<AS-list>]

5) AS ::= <AS subobject> [<area-list>]


An AS list has one or more AS-level IROs, each AS-level IRO has one
AS subobject optionally followed by one or more area-level IRO which has
an Area subobject (in turn, optionally followed by network elements)


6) <area-list>  ::= <area> [<area-list>]

7) area ::= [<IGP area subobject>] [<element-list>]

8) element-list ::= <element> [<element-list>]

9) element := <ipv4prefix> | <ipv6prefix> | <unnum_ifid> referring to 
RFC5440 IRO subobjects.


And to cover AS inter-AS links

10) AS ::= <AS subobject> [ <area-list> | <element> ]


Example of Inter-AS IRO
=======================================

node1, node2, area2, AS100, AS200, area2, area3
<-----------><-----><------><----> <----------->
     area      area    AS             area list
<------------------><------><------------------>
      area list        AS              AS
<-----------------><--------------------------->
      IntraAS                 AS list


So the main points are: a) optimal encoding of domain sequence b) suggestion
for IGP area subobjects and c) formal (RBNF) specification of domain 
sequences
within the IRO

Thanks for reading

Ramon