Subject: Re: WG last calls

From: Kireeti Kompella <[email-masked]>
Date: Fri, 1 Apr 2005 09:02:22 -0800 (PST)

On Thu, 31 Mar 2005, Kireeti Kompella wrote:

> This is to initiate CCAMP WG last calls on:
>
> draft-ietf-ccamp-crankback-04.txt

<WG chair hat on>

While this document is well-written and fairly comprehensive, it is
missing an important section.  While it has been claimed that the
moral pedigree of the editor places his writings beyond question, the
said editor is also a WG chair, and as such MUST set an example, good
or otherwise.

So, this document will not be progressed until an appropriate Morality
Considerations section, complete with subsections as specified by RFC
4041, has been added.

<WG chair hat off>

Kireeti.
-------

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 02 Apr 2005 19:25:31 +0200

hi adrian,

some coments here below

technical
---------

1. section 2.1

it seems from phrasing the term QoS is used in two different ways

"Using RSVP-TE, resources can also be reserved along a path to guarantee
  or control QoS for traffic carried on the LSP" thus last part of this 
sentence refers to the traffic oriented approach (as detailed in RFC 
2702) but after in this section (and in section 4.2) the term "QoS 
constraints" is used in a resource oriented perspective;

2. section 2.2

" The requirement for end-to-end allocation of lambda resources in
    GMPLS networks without wavelength converters means that end-to-end
    restoration is the only way to recover LSP failures. "

-> would it be possible to know how you came to this statement ?

3. section 3.

i may have missed it but the definition of "Explicit and Implicit 
Re-routing Indications" is not provided

4. section 4.2.1

not sure to see why the "reason" of the failure is important beside 
link, label, etc. (in particular since the persistence is limited to the 
LSP under establishmnet) - but i guess it depends on the semantic you 
put behind this word in the present context -

also by context you mean "position" of the element under failure wrt to 
its sequence as part of the ERO ?

5. section 4.4

is it " error indication upstream" or indicationS (collection) ?

6. section 5.2

"The Notify
    message may be used to expedite the propagation of error
    notifications, but in a network that offers crankback routing at
    multiple nodes there would need to be some agreement between LSRs
    as to whether PathErr or Notify provides the stimulus for crankback
    operation. "

this agreement is constrained by the re-routing behavior selection (as 
listed in section 6.4

7. section 6.4

point 2 - why segment-based is referred to as "hierarchical" - do you 
refer to an "horizontal hierarchy" here ?)

8. section 7.2

not sure to understand the "Proposed ERO" TLV ? would it be possible to 
describe this more than "MAY supply suggestions about the ERO that could 
have been used to avoid the error."

not sure to understand the "ERO_NEXT_CONTEXT" TLV

" Link Identifiers:

           A sequence of TLVs as defined here of type 3 that indicate
           incoming interfaces at downstream nodes that have already
           participated in crankback attempts and have been declared
           unusable for the current LSP setup attempt."

-> definition does not match the one proposed above in the text

"   For types 1, 2 and 3 the format of the Value field is already 
defined in [RFC3471]."

9. section 7.4.1

"   As described in section 3, a node receiving crankback information in
    a PathErr must first check to see whether it is allowed to perform
    re-routing. This is indicated by the Re-routing Flags in the
    SESSION_ATTRIBUTE object during LSP setup request."

-> why do you make use of the session attribute since section 6.4 
mentions usage of lsp attribute object

10. section 7.3

in section 7.3.1 it is mentioned

  "  If crankback is not being used but an IF-ID ERROR_SPEC object is
    included in a PathErr, ResvErr or Notify message, the sender SHOULD
    include one of the TLVs of type 1 through 3 as described in
    [RFC3473]. TLVs of type 4 or 5 SHOULD NOT be used as described in
    [BUNDLE] and component links should be identified using the
    principles described in that document.

    A sender MAY include additional TLVs from the range 6 through 27
    to report crankback information, although this information will at
    most only be used for logging."

[...]

   "An LSR that proposes to perform crankback re-routing SHOULD
    support receipt and processing of all of the fundamental crankback
    TLVs, and is RECOMMENDED to support the receipt and processing of
    the additional crankback TLVs."

in section 7.3.2 it is mentioned

" Error Report TLVs are those in the range 1 through 3. (Note that
    the obsoleted TLVs 4 and 5 may be considered in this category, but
    SHOULD NOT be used.)

    As stated above, when crankback information is reported, the IF_ID
    ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object is
    used, at least one of the TLVs in the range 1 through 3 MUST be
    present. The choice of which TLV to use will be dependent on the
    circumstance of the error and device capabilities. For example, a
    device that does not support IPv6 will not need the ability to
    create a TLV of type 2. Note, however, that such a device MUST still
    be prepared to receive and process all error report TLVs."

in section 7.3.4 it is mentioned

" It is left as an implementation detail precisely when to include each
    of the TLVs according to the capabilities of the system reporting the
    error."

=> would it be possible to harmonize these MUST, SHOULD, MAY, etc; ? one 
way to achieve this is by reducing repetitions and probably have 2 
sub-sections instead of 4

same comment in section 7.4.5 where it is mentioned

"When the node gives up it must propagate
    the failure message further upstream and include crankback
    information when it does so."

11. section 8.

   " For example, when an intermediate LSR issues a PathErr message, the
    signaling module of the intermediate LSR should interact with the
    routing logic to determine the routing-protocol-specific link or node
    ID where the blockage or fault occurred and carry this information
    onto the Link TLV and Node TLV inside the IF_ID ERROR_SPEC object."

-> Link TLV is not defined as part of the table ? would it be possible 
to list to which TLV you are referring to

12. section 9.1

"   In a network segmented into areas, the following procedures can be
    used. As explained in Section 8.2, the LSP restoration behavior is
    indicated in the Flags field of the SESSION_ATTRIBUTE object of the
    Path message. If the Flags indicate "End-to-end re-routing", the
    PathErr message is returned all the way back to the ingress LSR,
    which may then issue a new Path message along another path, which is
    the same procedure as in the flat network case above."

-> why do you make use of the session attribute since section 6.4 
mentions usage of lsp attribute object

editorial
---------

1. title

"Crankback Signaling Extensions for MPLS and GMPLS Signaling"

is probably redundant i would suggest (but leave this at your discretion)

"Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE"

2. section 2.2

alignment with P&R terminology and concepts would be advisable
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-06.txt>

3. section 4.2

"On the other hand, in a network partitioned into areas such as with
    hierarchical OSPF,..."

why "hierarchical OSPF" and not simply "OSPF"

4. section 5. - point 3)

instead of "... (particularly in the GMPLS context),"

i guess you mean for non-PSC LSP ?

5. section 7.2

"IF_ID PHOP" -> IF_ID RSVP_HOP ?

6. section 7.2

       " Node Identifiers:

           A sequence of TLVs as defined here of types 1, 2 or 8 that
           indicates downstream nodes that have already participated in
           crankback attempts and have been declared unusable for the
           current LSP setup attempt."

type 1, 2 does not define nodes in the proposed table ?

7. section 8

"  The ingress LSR, upon receiving the error message, should interact
    with the routing logic to compute an alternate path by pruning the
    specified link ID or node ID in the routing database."

i guess "node ID" refers to Router ID ?

aslo do no provide the exact pointer for TE Router ID and Router ID in 
the IS-IS context

hope this will help
---

Kireeti Kompella wrote:

> Hi,
> and
> draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
> 
> Please send your comments to the list (preferably) or to the authors
> by April 14, 23:59 GMT (which is when the last calls end).
> 
> Thanks,
> Kireeti.
> -------
> 
> 
> .
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 3 Apr 2005 08:40:32 +0100

Hi Dimitri,

Thanks for the thorough review.

> constraints" is used in a resource oriented perspective;

Point taken. This needs to be clarified.

> -> would it be possible to know how you came to this statement ?

Yes.
Actually, it should read "may be the only way".
Simply put, segment protection may be much harder in networks of photonic cross-connects because a particular lambda may already be in use on other links. End-to-end protection offers the choice of use of another lambda, but this choice is not available in segment protection.
 
> 3. section 3.
> 
> I may have missed it but the definition of "Explicit and Implicit 

The first paragraph was intended to convey this. We will clarify.

> put behind this word in the present context -

OK. It would probably help if we gave an example and a counter example.

Off the top of my head: "temporary control plane congestion" has a different impact on crankback rerouting to "cannot route to destination".

> its sequence as part of the ERO ?

Yeah. I don't think either of us has the right word here. We'll try to find something that explains this a bit better.

> is it " error indication upstream" or indicationS (collection) ?

Hmmm.
One error indication (message) may report multiple errors.
We will clarify this by inserting the word "message".

> this agreement is constrained by the re-routing behavior selection (as 

Yes. That would be a helpful cross-reference.

> refer to an "horizontal hierarchy" here ?)

