Chair review of draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

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

===