Subject: Fwd: Gen-art review of draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt

From: JP Vasseur <[email-masked]>
Date: Mon, 5 Nov 2007 14:38:32 -0500

Hi,

Many Thanks for the detailed review. See in line,

>> From: Elwyn Davies <[email-masked]>
>> Date: August 17, 2007 12:32:50 PM EDT
>> To: General Area Review Team <[email-masked]>
>> Cc: Mary Barnes <[email-masked]>, ccamp- 
>> [email-masked], [email-masked], IETF Discussion <[email-masked] 
>> >, JP Vasseur <[email-masked]>, [email-masked], [email-masked]
>> Subject: Gen-art review of draft-ietf-ccamp-inter-domain-pd-path- 
>> comp-05.txt
>>
>> I have been selected as the General Area Review Team (Gen-ART)
>> reviewer for this draft (for background on Gen-ART, please see
>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>>
>> Document: draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt
>> Reviewer: Elwyn Davies
>> Review Date: 16 Aug 2007 IETF LC End Date: 16 Aug 2007
>> IESG Telechat date: (if known) 23 Aug 2007
>>
>> Summary:
>> I think this document needs significant work on the core  
>> description of the algorithm.  I found s4 to be difficult to read  
>> and it appears to contain a number of ambiguities and  
>> inconsistencies that should be fixed before it goes to the IESG.   
>> The various sub-cases and routes through the algorithm are not very  
>> clearly expressed IMO. That being said, I think this is essentially  
>> a descriptive problem rather than any issue of principle. There are  
>> also a number of editorial issues (mostly need for acronym  
>> expansion) that need fixing in due course.
>>
>> Comments:
>> s3.1: To avoid the sense of surprise when a Path message appears in  
>> the last bullet, I would suggest s/The path (ERO)/The path  
>> (specified by an ERO in an RSVP-TE Path message)/
>>
>
> Fixed.
>
>> s4, para 2/3:  Presumably para 3 is talking about the 'next hop'  
>> being loose or abstract as is implied by items 1) and 2).  It would  
>> be good to make this clear.  It would also be worth inserting a  
>> sentence making it clear that if the next hop is strict there isn't  
>> anything to do, since otherwise one has to scan the entire section  
>> to verify that this is the case.  It is just possible that I have  
>> misunderstood what is going on and some of the stuff *does* apply  
>> to strict hops - in which case the section needs a whole lot more  
>> clarity.  There also needs to be some words about the 'simple  
>> abstract node' case.
>>
>
> You're absolutely right, this has been clarified.
>
>> s4: Sending of PathErr.  This section states that PathErr messages  
>> 'SHOULD be sent' in several places.  Whilst this is consistent with  
>> RFC 3209, both of these documents appear to be (or may be)  
>> inconsistent with RFC 2205 which does not appear to provide any  
>> alternative to sending a PathErr when there is a problem processing  
>> a Path message.  If it is deemed correct to allow not sending the  
>> PathErr, reasoning should be given as to why this might be  
>> desirable, and what is the alternative (presumably silently  
>> ignoring the message?) and its consequences.
>>
>
> As pointed out in the text, the sending of a Path Error message is  
> compliant with section 4.3.4 of RFC3209.
>
>> s4, item 1):  I think the first sentence ('If the next hop is not  
>> present in the TED.') is probably redundant and is certainly  
>> confusing.
>
> Indeed, we removed the redundant text, thanks.
>
>> Part of the confusion is that the rest of the item appears to only  
>> concern loose next hops but there is no pointer to what happens  
>> with the other case of abstract nodes.  I think the description  
>> would be more logical with the paragraph on abstract nodes, from  
>> later in the section, moved to before item 1).  In that way the  
>> case splitting (strict/loose/abstract) would be much clearer.  BTW  
>> doesn't the simple abstract case have to do some of the non-simple  
>> work?
>
> I see where the confusion came from. I added a paragraph clarifying  
> that s4 only applies to the case where
> the ERO contains a loose hop or a non simple abstract node (an  
> abstract node than identifies more than one
> LSR).
>
>>
>>
>> s4, item 1, bullet 2: Which domain has to be PSC?  The current one  
>> or the one containing the next hop?
>>
>
> The Next hop domain (text added).
>
>> s4, item 1: Worth making even clearer that *both* conditions have  
>> to be satisfied.
>
> Fixed.
>
>>
>>
>> s4, item 1: 'If the next-hop is reachable, then it SHOULD find a  
>> domain boundary LSR...': What does 'it' represent here?
>
> The "boundary LSR" (text fixed).
>
>> The path necessarily crosses the boundary (unless we have some very  
>> weird topology here ;-) ) so there is *something* on the domain  
>> boundary.  What else could it find on the boundary?  I think this  
>> is probably a badly expressed story about some other point.   
>> Reflecting on this, it strikes me that this is the key point where  
>> the routing information is pulled into the TE and this is very  
>> poorly expressed IMO.
>
> The point is in that case to find the boundary LSR: "If the next-hop  
> is reachable, then it SHOULD find a domain boundary LSR (domain  
> boundary point) to get to the next-hop. The determination of domain  
> boundary point based on routing information is what we term as “auto- 
> discovery” in this document."
>>
>>
>> s4, item 1: 'the ABR in the case of inter-area TE or the ASBR in  
>> the next-hop AS in the case of inter-AS TE should be the signaled  
>> loose next-hop in the ERO':  Does this mean in the expanded ERO or  
>> the original one?
>
> The original one.
>
>> If it is the original one, how is the implementor supposed to check  
>> it is an ABR/ASBR?
>>
>
> In the absence of auto-discovery, the user must indeed know and  
> configure all domain boundaries. If there is a succession
> of IGP areas and ASes for example, as pointed out in the text, the  
> ERO must contain all boundary nodes (ABRs/ASBRs).
>
>>
>> s4, item 2): The term 'ERO expansion' is not defined in any of the  
>> standards - it is referred to as an alternative shorthand in RFC  
>> 4736 (requirements doc).  It needs to be defined.
>
> It is actually defined in RFC 4736, but you're right that it should  
> also be mentioned here. We added some text.
> "an ERO expansion (process consisting of computing the constrained  
> path up to the next loose hop and add the list of hops as strcit  
> nodes in the ERO)"
>
>>
>>
>> s4, item 2), bullet 1: This section contains 3 instances of  
>> 'SHOULD'.  I am happy with the first one (policy applies).  The  
>> third one is covered by the discussion on PathErr above.  The  
>> second 'SHOULD' strikes me as a 'should' or even 'is'.  What else  
>> would be done if it isn't treated this way?  Bullet 2, sub-bullet 1  
>> has a similar construction.
>
> Very good point indeed. "If no path satisfying
>       the set of constraints can be found, then this SHOULD be treated
>       as a path computation and signaling failure "
>
> is actually non appropriate and should read "If no path satisfying
>       the set of constraints can be found, then this is treated
>       as a path computation and signaling failure "
>
>>
>>
>> s4, item 2), bullet 2, sub 1: The condition at the beginning of  
>> this bullet could probably be written down more clearly.
>>
>
> If OK with you we kept the text unchanged since the terminology  
> matches with the other companion draft (ccamp-inter-domain-rsvp-te)
>
>> s4, item 2), bullet 2/sub 1: 'If the boundary LSR is a candidate  
>> LSR for intra-area H-LSP/S-LSP setup (the LSR has local policy for  
>> nesting or stitching),...': Which LSR has the policy?  The boundary  
>> LSR or the one asking? There is an equivalent question for sub  
>> bullet 2.
>>
>
> Right - The "boundary LSR" (text added in both places).
>
>> s4, para after item 2): 'Note that in both cases, path computation  
>> and signaling process may be stopped due to policy violation.':  
>> Does this mean some other policy violation than is already  
>> documented?  If not I think this para should be removed as it it  
>> just raises doubts as to whether there is some other cause.
>
> You're right, text removed.
>
>>
>>
>> s4, 'optimization technique':  I am confused about what protocol  
>> instance would accept the proposed flooded information if the IGP  
>> is not running on the inter-AS link concerned.  Does this require  
>> some special functionality in the IGP?
>
> This is because it is carried as a non routing information. The TE  
> link is advertised by the IGP using
> an opaque LSA in OSPF and TE TLV in IS-IS. Thanks to local  
> configuration, the IGP only advertises
> the Inter-ASBR link as a TE link even if there is no routing  
> adjacency over that link. Note that there are
> implementations supporting that mode.
>
>>
>>
>> ss4.1/4.2: I believe that each of the examples references one or  
>> other of the Figure 1/2 configurations - this should be made clear  
>> explicitly.
>>
>
> Right, text added.
>
>> s4.1.1, para 4: Although it is not strictly normative, harder  
>> advice should be given on back-off times to avoid DoS/congestion.
>>
>
> As you pointed out, this section is clearly not normative and the  
> security aspects are being addressed separately.
>
>> s5: The 'tapping' problem may be well-known but not to me.  It  
>> needs either a brief explanation or a reference.
>
> OK I added an example.
>
>>
>> Editorial:
>>
>> Abstract: Expand IGP acronym (and add to terminology?).
>
> Done.
>
>>
>>
>> s2, para 4: The term Head-end is not defined.
>
> Text added: "LSR that inititiated the TE LSP"
>>
>>
>> s3.1, bullet 3: Expand ERO acronym.
>
> Fixed + added to the terminology section.
>
>>
>> s3.1: To avoid the sense of surprise when a Path message appears in  
>> the last bullet, I would suggest s/The path (ERO)/The path  
>> (specified by an ERO in an RSVP-TE Path message)/
>
> Done.
>
>>
>>
>>
>> s3.2: Expand ABR
>> s3.2: Expand ASBR
>
> Done.
>
>>
>> s3.2, Figure 2: s/(CE to ASBR =>/(CE to ASBR) =>/
>
> Fixed
>
>>
>> s3.2, last bullet: This contains no verb!  The bullet could  
>> (usefully) say: 'The scenario supports an inter-AS TE LSP...'.   
>> This bullet might logically appear as the 2nd on the list.
>
> I see a verb here ...
>
>  - The example depicted in Figure 1 shows the case where the Head-end
>      and Tail-end areas are connected by means of area 0.  The case of
>      an inter-area TE LSP between two IGP areas that does not transit
>      through area 0 is not precluded.
>
>>
>>
>> s5, para 3: A reference to s2 would help.
>
> Not sure why/where ?
>
>>
>>
>> s6.1: A reference to how/where the Make-before-Break procedure is  
>> defined would be good (RFC3209?).
>>
>
> Added, thanks.
>
>> s8: Expand FRR, MP and PLR acronyms.
>>
>
> Done + reference added.
>
>> s9, para 2: s/verison/version/
>>
>>
>
> Many Thanks again.

Here are the Diffs.

New text.

Many Thanks.

JP.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf