Subject: [Gen-art] Gen-ART LC review of draft-ietf-ccamp-inter-domain-rsvp-te-06.txt

From: "Eric Gray (LO/EUS)" <[email-masked]>
Date: Thu, 16 Aug 2007 11:56:22 -0500

Authors,

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: Inter domain Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions
(draft-ietf-ccamp-inter-domain-rsvp-te-06.txt)

Reviewer: Eric Gray

Review Date:  August 16, 2007

IETF LC End Date: August 16, 2007

IESG Telechat date: (if known) Unknown.

Summary:
=======

This document is not ready for publishing as a Proposed Standard.
Some points require clarifications.

Comments:
========

The following paragraph (section 2) seems inconsistent with the
text in subsequent sections: it seems that it is saying that any
combination of the three methods (contiguous, nested, stitched)
could be used in a _single_ LSP - yet at least on of these is 
defined as "end-to-end" in subsequent text (contiguous).  That
would seem to imply that any combination except contigous and
either of the other two.

The paragraph reads:

"In fact, as pointed out in [RFC4726], any combination of these three
options may be used in the course of an end-to-end inter-domain LSP."

Yet the subsequent text describing "Contiguous" says "a single
end-to-end TE LSP ..."

Possibly a careful read should be made to remove innappropriate 
uses of the words "end-to-end" in connection with each method?

For example, in the cited case above, simply removing "single
end-to-end" in the description of contiguous should remove the
ambiguity in that case.

Alternatively, assuming that it is actually the case that - for
a contiguous LSP - the intent is that it be truly end-to-end,
then the original statement above needs to be modified.

Finally, if it is fact the intent that the selection method is
supposed to apply to any given LSP - on an end-to-end basis -
then the quoted statement above should be removed entirely.
--------------------------------------------------------------------
Still related to the above, but as a side note, the fact that it 
is not immediately clear which of these is the intention in this 
document is an indication of a potential for some very serious 
interoperability issues.  Some of the subsequent text mentions 
the potential for a "policy failure" that SHOULD fail the setup.  

In addition to not being absolutely clear (when would it be okay
not to fail, is there a way to indicate that an alternative is
allowed, etc?), this implies that it is possible for a domain to
have a policy (for example, against contiguous LSP setup) that is
going to result in complete non-interoperation with a domain (or
implementation) asking for contiguous LSP setup.

This sort of policy conflict may easily arise if one implementer,
or operator, interprets the specification one way and another (or
others) interprets it another in terms of expected "end to end" 
behavior and combinations of the types of "spanning" LSPs. 
---------------------------------------------------------------------
The last two paragraphs in section 2 (preceding the heading for
section 2.1) are confusing and (potentially) contradictory: one
appears to say that signaling extensions (for control/selection
of methods) are in scope while specific details are not, but the 
other seems to say otherwise.

I suspect that the word "control" is where I am getting hung-up.
If it is intended that the specifics of each method are out of
scope in this document - once a method is selected - then it is 
hard to see how "control [...] of the three signaling mechanisms"
is in scope but "specific protocol extensions required to signal 
each LSP type" is not.

Perhaps "control and" should be removed?
----------------------------------------------------------------------
In section 3, under bullet 4a - on page 6 - you use "SHOULD" in
saying whether or not a PathErr message is to be generated.  Why
- or under what circumstances - would it be appropriate not to do
so?
----------------------------------------------------------------------
Similarly, on page 7, you use the word SHOULD with respect to ERO
processing in a Path message.  When (or under what circumstances)
would it make sense not to do as specified?  What alternatives are
there?

This same observation then applies to several (all?) of the actual
procedures - although several of them do provide some degree of
amplification as to when (or why) a specific step might not apply.

Perhaps it would be best to clarify in the steps themselves and -
rather than say "SHOULD" in the introductory statement, it might
be enough to simply say that the following procedures apply (thus
avoiding the issue of using either SHOULD or MUST).
----------------------------------------------------------------------
After "However:" in section 3.2, I would suggest some form of 
modification or qualification of the first bullet similar to:

- A domain border node MUST NOT passively suppress propagation 
  of a PathErr message.

Clearly, if the device applies a successful crankback approach, 
it does not make sense for it to propagate the PathErr anyway.
----------------------------------------------------------------------
In the third bullet of section 7, page 15, "do not need to be 
considered" does not follow from "are likely to be upgraded".

True - if they are upgraded - then they are unlikely to need
to be considered in backward compatibility discussion.  But
"likely to be" is NOT the same as "are".

The point I think you are trying to make is that upgrading a
border LSR to include this capability is an essential enabling
requirement for useful operation of this capability - and that 
makes it unnecessary to consider such upgraded border LSRs in
backward compatibility.

======================================================================
NITs:

In section 1.2, page 3, the definition for ASBR should start with
an expansion of the acronym.
----------------------------------------------------------------------
In section 3.1, as currently formatted, the "factors including:"
seems to be "Farrel, Ayyangar and Vasseur" - an artifact of the 
way that your document only has a single empty text-line between
the last line of content-text and the page footer.  This is only
a problem when reading the electronic version and - most likely -
a (humorous) temporary problem that will fall out in subsequent 
versions.  If not, it might be a good idea to force the line with
a colon ending it to not orphan the next line of content-text.

