Hi JP, Thanks for this. Cut down to just a few comments in line.
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.There are pros/cons but if you prefer, no objection to follow the Informational track, but I think that we should still keep 2119.
OK. You can do that. You should add a note to the 2119 paragraph that says something like...Although this is not a protocol specification, in order to clearly state the behavior of a router that performs per-domain path computation, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
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.Agreed but I think that this is clearly spelled out ?
The title of the case is: 1) If the next hop boundary LSR is not present in the TED. This should read: 1) If the next hop is not present in the TED.
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.Yes this is what is meant by "the reoptimization is not global".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.I see your point, this might be confusing. I could either add another paragraph or preferably I suggest to remove the note (which is probably the best option).
Yes. Either add some text like what I wrote, or remove the note that confuses.
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.Yes.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.Right, this is in fact all covered by the Policy aspects (added some text in section 3.1).
That is kind of OK, but the Security review will probably mainly read the Security section. So at least point to the text in 3.1 from a short paragraph explaining that there are concerns but they are covered in another section.
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.I'm not sure that we need to start such a discussion about Inter- Provider business model; I'd prefer to keep our focus on the technical issue. Does that make sense ?
Having had to shepherd a few I-Ds through IESG review recently I want to do everything possible to make he security sections water-tight. The alternative (which is currently very attractive) is to pass the buck to the I-D editors and get them to "negotiate" with the IESG.
I guess I am strongly advising you to put some more meat (sorry to all veggies) into this section. You can choose not to, but I think the I-D will get stuck in IESG review if you don't.
Thanks,Adrian