Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Mar 2012 23:11:41 +0100

Please accept this comment as an individual comment like all the rest.
 
I have some reservations about adopting this document as a WG draft, but will
not register to stand in its way.
 
I understand the motive for this work and, indeed, it fills a hole in the
protocol spec.
 
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?
 
Here are some comments based on a very light review. I should probably read the
document properly some day.
 
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, wen 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.
 
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
 
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.
 
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.
 
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
 
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.
 
Shouldn't you allow "loose" hops in the domain path? (i.e. gaps between
domains).
 
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?
 
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.
 
In 3.5.7 you have:
      All PCE must be aware of all other PCEs in all domain for PCE-
      Sequence.
This is false. Although it is true that a PCE in one domain must be able to
route to the IP address of a PCE in a neighboring domain. 
 
In 3.5.7 you have:
      There maybe multiple PCE in a domain, the selection of PCE should
      not be made at the PCC/PCE(1).  This decision is made only at the
      neighboring PCE which is aware of state of PCEs via notification
      messages
There are four points here:
1. These are unsubstantiated assertions rather than reasons.
2. All neighboring PCEs are sending each other notification messages?
3. PCE choice may be based on capabilities, not just being up
4. In HPCE, it is quite reasonable for the parent to select the children
 
Section 5 will need loads of work because the domain sequence (even for
inclusion, not reporting) provides information valuable to an attacker.
 
I am sure the management considerations can be added within the WG process.
 
Thanks,
Adrian

From: [email-masked] [mailto:[email-masked]] On Behalf Of JP Vasseur
Sent: 29 March 2012 17:30
To: [email-masked]
Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG
 
Dear all,
 
We had a pretty strong support for adopting
draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG
meeting but
as usual we'd like to confirm on the mailing list.
 
Could you please let us know if you are in favor/opposed to adopting
draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ?
 
Thanks.
 
JP and Julien.

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 30 Mar 2012 11:14:04 +0200

Dear Adrian, 

Thanks for your comments. Please find response inline. 

Regards,

Dhruv

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian
Farrel
Sent: Friday, March 30, 2012 12:12 AM
To: 'JP Vasseur'; [email-masked]
Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new
PCE WG

I have some reservations about adopting this document as a WG draft, but
will not register to stand in its way.

[Dhruv Dhody] We will discuss among the co-authors and WG chairs on this. 

Here are some comments based on a very light review. I should probably read
the document properly some day.

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, wen 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.

[Dhruv Dhody] We did try to make sure to reuse already defined subobjects
but found some gaps which were handled in our document. RFC 4920 defines TLV
that can be carried in IF_ID ERROR_SPEC Object to specify the AS and area,
but using the TLV as a subobject breaks the definition of IRO Object.   

[Dhruv Dhody] zhang-pce-hierarchy-extensions provide this information as TLV
where we define the information in subobjects format. There is an editor
note in the draft in section 3.1.3 stating this. We are working closely with
HPCE authors and would make sure to avoid overlaps and redefinations. 

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.

[Dhruv Dhody] Dully Noted. 

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.

[Dhruv Dhody] We added a new type in this revision after discussion within
the WG (http://www.ietf.org/mail-archive/web/pce/current/msg02580.html) for
following reasons - 

Better application of rules w.r.t domain sequence

- define clear order of SubObjects

- Different Scope within IRO

- Clear Mode of Operations and handling

The algorithm in 3.4:

   its neighboring domains

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.

[Dhruv Dhody] We will refine the algorithm and text to make sure above
points are considerd. 

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.

In 3.5.7 you have:

      Sequence.

In 3.5.7 you have:

      messages

[Dhruv Dhody] We would refine this section to clearly state that both
PCE-Sequence and Domain-Sequence can co-exist. But there are some benefits
in using domain-sequence esp when such a thing needed to be configured at
PCC. 

[Dhruv Dhody] Dully Noted! 

Thanks,

Adrian

From: [email-masked] [mailto:[email-masked]] On Behalf Of JP
Vasseur
Sent: 29 March 2012 17:30
To: [email-masked]
Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE
WG

Dear all,

We had a pretty strong support for adopting
draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE
WG meeting but

Thanks.

JP and Julien.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 30 Mar 2012 13:15:48 +0200

Hi,

Many Thanks Adrian - Authors, could you please address the points listed below ?

Thanks.

JP.

On Mar 30, 2012, at 12:11 AM, Adrian Farrel wrote:

> I have some reservations about adopting this document as a WG draft, but will not register to stand in its way.
>  
> I understand the motive for this work and, indeed, it fills a hole in the protocol spec.
>  
> 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?
>  
> Here are some comments based on a very light review. I should probably read the document properly some day.
>  
> 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, wen 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.

>  
> 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
>  
> 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.
>  
> 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.
>  
> The algorithm in 3.4:
> 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.
>  
> Shouldn't you allow "loose" hops in the domain path? (i.e. gaps between domains).
>  
> 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?
>  
> 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.
>  
> In 3.5.7 you have:
> This is false. Although it is true that a PCE in one domain must be able to route to the IP address of a PCE in a neighboring domain.
>  
> In 3.5.7 you have:
> Section 5 will need loads of work because the domain sequence (even for inclusion, not reporting) provides information valuable to an attacker.
>  
> We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but
> Could you please let us know if you are in favor/opposed to adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ?
>  
> Thanks.
>  
> JP and Julien.

---

From: Ramon Casellas <[email-masked]>
Date: Sat, 31 Mar 2012 11:27:24 +0200

> Many Thanks Adrian - Authors, could you please address the points 

Adrian, JP, all

Thank you for your review and comments. They do indeed point out areas 
that need substantial work.

Please find inline my thoughts, in addition to the ones Dhruv sent. 
Sorry for the length of the mail and my tendency to be too verbose...

>> I have some reservations about adopting this document as a WG draft, 
>> but will not register to stand in its way.
[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.)

>> deployment. If not, would they please consider whether it should be 
[Ramon] I have no objection at being experimental, what option the WG 
things more appropriate is fine for me.

>> contained in RFC 5440. In my opinion the authors of 5440, and the WG 
>> at the time, wen 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

[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

>
>> It is also worth noting how 4920handles 2 and 4 octet AS numbers and 
>> that there is overlap in the definition of AS number subobjects with 
[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)

[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.

>> 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.

>> 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?

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.

>> - assumes that a PCE knows at least one PCE responsible for each of
[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.

>> 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 
>> theboundary 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 
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"?

>> 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. There 
was also the concern of separating the roles of intra-domain path 
computation IRO and the resolution of PCEs in a collaborative setting. 
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?). 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"

>> 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)

>> 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