In the version I read, this occurs at the bottom of page 6.
-----------------------------------------------------------------------
On page 14, second paragraph, I suggest changing "ingress LSP" to
"LSP ingress".  An LSP - however qualified - cannot "exert control".
-----------------------------------------------------------------------
First line in section 7, existing rather than esiting.
-----------------------------------------------------------------------
Last line of the first bullet in section 7 (page 15, roughly mid
page) - inter-domain rather than inte-domain.
-----------------------------------------------------------------------
Third line of third bullet (in section 7), controls verses conrols.
-----------------------------------------------------------------------
Third line of second paragraph (in section 8, page 15), suitable
instead of suiable.

--
Eric Gray
Principal Engineer
Ericsson 

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Aug 2007 19:52:52 +0100

Hi Eric,

Many thanks.

> defined as "end-to-end" in subsequent text (contiguous).

[SNIP]

Point taken.

What we were trying to convey is that, domain by domain, you may apply any 
one of the techniques.

We can re-work this text to make it clearer and possibly include a (rather 
trite) example.

The ability to fail to interoperate at the domain level is intended to be an 
operator choice. If, for whatever reason, the operator only wants to allow 
one of the mechanisms, and the ingress domain insists on another mechanism, 
then it is important to provide for the rejection of the LSP setup.

The most obvious (to me) example, is that an ingress may request a 
contiguous LSP because it wishes to exert maximal control over the LSP's 
path and (in particular) to control when re-optimization takes place. OTOH, 
the operator of a transit domain may decide that only (for example) LSP 
stitching is allowed for exactly the reason that it gives the operator the 
chance to reoptimize their own domain under their own control. Now there is 
a stand-off. The ingress operator has a choice:
- find another path
- relax his requirements
- fail to provide the service.

But the point about implementation is more important.
The choice is not very functional if the ingress LSR is not able to support 
all modes. Fortunately, that is easy to implement (it is only a flag).
The choice is, however, fully functional if the LSRs at the borders of the 
transit domain only support one mechanism (since that must be the mechanism 
that the domain operator is deploying).

We can clarify this choice, but I don;t believe any functional change is 
required.

I think the issue is with the associativity of "and".

We mean:
   This document describes the RSVP-TE signaling extensions
   required to control which of the three signaling mechanisms
   is used and to select which of the three signaling mechanisms
   is used.

I agree that "control and" is superfluous.

Hmmm. RFC 3209 includes a variety of reasons to generate a PathErr carrying 
the "Routing Problem" error. Some of these are related to path computation 
failure (including next hop selection), and the referenced text relates to 
path computation failure. We do not feel that we can redefine (or justify!) 
the behavior described in RFC 3209. In addition, the referenced I-D 
([INTER-DOMAIN-PD-PATH-COMP], also describes this behavior - and needs to be 
fixed to include why this is a "MAY".

My opinion is that at a domain boundary we should make the same 
considerations as in RFC 4208 sections 3.1 and 3.2 (note the error in 3.2 
with lower case "should"). The reasoning here, I believe, is that a Path 
message could be interpretted as a network probe, and a PathErr provides 
information about the network capabilities and policies. Therefore, it may 
be an administrative/security policy to not send a PathErr under certain 
routing failure conditions.

We should clarify this six (count them!) ways:
- reference to 3209
- reference to [INTER-DOMAIN-PD-PATH-COMP]
- explanation of when an application MAY decide to not send PathErr
- text in the security section
- explanation in [INTER-DOMAIN-PD-PATH-COMP] of when an
  application MAY decide to not send PathErr
- text in the security section of [INTER-DOMAIN-PD-PATH-COMP]

I think that the numbered paragraphs need to be updated as:
1. first SHOULD -> MUST; second SHOULD remains with added explanation
2. SHOULD -> MUST
3. SHOULD remains with added explanation
6. SHOULD remains with added explanation

The changes of SHOULD to MUST need consultation with my co-authors and with 
the WG.

> avoiding the issue of using either SHOULD or MUST).

I agree. The meta-paragraph (before the numbered points) doesn't make sense 
since "SHOULD do a MUST" is meaningless. We should drop the 2109 language 
from that text.

> it does not make sense for it to propagate the PathErr anyway.

OK. This was obviously not sufficiently clear.
It was meant to imply that the PathErr must
- either be propagated
- or dropped because some other action has been applied
In other words, a PathErr must not simply be dropped according to policy, 
whim, or misadventure.
(Actually, misadventure can occur because of the nature of IP :-)

We can try to expan the text to make "passively suppress" less opaque.

Yes, that is exactly the point.
Of course, it is possible that someone will try to exercise the function 
without upgrading the domain border LSRs, but then it wouldn't work, and is 
not expected to work.

We will try to polish the text.

> NITs:

[SNIP]

> In the version I read, this occurs at the bottom of page 6.

How do you know this is not how we intended it to be read?

[SNIP]

Very many thanks.
Adrian

---

From: "Eric Gray (LO/EUS)" <[email-masked]>
Date: Thu, 16 Aug 2007 14:31:56 -0500

Adrian,

	As a further clarification on one point...

...

Just to be clear, "passively" was what I added in the suggested 
example of how to "fix" the problem.

>From what you say, it is not the intention that the domain border
LSR should be allowed to drop the PathErr without taking some sort
of action - hence my suggestion to add "passively".  However, that
doesn't seem to clear it up enough.

I felt that the statement does not need too much improvement since
the example of holding the PathErr while the boundary LSR tries an
alternative (or two) follows very shortly after the statement.  So,
I was suggesting adding a weak qualifier to keep from implying that 
the PathErr MUST be forwarded under all circumstances - only to 
follow shortly with an example of when it might make sense to not 
do so.

If the example clearly said that - on subsequently succeeding - the
initial PathErr would (clearly) not need to be propagated, then I
would have ignored the previous statement (even though still a bit
inconsistent).