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 protected] [mailto:[email protected]] On Behalf Of JP Vasseur
Sent: 29 March 2012 17:30
To: [email protected]
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.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
