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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 4 Feb 2007 11:52:18 -0000

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

===

---

From: JP Vasseur <[email-masked]>
Date: Sun, 4 Feb 2007 10:17:10 -0500

Thanks Adrian, will be done this week.

Cheers.

JP.

On Feb 4, 2007, at 6:52 AM, Adrian Farrel wrote:

> 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.
>
> 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
>
> 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...
>
> I-D.ietf-ccamp-inter-domain-rsvp-te specifically describes  
> procedures at domain border nodes.
> 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...
>
> 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
>
> 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".
>
> 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.
>
> 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.
>
> 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.
>

---

From: JP Vasseur <[email-masked]>
Date: Wed, 7 Feb 2007 09:55:06 -0500

Hi Adrian,

> and those raised on the list resently, we can

Thanks for the detailed review - See in line,

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

> cases every time. Consider using "domain" to include both cases.

OK

>   When an LSR that is a boundary node (e.g. an ABR or ASBR) receives a

Done.

> easier to see how the cases are nested.

Added.

> toward the next loose hop.

Agreed but I think that this is clearly spelled out ?

> te can control whether an LSP is a candidate for hierarchy or  

Excellent point, indeed. Thanks. Text added to both i) and ii).

> mechanisms. It also seems to be a violation of an administration's  

mmm ... this is orthogonal to the auto-discovery mechanisms. That  
said, the text states the obvious, text removed.

> Can you give a reference for the requirement?

Yes in RFC4216 and RFC4105 (references added).

>   different domain border nodes, or even the selection of different

Yes this is what is meant by "the reoptimization is not global".

>   to-end signaling works with all three methods of inter-domain LSP

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

> between ASes and preserves topology confidentiality.

Yes.

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

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

> Update I-D.ietf-ccamp-inter-domain-framework to RFC 4726

Done, thanks.

> I suggest that you move RFC2702 to the Informative References section.

Indeed, thanks.

> from the Informative References section.

Nice loop ;-)

> I-D.ietf-pce-architecture is now RFC 4655

Let me know if we're in sync and I'll publish the new updated revision.

Thanks.

Cheers.

JP.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 7 Feb 2007 18:01:01 -0000

Hi JP,

Thanks for this. Cut down to just a few comments in line.

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

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.

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

>> paths does not increase the information exchanged  between ASes and 
>> preserves topology confidentiality.
>
> Yes.
>
>> 1. A downstream AS could "fail" to route an LSP because it does not  like 
>> one of the downstream ASes in the ERO.
>> 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.

> 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

---

From: JP Vasseur <[email-masked]>
Date: Tue, 20 Feb 2007 10:26:22 -0500

Hi Adrian,

We're in sync, I have incorporated your comments and fleshed out the  
security section (re used some text from draft-ietf-ccamp-inter- 
domain-rsvp-te) + text related to the policy during ERO expansion.

Thanks for the comments.

JP.

On Feb 7, 2007, at 1:01 PM, Adrian Farrel wrote:

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