Probably best if we remove this word because it has overloaded semantics with respect to hierarchical LSPs.
What we meant is simply that segment based protection allows you to protect ever smaller segments in a nested way. For example...

A--B--C--D--E--F--G--H
   |  |  |  |  |  |
   |  |  P--Q  |  |
   |  R----S---T  |
   W----X----Y----Z 

> have been used to avoid the error."

Intention is to allow a downstream LSR to report that "I cannot route using the supplied ERO, but if you had supplied *this* ERO it would have been possible."

> not sure to understand the "ERO_NEXT_CONTEXT" TLV

Both of these TLVs are described a bit further in 7.3.4. However, on re-reading I see that there isn't enough information. The distinction between TLVs 12 and 13 is the distinction between "this is the hop I was trying to satisfy when I failed" and "this is the next hop I was trying to reach when I failed".

> "   For types 1, 2 and 3 the format of the Value field is already 

Not sure what you are saying. Are you simply suggesting that the defintion of the Value for type 27 should point to 3471?

> mentions usage of lsp attribute object

Good catch!
Old text that should be replaced with LSP ATTRIBUTE.

> sub-sections instead of 4

Yes.

>     information when it does so."

Same answer.

> to list to which TLV you are referring to

Yes. Means TLV 1, 2 or 3.

> mentions usage of lsp attribute object

Ditto, above.

> "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE"

OK

> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-06.txt>

OK. Anything specific or do we just need to do a general parse?

> why "hierarchical OSPF" and not simply "OSPF"

Because we like adding the word "hierarchical" at every oportunity :-)

> I guess you mean for non-PSC LSP ?

You guess correctly. Will tidy this.

> "IF_ID PHOP" -> IF_ID RSVP_HOP ?

Yes.

> type 1, 2 does not define nodes in the proposed table ?

Not sure about this. Your point is valid, but it is also the case that one may identify a node by one of its interfaces. Thus it may be convenient to simply put the list of failed interfaces into this TLV and thus identify the list of nodes that have failed to perform crankback.

I guess we need a little input from the implementers on this point.

> i guess "node ID" refers to Router ID ?

Well, "TE Router ID".
And, of course, "Routing database" should read "Traffic Engineering Database".

> also do no provide the exact pointer for TE Router ID and Router ID in 
> the IS-IS context

Yup. I think by using TE Router ID we are covered in the IS-IS case, and we just need to update the text to identify the exact field.

> hope this will help

It does, a lot.

Thanks,
Adrian

---

From: dimitri papadimitriou <[email-masked]>
Date: Tue, 05 Apr 2005 00:57:05 +0200

hi adrian - see in-line for one or two remaining clarifications:

Adrian Farrel wrote:

>> technical ---------
>> "Using RSVP-TE, resources can also be reserved along a path to
>> guarantee or control QoS for traffic carried on the LSP" thus last
>> part of this sentence refers to the traffic oriented approach (as
>> detailed in RFC 2702) but after in this section (and in section
>> 4.2) the term "QoS constraints" is used in a resource oriented
>> perspective;
> 
> Yes. Actually, it should read "may be the only way". Simply put,
> segment protection may be much harder in networks of photonic
> cross-connects because a particular lambda may already be in use on
> other links. End-to-end protection offers the choice of use of
> another lambda, but this choice is not available in segment
> protection.
> 
>> 3. section 3.
>> 
>> link, label, etc. (in particular since the persistence is limited
>> to the LSP under establishmnet) - but i guess it depends on the
>> semantic you put behind this word in the present context -
> 
> Off the top of my head: "temporary control plane congestion" has a
> different impact on crankback rerouting to "cannot route to
> destination".
> 
>> also by context you mean "position" of the element under failure
>> wrt to its sequence as part of the ERO ?
> 
> Yeah. I don't think either of us has the right word here. We'll try
> to find something that explains this a bit better.
> 
>> 5. section 4.4
>> 
> Hmmm. One error indication (message) may report multiple errors. We
> will clarify this by inserting the word "message".
> 
>> 6. section 5.2
>> 
>> "The Notify message may be used to expedite the propagation of
>> error notifications, but in a network that offers crankback routing
>> at multiple nodes there would need to be some agreement between
>> LSRs as to whether PathErr or Notify provides the stimulus for
>> crankback operation. "
>> 
>> this agreement is constrained by the re-routing behavior selection
>> (as listed in section 6.4
> 
>> point 2 - why segment-based is referred to as "hierarchical" - do
>> you refer to an "horizontal hierarchy" here ?)
> 
> Probably best if we remove this word because it has overloaded
> semantics with respect to hierarchical LSPs. What we meant is simply
> that segment based protection allows you to protect ever smaller
> segments in a nested way. For example...
> 
> A--B--C--D--E--F--G--H
>    |  |  |  |  |  |
>    |  |  P--Q  |  |
>    |  R----S---T  |
>    W----X----Y----Z 

