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

From: Ramon Casellas <[email-masked]>
Date: Mon, 15 Aug 2011 21:17:18 +0200

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

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 16 Aug 2011 10:47:50 +0530

Dear Ramon and PCE-WG, 

(1) Encoding of Domain Seq in IRO. 

I like your suggestion to have new IRO object (Object class 10, object type
2). 

This will allow us to add clear rules of processing with respect to domain
sequence. 

We can add text in the draft to define clear behaviour while processing this
new IRO object type. 

Request WG to weight in this option. 

(2) Area Encoding

I have kept the subobject similar to IPv4/IPv6 subobjects. But I have no
objection to your proposed encoding either. 

Wrt to AS Number subobject (type=32) as defined in RFC 3209 allow only 2
octet AS Number. 

WG Chair/Area director: How to handle this - 

(a)    Update to RSVP RFC 3209? 

(b)    Errata to RSVP RFC 3209? 

(c)    New subobject to be defined in this draft to handle 4-byte AS Number?

Request Chairs/AD to comment. 

(3) Scenarios

BN (Boundary Node) and inter-as TE link information be part of domain
sequence? Hmmm.

Adding this optional information in-case the administrator want to exert
control by pre-selecting the BNs and inter-AS link, this deployment scenario
can be added as well.  

We can rearrange the section in the draft to handle scenarios and examples
separately. 

For section 3.3.1, if the domain sequence is made up of only AS, then in
that case PCE should be able to select the next PCE without any ambiguity.
In the example, just the AS number is enough. 

If the AS is further made up of multiple areas and there is a separate PCE
serving each area. PCE should be able to select the next PCE correctly only
when both AS and Area information is available. Thus a distinction was made.

If adding RBNF gives more clarity to draft, am all for it! 

Ramon: I wanted to thank you for such detail review, as you have suggested
detailed text to the draft; we can co-author the draft so that all your
suggestions/texts is correctly incorporated. 

Regards,

Dhruv

****************************************************************************
***********

Dhruv Dhody, Senior Technical Leader, Huawei Technologies, Bangalore, India,
Ph. +91-9845062422

This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

-----Original Message-----
From: Ramon Casellas [mailto:[email-masked]] 
Sent: Tuesday, August 16, 2011 12:47 AM
To: [email-masked]; Dhruv Dhody
Subject: Comments / review of draft-dhody-pce-pcep-domain-sequence-00

Dear Dhruv, all PCErs

comments for

the draft

encoding

 

below.

changes in

defined in

RFC5440.

     1. _Object Ordering_

resulting

mistaken,

whether

ERO in the

clearly

 

     2. _Different Scopes_

object, so type 2

with the

included

     domain sequence.

resolution.

In other

for next

based IRO since

help. For

p-bit set

elements

 

     3. _Limited Procedures_

must

     areas and AS.

     4.  _Strict vs Loose_

     current IRO.

while also

personal

better

"regular"

preferred

another

strict.

Area encoding

===================

     0                   1                   2                   3

     0                   1                   2                   3

     |L|    Type     |     Length    |                               |

     //                        ISIS Area ID                         //

     |                                                               |

be at least

padding at the

or the

 

     0                   1                   2                   3

     |                         Area Id (4 bytes)                     |

     0                   1                   2                   3

     |                                                               |

     //                        ISIS Area ID                         //

     |                                                               |

 

     taken into account

     0                   1                   2                   3

     |                       Ext AS Id (4 bytes)                     |

 

Scenarios

=======================

where

sequence.

e.g. Area0, ABR1, Area1

ASes

sequence

may not

incude IGP areas .

sequence is

IRO ::= <element-list>

grammar

could be of the form

where

 

 

RFC5440 IRO subobjects.

 

Example of Inter-AS IRO

     area      area    AS             area list

      area list        AS              AS

      IntraAS                 AS list

sequences

within the IRO

Thanks for reading

Ramon

---

From: Ramon Casellas <[email-masked]>
Date: Tue, 16 Aug 2011 08:54:45 +0200

Dhruv

Please see inline

On 08/16/2011 07:17 AM, Dhruv Dhody wrote:
> I like your suggestion to have new IRO object (Object class 10, object 
> type 2).
>
Imho it is a good trade-off. Using type 1 would not be backwards compatible

//
>
> (2) Area Encoding
>
> I have kept the subobject similar to IPv4/IPv6 subobjects. But I have 
> no objection to your proposed encoding either.
>
Indeed, that's what I thought. My proposal was motivated by: a) ISIS 
area restriction and b) alignment issues, e.g. in 32 bit machines
Consider this

#include <iostream>
#include <cstdint>

struct A {
         uint8_t  type;
         uint8_t  len;
         uint32_t addr;
         uint16_t resv;
};

struct B {
         uint8_t   type;
         uint8_t   len;
         uint16_t  resv;
         uint32_t  addr;
};

int main () {
         std::cout << sizeof(A) << std::endl;
         std::cout << sizeof(B) << std::endl;
         return 0;
}

The output is 12 and 8. The compiler adds padding to align the address.

> Wrt to AS Number subobject (type=32) as defined in RFC 3209 allow only 
> 2 octet AS Number.
>
Indeed, nothing changes w.r.t to the already existing AS number 
sub-object, but I was proposing _another_  new sub-object to also take 
into account 4-byte AS. See http://tools.ietf.org/html/rfc4893 Since you 
are already proposing Area sub-objects, you may as well include 4-byte AS
>
> WG Chair/Area director: How to handle this --
>
> (a)Update to RSVP RFC 3209?
>
> (b)Errata to RSVP RFC 3209?
>
> (c)New subobject to be defined in this draft to handle 4-byte AS Number?
>
> //
>
If you add Area sub-objects, you may as well add 4-byte AS. We can later 
on address this appropriately since as you mention it is generic and may 
need to be addressed by ccamp?

> If adding RBNF gives more clarity to draft, am all for it!

The RBNF may be overkill and/or may be simplified :)  but the important 
point is that a detailed, generic guideline could be added and the RBNF 
tries to provide some formal information structure

> Ramon: I wanted to thank you for such detail review, as you have 
> suggested detailed text to the draft; we can co-author the draft so 
> that all your suggestions/texts is correctly incorporated.
>

Thanks
R.