Hi,
As promised, I have done a review of this I-D to help the authors
prepare it
for WG last call. In my opinion, the draft is in pretty good shape,
but
there are a few minor issues.
If the authors can submit a new version to address these comments
and those raised on the list resently, we can
take the I-D forward.
Thanks,
Adrian
===
Authors' details.
Need to update Arthi's contact details.
===
Boilerplate
Need the new IETF Trust boilerplate
===
Intended status
Why is this Standard Track?
Seems to me that there are no protocol extensions in this I-D, and
no procedures that are dependent on interoperability.
In fact, I am not comfortable with the use of 2119 language in this
I-D since the choice seems to be available per-domain and per-LSP.
===
Page headings
Draft name is not complete
===
Terminology
s/ABR Router/ABR/
s/ASBR Router/ASBR/
Need to add "AS" to your list. (So says the RFC Editor).
===
Section 3.1 has
The paths for the intra-domain Hierarchical LSPs (H-LSP) or S-LSPs
(S-LSP) or for a contiguous TE LSP
s/S-LSPs (S-LSP)/Stitched LSPs (S-LSPs)/
===
Section 4
In this section the text sometimes is exclusive to "area", although
sometimes you do describe "area or AS".
You do not want to give the impression that the cases where you
only mention "area" do not apply to "ASes", but you also probably
don't want the text to be clumsy with having to reference both
cases every time. Consider using "domain" to include both cases.
===
Section 4 paragraph 3
You have...
When an LSR (e.g. a boundary node such as an ABR/ASBR) receives a
Path message with an ERO that contains a loose hop or an abstract
node that is not a simple abstract node (that is, an abstract node
that identifies more than one LSR), then it MUST follow the
procedures as described in [I-D.ietf-ccamp-inter-domain-rsvp-
te]. In
addition, the following procedures describe the path computation
procedures that SHOULD be carried out on the LSR:
But this is not true!
I-D.ietf-ccamp-inter-domain-rsvp-te specifically describes
procedures at domain border nodes.
You can fix your text by changing the first line to read...
When an LSR that is a boundary node (e.g. an ABR or ASBR) receives a
===
Section 4 procedures
This text would benefit from some careful indentation to make it
easier to see how the cases are nested.
Case 1.
I think it is important to understand that an LSR that find the
next loose hop to be absent from its TED does not know that that
hop refers to a boundary node. Indeed, it might refer to the
destination or to an AS number.
So the point here is that the next hop is not in the TED, and the
LSR must determine the domain exit boundary node to use to route
toward the next loose hop.
===
Throughout
s/PErr/PathErr/
===
Section 4 Case 2) b) i)
This case should point out that, in addition to local policy, the
signaling information described in I-D.ietf-ccamp-inter-domain-rsvp-
te can control whether an LSP is a candidate for hierarchy or
stitching.
===
Section 4
You have...
The links interconnecting ASBRs are usually not TE-enabled and no
IGP
is running at the AS boundaries. An implementation supporting
inter-AS MPLS TE MUST allow the set up of inter-AS TE LSP over the
region interconnecting multiple ASBRs. In other words, an ASBR
compliant with this document MUST support the set up of TE LSP over
inter-ASBR links and MUST be able to perform all the usual
operations
related to MPLS Traffic Engineering (call admission control, ...).
This use of "MUST" is in contradiction with previous text that says
LSRs MAY reject LSPs if they don't want to use the "auto-discovery"
mechanisms. It also seems to be a violation of an administration's
policy options.
===
Section 5
s/does no meet/does not meet/
===
Section 6
The ability to reoptimize an already established inter-domain TE LSP
constitutes a requirement.
Can you give a reference for the requirement?
===
Section 6.2
You have...
Note that stitching or nesting rely on local optimization: the
reoptimization process allows to locally reoptimize each TE S-LSP or
H-LSP: hence, the reoptimization is not global and consequently the
end-to-end path may no longer be optimal should it be optimal when
being set up.
This text contradicts the previous paragraph!
I think that what you are trying to say is something very different
and should probably be in its own section, "End-to-end
Reoptimization".
It is possible that a more optimal end-to-end path will arise that
cannot be achieved by local reoptimization solely within a domain.
For example, the new, more optimal path may require the use of
different domain border nodes, or even the selection of different
domains.
Such situations cannot usually be detected by the individual domains
on the existing path, and so they cannot be reported to the head-end
LSR. They certainly cannot be fixed by local optimization of H-LSPs
or S-LSPs within any one domain.
These scenarios can only be resolved by new end-to-end signaling
with
new path computation, and the use of make-before-break to establish
the new LSP and switchover traffic with minimal disruption. New end-
to-end signaling works with all three methods of inter-domain LSP
setup.
===
The security section here looks very light.
I think you could do with explaining that this process for
establishing paths does not increase the information exchanged
between ASes and preserves topology confidentiality.
But there are three aspects that remain open:
1. A downstream AS could "fail" to route an LSP because it does not
like one of the downstream ASes in the ERO.
2. A downstream AS could choose to route the LSP on an unfavorable
path because it doesn't like the source or destination.
3. A downstream AS could choose to route the LSP through an AS that
is not listed in the ERO, perhaps for financial reasons.
So, some discussion is needed. Perhaps all you need to say is that:
- pd-path assumes commercial arrangements between peered ASes
and probably between source AS and all transit ASes
- pd-path is at least as good as pre-existing techniques
- greater path control can be achieved by using more complex
computation
techniques
- there is a fundamental trust relationship at AS borders that must be
assumed in order to have inter-AS traffic.
You can also forward-reference Luyuan's MPLS-TE security work.
===
References
Update I-D.ietf-ccamp-inter-domain-framework to RFC 4726
The IESG are now quite exercised by down-refs in I-Ds. As a result,
I suggest that you move RFC2702 to the Informative References section.
Remove the reference to I-D.ietf-ccamp-inter-domain-pd-path-comp
from the Informative References section.
I-D.ietf-pce-architecture is now RFC 4655
===