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

From: Elwyn Davies <[email-masked]>
Date: Fri, 17 Aug 2007 17:32:50 +0100

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

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.

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.

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

s4, item 1, bullet 2: Which domain has to be PSC?  The current one or the one containing the next hop?

s4, item 1: Worth making even clearer that *both* conditions have to be satisfied.

s4, item 1: 'If the next-hop is reachable, then it SHOULD find a domain boundary LSR...': What does 'it' represent here? 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.

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?  If it is the original one, how is the implementor supposed to check it is an ABR/ASBR?

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.

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.

s4, item 2), bullet 2, sub 1: The condition at the beginning of this bullet could probably be written down more clearly.

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.

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.

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?

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.

s4.1.1, para 4: Although it is not strictly normative, harder advice should be given on back-off times to avoid DoS/congestion.

s5: The 'tapping' problem may be well-known but not to me.  It needs either a brief explanation or a reference.
 
Editorial:

Abstract: Expand IGP acronym (and add to terminology?).

s2, para 4: The term Head-end is not defined.

s3.1, bullet 3: Expand ERO acronym.
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)/

s3.2: Expand ABR
s3.2: Expand ASBR
s3.2, Figure 2: s/(CE to ASBR =>/(CE to ASBR) =>/
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.

s5, para 3: A reference to s2 would help.

s6.1: A reference to how/where the Make-before-Break procedure is defined would be good (RFC3209?).

s8: Expand FRR, MP and PLR acronyms.

s9, para 2: s/verison/version/

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

---

From: JP Vasseur <[email-masked]>
Date: Fri, 17 Aug 2007 17:09:56 -0400

Hi,

On Aug 17, 2007, at 5:06 PM, BRUNGARD, DEBORAH A, ATTLABS wrote:

> Much thanks Elwyn -
>
> JP - I scanned quickly and they seem to be fair comments - very  
> helpful
> as another perspective. The fixes look to be largely descriptive
> clarifications and editorial. Can you handle the updates on this
> document when the rest of the IESG comments have been received?
>

I surely will.

Thanks.

JP.

> Deborah
>
> -----Original Message-----
> From: Elwyn Davies [mailto:[email-masked]]
> Sent: Friday, August 17, 2007 12:33 PM
> To: General Area Review Team
> Cc: Mary Barnes; [email-masked]; ccamp- 
> [email-masked];
> IETF Discussion; JP Vasseur; [email-masked];
> [email-masked]
> Subject: Gen-art review of
> draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt
>
> 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)/
>
> 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.
>
> 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.
>
> 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.
> 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?
>
> s4, item 1: Worth making even clearer that *both* conditions have  
> to be
> satisfied.
>
> s4, item 1: 'If the next-hop is reachable, then it SHOULD find a  
> domain
> boundary LSR...': What does 'it' represent here? 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.
>
> 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?  If it is the original one, how is the implementor
> supposed to check it is an ABR/ASBR?
>
>
> 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.
>
> 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.
>
> s4, item 2), bullet 2, sub 1: The condition at the beginning of this
> bullet could probably be written down more clearly.
>
> 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.
>
> 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.
>
> 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?
>
> 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.
>
> s4.1.1, para 4: Although it is not strictly normative, harder advice
> should be given on back-off times to avoid DoS/congestion.
>
> s5: The 'tapping' problem may be well-known but not to me.  It needs
> either a brief explanation or a reference.
>
> Editorial:
>
> 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)/
>
>
> s3.2: Expand ABR
> s3.2: Expand ASBR
> 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.
>

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Fri, 17 Aug 2007 16:06:18 -0500

Much thanks Elwyn -

JP - I scanned quickly and they seem to be fair comments - very helpful
as another perspective. The fixes look to be largely descriptive
clarifications and editorial. Can you handle the updates on this
document when the rest of the IESG comments have been received?

Deborah

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]] 
Sent: Friday, August 17, 2007 12:33 PM
To: General Area Review Team
Cc: Mary Barnes; [email-masked]; [email-masked];

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

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.

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.

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

s4, item 1, bullet 2: Which domain has to be PSC?  The current one or
the one containing the next hop?

s4, item 1: Worth making even clearer that *both* conditions have to be
satisfied.

s4, item 1: 'If the next-hop is reachable, then it SHOULD find a domain
boundary LSR...': What does 'it' represent here? 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.

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.

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.

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?

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.

 
Editorial:

s3.1, bullet 3: Expand ERO acronym.
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)/

s3.2: Expand ABR
s3.2: Expand ASBR

s6.1: A reference to how/where the Make-before-Break procedure is
defined would be good (RFC3209?).