Hello Ramon,

>> I understand the motive for this work and, indeed, it fills a hole in the
protocol spec.
>
> [Ramon] if you could elaborate a bit more on which hole(s) exactly, I would
> make sure that we can come up with a more satisfactory proposal, e.g a) the
> lack of (some?) route sub-objects for domain encodings, b) the ordering 
> constraints, c) decoupling and relationship between PCE-sequences and 
> domain-sequences? (personally, I find a) and b) more important.)

I find a) most important.
As far as I am concerned, the PCE sequence is already decoupled from the IRO.
I find the way that this I-D decouples the domain sequence from the path
"inconvenient".
  
>> I do hope that the authors are building it for shipping equipment and
deployment. If
>> not, would they please consider whether it should be experimental?
>
> [Ramon] I have no objection at being experimental, what option the WG things
more
> appropriate is fine for me.

Open issue for the chairs to drive.

>> I am concerned that this document changes the definition and intent contained
in
>> RFC 5440. In my opinion the authors of 5440, and the WG at the time, went to
>> some lengths to tie the content of objects in PCEP to the same definitions
found
>> in RFCs 3209, 3473 and 3477. At the same time, definitions of subobjects for
path
>> definition, should also pay attention to RFCs 4874 and 4920. The intention is
to not
>> define more subobjects than needed and to keep registries aligned
>
> [Ramon] agreed, and this is the intention. See also my other comments below

Excellent. So it is probably just nits.

> [Ramon] I would really appreciate your thoughts on whether  [E/X/R/I]RO 
> sub-objects for OSPF-TE areas and IS-IS areas are needed, as well as 4-byte
> AS (unlike TLVs, 4 byte AS and 2-byte AS sub-objects cannot share the
> encoding). This is in line with your concern whether more sub-objects are
> needed or not, which should also be brought to ccamp attention as well.
>
> Some (initial, loose) discussions on the need for IGP sub-objects were
> indirectly discussed in
http://www.ietf.org/mail-archive/web/pce/current/msg02561.html

We need to consider two "fringe" conditions.

1. A PCE serves multiple domains. In this case, if the PCC wishes to control the
domain path, it needs to be able to specify domain IDs as inclusions and
exclusions.

2. There may be segments of the path where per-domain signaling is needed. In
this case there needs to be an exchange of objects (back and forth) between PCEP
and RSVP-TE in order to achieve control of the domain path.

That said, in my experience, the domain paths in current deployments are not
long, and border routers are often known a priori.

>> It is also worth noting how 4920  handles 2 and 4 octet AS numbers and that
>> there is overlap in the definition of AS number subobjects with 
>> draft-zhang-pce-hierarchy-extensions-01
>
> [Ramon] We had considered 4920 for this, although the proposed encodings
> are as TLVs (for IF_ID ERROR_SPEC objects) and this i.-d. work was (arguably)
> regarding route objects. I agree that, as TLV encodings, a single 4 byte
encoding
> for both 2-4 bytes AS makes a lot of sense, specially since the 16-bit
sub-registry
> is common. This would also solve the problems regarding IGP areas.
>
> If I may, what kind of encoding would you suggest? In previous discussions it 
> was suggested that we should use the IRO for the problem we were trying to
> solve , which somehow precludes the use of TLVs unless wrapped in a ERO
> subobject (had we been given the green light for a new object, which is not
> necessarily the right thing to do, I would be happy to use 4920 tlv encodings
> for this)

I guess I would need to look at this in more detail. I don't see a lot of
difference between a TLV encoding and a subobject encoding. The main difference
is the codespace the T values come from. Obviously, you can't munge the two code
spaces, but you can share encodings.

> [Ramon] AS number subobjects and all common IANA registry requests between
> this draft and draft-zhang-pce-hierarchy-extensions-01 MUST be unified and
being
> involved in both we make sure they will.

Perfect.
 
>> In this light and on careful reading, the IANA section is somewhat broken and
>> confused about what should be in the registry it is creating.
> 
> [Ramon] agreed, and most importantly, it must also be brought to ccamp
> attention as well. 

Good idea

>> But I am also unsure why a new IRO type is needed. Surely the domain 
>> sequence that is used in the computation is also the domain sequence 
>> for the path that the LSP will take. This feeds on the points below.
>
> [Ramon] The main rationale behind this discriminator is the ordering
> constraint, since (my guess) no ordering assumption could be inferred
> from rfc5440. IIRC this was confirmed (I am sorry I wasn't in Taipei, I
> may be wrong).
> Quoted from a past mail:
> http://www.ietf.org/mail-archive/web/pce/current/msg02580.html
>
> "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". As an RFC 5440 co-author  maybe you
> can comment on this? is the ordering implicit?

Very good quote. Yes, this uncovers the ordering issue with the IRO. And,
thinking back, it was exactly the intention that the IRO did not imply any
ordering. Usually, I think, the IRO would contain a small number of nodes/links
to give hints to the computation, or to take the path through key points in the
network.

So, this is a bigger issue than just the domain sequence: how does the PCC
request an ordering of path elements?

The answer may be that it should not need to. Maybe, even, that it has no
meaning for it to do so.
This answer could apply equally to nodes, links, or domains.

I think this can be proved by drawing a picture. If there is the possibility to
route a path from domain X through domains A, B, C, and D to domain Z, why
should the PCC state the order that they must be traversed? Surely the PCE will
work out which is the better path XABCDZ or XACBDZ. If, on the other hand, the
only possible path is XABCDZ then the PCC does not need to worry about the order
of the domains it lists in the IRO because the PCE can only produce one result.

