[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
- [Pce] Comments / review of draft-dhody-pce-pcep-d… Ramon Casellas
- Re: [Pce] Comments / review of draft-dhody-pce-pc… Dhruv Dhody
- Re: [Pce] Comments / review of draft-dhody-pce-pc… Ramon Casellas