-> ok - i would refer to this as "nested crankback"

>> 8. section 7.2
>> 
>> not sure to understand the "Proposed ERO" TLV ? would it be
>> possible to describe this more than "MAY supply suggestions about
>> the ERO that could have been used to avoid the error."
> 
> Intention is to allow a downstream LSR to report that "I cannot route
> using the supplied ERO, but if you had supplied *this* ERO it would have
> been possible."
>  
> Both of these TLVs are described a bit further in 7.3.4. However, on
> re-reading I see that there isn't enough information. The distinction
> between TLVs 12 and 13 is the distinction between "this is the hop I was
> trying to satisfy when I failed" and "this is the next hop I was trying
> to reach when I failed".
> 
>> " Link Identifiers:
>> 
>> A sequence of TLVs as defined here of type 3 that indicate incoming
>> interfaces at downstream nodes that have already participated in
>> crankback attempts and have been declared unusable for the current
>> LSP setup attempt."
>> 
> Not sure what you are saying. Are you simply suggesting that the
> defintion of the Value for type 27 should point to 3471?

-> i mean that the encoding is borrowed from [RFC3471] but not the 
definition since pointing to "incoming interface at downstream node"
(which is the RFC3209 definition taken from ERO construction) and not 
the corr. definition of [RFC3473] "Data channels are specified from the 
viewpoint of the sender of the Path message".

>> 9. section 7.4.1
>> 
>> " As described in section 3, a node receiving crankback information
>> in a PathErr must first check to see whether it is allowed to
>> perform re-routing. This is indicated by the Re-routing Flags in
>> the SESSION_ATTRIBUTE object during LSP setup request."
>> 
> Good catch! Old text that should be replaced with LSP ATTRIBUTE.
> 
>> 10. section 7.3
>> 
>> A sender MAY include additional TLVs from the range 6 through 27 to
>> report crankback information, although this information will at 
>> create a TLV of type 2. Note, however, that such a device MUST
>> still be prepared to receive and process all error report TLVs."
>> 
>> " It is left as an implementation detail precisely when to include
>> each of the TLVs according to the capabilities of the system
>> reporting the error."
>> 
>> => would it be possible to harmonize these MUST, SHOULD, MAY, etc;
>> ? one way to achieve this is by reducing repetitions and probably
>> have 2 sub-sections instead of 4
> 
> Yes.
> 
>> "When the node gives up it must propagate the failure message
>> further upstream and include crankback information when it does
>> so."
> 
> Same answer.
> 
>> 11. section 8.
>> 
>> " For example, when an intermediate LSR issues a PathErr message,
>> the signaling module of the intermediate LSR should interact with
>> the routing logic to determine the routing-protocol-specific link
>> or node ID where the blockage or fault occurred and carry this
>> information onto the Link TLV and Node TLV inside the IF_ID
>> ERROR_SPEC object."
>> 
>> -> Link TLV is not defined as part of the table ? would it be
>> possible to list to which TLV you are referring to
> 
>> " In a network segmented into areas, the following procedures can
>> be used. As explained in Section 8.2, the LSP restoration behavior
>> is indicated in the Flags field of the SESSION_ATTRIBUTE object of
>> the Path message. If the Flags indicate "End-to-end re-routing",
>> the PathErr message is returned all the way back to the ingress
>> LSR, which may then issue a new Path message along another path,
>> which is the same procedure as in the flat network case above."
>> 
>> editorial ---------