Now, I can hear in my head the people saying that it is more complicated if the
PCE has to work out the ordering of the domains, but I wonder why this is more
complicated than working out the ordering of nodes. And I do think that the PCC
should be spared the complexity of knowing or working out any sequencing for the
path.

> In any case, the actual solution and encoding is open to discussion. IF
> the ordering inclusion is implicit, I have no objection for using the
> existing IRO and this includes your subsequent concerns with its contents.
>
>> The algorithm in 3.4:
>> - assumes only area IDs and AS numbers
>> - assumes that a PCE knows at least one PCE responsible for
>>    each of its neighboring domains
 >
> [Ramon] afaik, the algorithm was added recently in order to simplify the
> (apparently overkill and over-)specification of the IRO sub-objects which
> was also proposed by me in the aforementioned mail 
> web/pce/current/msg02580.html (which tried, as a informational exercise,
> to also capture intra-domain objects). The motivation behind both is to
> clarify its usage. Depending on the outcomes of this and further discussions
> they can be elaborated, removed (by relying on the existing documents) or
> clarified.

OK

>> I would like the authors to take care that the identity of a boundary node
>> does not uniquely identify a next-hop domain (even if it may be
>> successfully used for domain routing given the knowledge of the next
>> domain, next boundary node, or egress node) and the text should not
>> imply that it does. This is hidden at the end of 3.4 some time after the  
>> boundary node/link discussion.
>
> [Ramon] point taken. we will review the text accordingly.
>
>> Shouldn't you allow "loose" hops in the domain path? (i.e. gaps between
>> domains).
>
> I don't see any special reason why we shouldn't, although one concern I 
> have is how would this relate to RFC5440 statement "The L bit of such
> sub-object has no meaning within an IRO"?

Ah, my bad. As above, the original (type 1) IRO has no ordering or tightness of
sequencing. Thus, it is just a list of things to include.
 
*if* you stay with the type 2 IRO, and *if* you define ordering in the type 2
IRO (as currently written), then you need to consider the L bit.

>> Can I also mix other concepts with the domain path? What about a consistent
>> lambda, or a core node that needs to be on the path?
>
> [Ramon] IMHO, there are two (decoupled) points here:
>
> a) whether the current IRO has ordering constraints or not
>
> b) If a new IRO is needed whether only domain-related info is conveyed.
>
> An (authoritative ;-) ) answer for a) would be much appreciated.

Ask JP ;-)

My reading agrees with yours (and my memory) as above. The IRO is just a set of
objects to be included. Presenting the elements of the set in any order will
have the same result (plus or minus ECMP situations and peculiarities of
specific PCE implementations).

> There was also the concern of separating the roles of intra-domain path
> computation IRO and the resolution of PCEs in a collaborative setting. 

I'm not entirely sure I get this point. A PCE can only compute a path segment
that goes through its domain of responsibility - it will find all elements in
the IRO that it recognises as "local" and include them in the segment it makes,
and it will pass on all other elements to the other PCEs it cooperates with.
There is clearly a task for the "aggregating PCE" (which may be the head of the
chain, or may be the parent) to put the segments together according to the
complete IRO.

> For b), if we agree on the idea "the new object type imposes
> ordering constraints" I would not be against being like any other
> IRO. With a new IRO type we can be more concrete regarding the
> role of the must-process p-bit, what to do with unknown objects 
> (locally to a PCE) i.e., nothing is said in IRO and XRO objects what
> the procedures are when a sub-object is "not found" (in the TED?).

This seems to cut to a complexity question.
We could allow a PCC to specify as much or as little of the information about
the path as it likes. This is certainly fully flexible, but it seems to me to
masively over-complicate the protocol and the functional model. Isn't it the
case that the PCE is capable of selecting the *best* path. Thus, for example,
there is no need for the PCC to say "I want a continuous lambda for the segment
over domain X" because that implies the PCC knows stuff about domain X that the
PCE is unaware of.

> From the mail: "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
> similar"

That is a good question, and there are two sub-species of "unknown". The
processing collapses to the same behavior, but it is worth looking at them
separately.

1. I know the T value, but I can't find the identified resource
2. I don't know the T value.

In the first case, the PCE processes the IRO to include as many of the elements
of the IRO as possible. If the PCE is passing the request onwards, it is OK for
it to fail to find the resource, and it can assume that the next PCE might be
able to satisfy the remaining elements of the IRO. On the other hand, if the PCE
is making an end-to-end (or edge-to-edge, or end-to-edge) path and will return
the response to a PCC (rather than pass it on) then the PCE must fail if it
cannot satisfy the IRO (this failure behavior is in RFC 5440).

Now, I would hold that the second case can be handled identically to the first
case.

And ultimately, when the path segments are aggregated by a head-end PCE or by a
parent PCE, that PCE can check to see whether any elements of the IRO are still
missing. 

There is, just one wrinkle in that case which is that the aggregating PCE must
understand all of the T values, or the IRO must be stripped and returned on the
response messages.

>> In 3.5.7 I don't see that the domain sequence is necessarily an alternative
>> to the PCE sequence. There are cases where even with a domain sequence,
>> a PCE sequence is important.
>
> [Ramon] Personally, (although we still need to discuss it more) I don't see
> domain-sequence and pce-sequence as exclusive and I agree they can
> coexist. The whole 3.5.7 needs to be revisted, including J.P. comments
> during the meeting that some assertions were false (which is true, brpc
> may benefit from a domain sequence but does not require it)

Agrred

>> Section 5 will need loads of work because the domain sequence (even
>> for inclusion, not reporting) provides information valuable to an attacker.
>
>[Ramon] agreed.
>
> Thanks again,
> Ramon

Very welcome.
Most fun I have had all year :-)

Adrian