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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