-> adapt terminology (use the term protecting instead of backup, use the 
term protected or working instead of primary, etc.) and concepts (e.g. 
prefer the term "recovery" rather than restoration in the sentence "... 
various restoration schemes for link or node failures ..."; prefer the 
term "re-routing" rather than restoration in the sentence "... and 
include fast restoration.", etc.)

>> 3. section 4.2
>> 
>> "On the other hand, in a network partitioned into areas such as
>> with hierarchical OSPF,..."
>> 
>> crankback attempts and have been declared unusable for the current
>> LSP setup attempt."
>> 
> Not sure about this. Your point is valid, but it is also the case
> that  one may identify a node by one of its interfaces. Thus it may be
> convenient to simply put the list of failed interfaces into this TLV and
> thus identify the list of nodes that have failed to perform crankback.
> 

-> you would need feedback from people having implemented this with 
numbered i/fs (from my side, crankback has been experimented for 
unnumbered id) but this is indeed a common trick - so you would probably 
need to insert a hint here -

>> 7. section 8
>> 
>> " The ingress LSR, upon receiving the error message, should
>> interact with the routing logic to compute an alternate path by
>> pruning the specified link ID or node ID in the routing database."
>> 
> Well, "TE Router ID". And, of course, "Routing database" should read
> "Traffic Engineering  Database".
> 
>> also do no provide the exact pointer for TE Router ID and Router ID
>> in the IS-IS context
> 
> Yup. I think by using TE Router ID we are covered in the IS-IS case,
> and we just need to update the text to identify the exact field.
> 
>> hope this will help
> 
> 
> It does, a lot.
> 
> Thanks, Adrian

---

From: Arthi Ayyangar <[email-masked]>
Date: Wed, 13 Apr 2005 17:40:44 -0700 (PDT)

Hi Adrian,

Here are some comments (marked <AA>) on the crankback ID.

thanks,
-arthi

---------
1.1 typo : documentaiton

2.2
Crankback routing schemes could be used to notify the upstream LSRs
of the location of the failure.

<AA> Do you mean "Cranback signaling schemes could be used to notify" ?
                           ----------
     I observed that in some places crankback signaling and cranback routing
     are used interchangeably. Need to clarify ?

4.2.2
   If the crankback information can be used to compute a new route
   avoiding the blocking problem, the route can be signaled as an
   Explicit Route.

<AA> How about "If the crankback information can be used to compute a new
   path avoiding the blocking problem, the path can be signaled with a new
   Explicit Route."

7.2
<AA> What is the PROPOSED_ERO for ? Why can't the node doing crankback
re-routing simply figure out the new path based on constraints and
failures history in the downsstream network that he probably understands
best ? Why do we want the node reporting error to suggest an ERO ?
Same question about 26 and 27 as well. It would be intuitive if the node
reporting failures simply reports the failure and leaves the guesswork and
computation to the node taking the re-routing action. That way the
reponsibility of each node is well-defined. Also, it is the node doing
the re-route that has the bigger picture in the end.

7.3.1
<AA> I am not too sure of the following statement:-

  "If crankback is being used, the sender of a PathErr, ResvErr or
   Notify message MUST use the IF_ID ERROR_SPEC object and MUST include
   at least one of the TLVs in the range 1 through 3 as described in
   [RFC3473], [BUNDLE], and previous paragraph."

The assumption here is that IF_ID ERROR_SPEC is always being used.
In section 5.1 we acknowledge that with RSVP-TE crankback re-routing can
be performed explicitly avoiding the node or interface reported in
ERROR_SPEC; i.e. no TLVs. So, the above sentence is only true in the
context of GMPLS RSVP-TE. You may want to clarify this once somewhere.

7.3.3

   An LSR that proposes to perform crankback re-routing SHOULD
   support receipt and processing of all of the fundamental crankback
   TLVs, and is RECOMMENDED to support the receipt and processing of
   the additional crankback TLVs.

<AA> Why is the requirement for 'crankback re-routing' different from
     that for 'crankback' in section 7.2 ? Why isn't it enough for
     the LSR to support just the Error Report TLVs (1-3) in order to
     perform cranback re-routing ?

<AA> What information does DOWNSTREAM_LABEL and UPSTREAM LABEL provide to
     some node several hops upstream ? How is the node doing cranback
     re-routing going to use this info and enforce it along the new path?

7.4.4 When Re-routing Fails

   However, when a node was responsible for expanding or replacing the
   explicit route as the LSP setup was processed it MUST update the
   crankback information with regard to the explicit route that it
   received. Only if this is done will the upstream nodes stand a
   chance of successfully routing around the problem.

<AA> When you say "update", is the LSR replacing old crankback info with
new crankback info that it generates or is it appending this to received
crankback info in PathErr ? Also, is this a new PathErr (with a new src
addr) or the same PathErr that was received ? The reason I bring this up is
because elsewhere in the doc, you talk about intercepting and terminating
the error. I think you should clarify this in this section.

7.5. Notification of Errors

<AA> Is this section missing PathErr because it has been discussed in the
rest of the document ?

--------