Subject: Last call review of draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 21 Apr 2008 20:25:30 +0100

Hi,

Here are some review comments about this I-D. As is bound to be the case 
with an experiment that has not been carried out, I think there are a few 
wrinkles to be ironed.

Cheers,
Adrian

===
I struggled to see the utility of the Upstream_TSpec and Upstream_Adspec 
objects. By the time these objects are used (on the Resv) the reservation 
has already been made using the Upstream_Flowspec (on the Path message).

This is strengthen by section 2.2.1 that says that the content is 
constructed using the same mechanisms as used for creating the content of 
the Flowspec. If that is so, it is a flowspec not a tspec.

I would contest that what you really have is...
Upstream_Flowspec is used to request a particular reservation as predicted 
by the ingress.
Upstream_TSpec is used to report the intended traffic flow (which might not 
be the same as the reservation and might require a modification to the 
reservation).
Upstream_Adspec reports the available resources in the upstream direction.

In this case, the operational use would be...
Path {TSpec, Adspec, Upstream_Flowspec}
Resv {Flowspec = fn(TSpec, Adspec), Upstream_TSpec, Upstream_Adspec}
If necessary
     Path {TSpec, Adspec, Upstream_Flowspec'}
     Resv {Flowspec, Upstream_TSpec, Upstream_Adspec}
===
I believe it would be helpful to indicate in the Abstract that this is an 
Experimental approach, and in the Introduction to include a whole paragraph 
on why this is positioned as an Experimental RFC.
===
Document title
s/LSPs/Label Switched Paths/
===
Abstract
s/LSPs/Label Switched Paths (LSPs)/
===
Section 1 para 1
s/LSPs/Label Switched Paths (LSPs)/
s/TDM/Time Division Multiplexing (TDM)/
===
Section 1 para 2
s/discussion on/discussion of/
===
Section 1
I believe it may be useful to say what an "asymmetric bandwidth LSP" is.
Perhaps...
   In this context there
   has been discussion on the support of bidirectional LSPs with
   asymmetric bandwidth.
ADD
   That is, bidirectional LSPs that have different bandwidth
   reservations in each direction.
===
Section 1.2
You have
   An alternative approach was considered and
   rejected.  For reference purposes only, the rejected approach is
   summarized in Appendix A.

Looking ahead at Appendix A, it is hard to see that this alternative has 
been rejected. In fact, it says "SHOULD NOT be implemented". Nowhere is 
there a definitive reason why the alternative has been rejected (although 
there are a few hints in the introduction to the Appendix).

*If* you wish to retain the rejected approach in the documentation, then you 
need to give some background about why. What would be the implications of 
doing the approach that lead you to recommend against it?

This material could happily go in the appendix leaving the only change to 
section 1.2 to be...
s/rejected approach is summarized/rejected approach is summarized with 
reasons for rejection/
===
Section 2
You have
   The new upstream objects carry the same information and are used in
   the same fashion as the existing downstream objects; they only differ
   in that they relate to traffic flowing in the upstream direction
   while the existing objects relate to traffic flowing in the
   downstream direction.

They also differ in that they are used on messages in the opposite 
directions.
===
Section 2.1.1
You suggest using "Routing problem/MPLS label allocation failure"
Are you sure you do not want to be able to tell whether it was the upstream 
or downstream resources that failed? Since these can be varied 
independently, it would surely be useful to know which failed.
===
Section 2.3.1
I think you need to clarify whether the Upstream_Adspec reports the 
available upstream resources before or after the reservation for the LSP in 
hand. Note that Adspec would apply before the reservation.
===
Section 3
You don't list Upstream_Flowspec as carried on a Notify. But an upstream 
notify session carries <sender descriptor> and you have defined this to 
carry Upstream_Flowspec.
You also don't list ResvErr as able to carry Upstream_TSpec, but ResvErr can 
carry <error flow descriptor> which presumably can carry the Upstream_TSpec 
as it also carries the Flowspec.
Also, you don't list PathTear (can carry <sender descriptor>) and ResvTear 
(carries <flow descriptor>)

Perhaps your excuse will be that you say "Unmodified formats are not 
listed." If that is the case, it should be pointed out that the formats of 
the other messages are not modified either!

Maybe the best way forward is to show how you modify <sender descriptor>, 
<flow descriptor> and <error flow descriptor>, and say that the use of these 
constructs on RSVP messages is not modified. That would be the smallest 
change to the documentation.
===
Section 4
OLD
   Per [RFC2205], nodes not
   supporting this extension should not recognize the new class numbers
   and respond with an "Unknown Object Class" error.
NEW
   Per [RFC2205], nodes not
   supporting this extension will not recognize the new class numbers
   and SHOULD respond with an "Unknown Object Class" error.
===
Section 4
You have...
   The error message
   will propagate to the ingress which can then take action to avoid the
   path with the incompatible node, or may simply terminate the session.
I think you need a little more care with the behavior for unknown object on 
a Resv since that error will propagate to the egress.
===
Section 5.
You might need another error code as mentioned above.
===
Section 6
It is always worth referencing 
draft-ietf-mpls-mpls-and-gmpls-security-framework in GMPLS-related security 
sections.

Although you have not introduced any new ways to penetrate the security, I 
wonder whether you have introduced new ways to attack the system once 
security is penetrated. Upstream_Adspec may be a way to damage the system 
without leaving immediate evidence of where the attack originated. 
Upstream_TSpec represents a new way to cause an LSP that has been set up, to 
be torn down. Of course these issues can be protected against, but you need 
to point them out so that people understand the increased risk and the 
potential need to use the existing security mechanisms.
===
Section 7.1
[MEF-TRAFFIC] has been revised.
Does it need to be a normative reference? It is only cited as an example.
===
Section 7.2
[GMPLS-PBBTE] is now a CCAMP I-D
===
Section 8
s/Author's/Authors'/
===
All appendix sections
Section headers need left justify
===
Sections A, A.1, A.3, A.4
s/section/appendix/  (Except "Section 3", "Section 3.1")
===

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Apr 2008 10:51:36 -0400

Adrian,
         Much thanks for the comments.  Please see below for in-line responses.

At 03:25 PM 4/21/2008, Adrian Farrel wrote:
>Hi,
>
>Here are some review comments about this I-D. As is bound to be the 
>case with an experiment that has not been carried out, I think there 
>are a few wrinkles to be ironed.
>
>Cheers,
>Adrian
>
>===
>I struggled to see the utility of the Upstream_TSpec and 
>Upstream_Adspec objects. By the time these objects are used (on the 
>Resv) the reservation has already been made using the 
>Upstream_Flowspec (on the Path message).

The utility here really comes from the support of PSC modes and 
preservation of RSVP/IntServ semantics.  In short we're maintaining 
the object types used in the downstream direction and instantiating 
them for the upstream direction.  To quote 2210:

    From the point of view of RSVP objects, the breakdown is as follows:

       - The RSVP SENDER_TSPEC object carries the traffic specification
       (sender TSpec) generated by each data source within an RSVP
       session.  It is transported unchanged through the network, and
       delivered to both intermediate nodes and receiving applications.

       - The RSVP ADSPEC object carries information which is generated at
       either data sources or intermediate network elements, is flowing
       downstream towards receivers, and may be used and updated inside
       the network before being delivered to receiving applications.
       This information includes both parameters describing the
       properties of the data path, including the availability of
       specific QoS control services, and parameters required by specific
       QoS control services to operate correctly.

       - The RSVP FLOWSPEC object carries reservation request
       (Receiver_TSpec and RSpec) information generated by data
       receivers.  The information in the FLOWSPEC flows upstream towards
       data sources.  It may be used or updated at intermediate network
       elements before arriving at the sending application.

         NOTE: The existence of both SENDER_TSPEC and ADSPEC RSVP objects
         is somewhat historical. Using the message format described in
         this note it would be possible to place all of the service
         control information carried "downstream" by RSVP in the same
         object. However, the distinction between data which is not
         updated within the network (in the SENDER_TSPEC object) and data
         which is updated within the network (in the ADSPEC object) may
         be useful to an implementation in practice, and is therefore
         retained.

>constructed using the same mechanisms as used for creating the 
>content of the Flowspec. If that is so, it is a flowspec not a tspec.

I see this as a reference to semantic construction.  I think this is 
clear in the text, but am open to any specific improvements you can suggest:

    ... The contents of the
    UPSTREAM_TSPEC Object MUST be constructed using a consistent format
    and procedures used to construct the FLOWSPEC object that will be
    used for the LSP, e.g., [RFC2210] or [RFC4328].  The contents of the
    UPSTREAM_TSPEC Object MAY differ from contents of the
    UPSTREAM_FLOWSPEC object based on application data transmission
    requirements.

>Upstream_Flowspec is used to request a particular reservation as 
>predicted by the ingress.

yes.

>Upstream_TSpec is used to report the intended traffic flow (which 
>might not be the same as the reservation and might require a 
>modification to the reservation).

right.

>Upstream_Adspec reports the available resources in the upstream direction.

right again.

>     Resv {Flowspec, Upstream_TSpec, Upstream_Adspec}

I think this is what the draft says.

>===
>I believe it would be helpful to indicate in the Abstract that this 
>is an Experimental approach, and in the Introduction to include a 
>whole paragraph on why this is positioned as an Experimental RFC.

Okay have added:

         NOTE: THIS IS AN EXPERIMENTAL RFC.

Let us know if you'd to see anything additional.

>   reservations in each direction.

okay.

>Looking ahead at Appendix A, it is hard to see that this alternative 
>has been rejected. In fact, it says "SHOULD NOT be implemented". 
>Nowhere is there a definitive reason why the alternative has been 
>rejected (although there are a few hints in the introduction to the Appendix).

well it does say:
     This section is included for historic purposes and SHOULD NOT
     be implemented.

and
     In summary, the "ADSPEC Object" approach presented in this
     section SHOULD NOT be implemented.

This seems pretty clear to me.  What would you like it to say?

>*If* you wish to retain the rejected approach in the documentation, 
>then you need to give some background about why. What would be the 
>implications of doing the approach that lead you to recommend against it?

>This material could happily go in the appendix leaving the only 
>change to section 1.2 to be...
>s/rejected approach is summarized/rejected approach is summarized 
>with reasons for rejection/

I've changed the sec. 1.2. text to read "An alternative approach was 
considered and rejected in favor of the more generic approach 
presented below." and to A.1. "In particular this approach is 
technology specific; it uses the ADSPEC object to carry traffic 
parameters for upstream data and requires MEF Ethernet Traffic 
Parameter while the approach presented above is suitable for use with 
any technology."

>They also differ in that they are used on messages in the opposite directions.

okay.

>Are you sure you do not want to be able to tell whether it was the 
>upstream or downstream resources that failed? Since these can be 
>varied independently, it would surely be useful to know which failed.

I don't have a strong opinion one way or another.

>available upstream resources before or after the reservation for the 
>LSP in hand.

>  Note that Adspec would apply before the reservation.

This may be true on the initial path, but it isn't actually stated 
anywhere.  Furthermore, the information may include an LSPs 
reservation even in the case where it is not yet made.  e.g., RFC2212 
talks in terms of reporting what the "flow might experience" which 
implies that the full Tspec is accounted for in the initial ADSPEC.

So I think, like 2210, this should not be mentioned.

>===
>Section 3
>You don't list Upstream_Flowspec as carried on a Notify. But an 
>upstream notify session carries <sender descriptor> and you have 
>defined this to carry Upstream_Flowspec.
>You also don't list ResvErr as able to carry Upstream_TSpec, but 
>ResvErr can carry <error flow descriptor> which presumably can carry 
>the Upstream_TSpec as it also carries the Flowspec.
>Also, you don't list PathTear (can carry <sender descriptor>) and 
>ResvTear (carries <flow descriptor>)
>
>listed." If that is the case, it should be pointed out that the 
>formats of the other messages are not modified either!

nope. just a simple mistake.

>Maybe the best way forward is to show how you modify <sender 
>descriptor>, <flow descriptor> and <error flow descriptor>, and say 
>that the use of these constructs on RSVP messages is not modified. 
>That would be the smallest change to the documentation.

Good catch.  Have changed the text to read:

    Object name            Applicable RSVP messages
    ---------------        ------------------------
    UPSTREAM_FLOWSPEC      Path, PathTear, PathErr and Notify
                               (via sender descriptor)
    UPSTREAM_TSPEC         Resv, ResvConf, ResvTear, ResvErr and
                               Notify (via flow descriptor list)
    UPSTREAM_ADSPEC        Resv, ResvConf, ResvTear, ResvErr and
                               Notify (via flow descriptor list)

>   and SHOULD respond with an "Unknown Object Class" error

okay, the should is lower case as this document cannot dictate 
behavior of non-conforming implementations ;-)

>I think you need a little more care with the behavior for unknown 
>object on a Resv since that error will propagate to the egress.

This can only happen from a non-conformant implementation, i.e., one 
that passes a new object in the path but then rejects it in the resv.

>draft-ietf-mpls-mpls-and-gmpls-security-framework in GMPLS-related 
>security sections.
>
>Although you have not introduced any new ways to penetrate the 
>security, I wonder whether you have introduced new ways to attack 
>the system once security is penetrated. Upstream_Adspec may be a way 
>to damage the system without leaving immediate evidence of where the 
>attack originated. Upstream_TSpec represents a new way to cause an 
>LSP that has been set up, to be torn down. Of course these issues 
>can be protected against, but you need to point them out so that 
>people understand the increased risk and the potential need to use 
>the existing security mechanisms.

okay have added some words on this.
>Does it need to be a normative reference? It is only cited as an example.

moved.

>s/section/appendix/  (Except "Section 3", "Section 3.1")

isn't an appendix a section of the document?

Thanks for the usual detailed review & comments...

Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 24 Apr 2008 20:58:57 +0100

Hi Lou,

>>has already been made using the Upstream_Flowspec (on the Path message).

[SNIP]

I think I found the "exactly the same" description a little strong. But 
given our discussion (snipped) I think we are agreed on the usage.

The only thing I find missing from the I-D might be expressed as...

"When an egress receives an Upstream-Flowspec object, it responds with an 
Upstream-TSpec for describe the traffic flow that it will originate. When 
that Upstream-TSpec is received by the ingress, it may determine that the 
original reservation is not sufficient to satisfy the traffic flow. In this 
case it will issue a new Path message with an updated Upstream-Flowspec 
object to mnodify the resources reserved for the upstream traffic flow. This 
might also require that the LSP is re-routed, and in extreme cases might 
result in the LSP being torn down if sufficient resources are not 
available."

>>Experimental approach, and in the Introduction to include a whole 
>>paragraph on why this is positioned as an Experimental RFC.
>
> Okay have added:
>

In the abstract it would be fine to simply say:

"The procedures described in this document are experimental."

In the Introduction, you might say:

"The usage of asymmetrical bidirectional LSPs is not well developed and no 
products have been developed yet. In consequence, the procedures described 
in this document are experimental."

> This seems pretty clear to me.  What would you like it to say?

Well, I've just seen an I-D bounced by the IESG because it uses "SHOULD" 
without explaining why you might actually do it. That is, there is a claim 
that in 2119 language "SHOULD" implies that there might be good reasons to 
deviate, so there needs to be text to describe how the deviation is handled 
and why it might be introduced.

Curiously, NOT RECOMMENDED would mean the same thing, but might be more 
acceptable.

[SNIP]

> considered and rejected in favor of the more generic approach presented 
> below." and to A.1. "In particular this approach is technology specific; 
> it uses the ADSPEC object to carry traffic parameters for upstream data 
> and requires MEF Ethernet Traffic Parameter while the approach presented 
> above is suitable for use with any technology."

That's good.
Thanks.

>>upstream or downstream resources that failed? Since these can be varied 

Me neither.
We could ask the implementers :-)

>>available upstream resources before or after the reservation for the LSP 
>>in hand.
>
> anywhere.  Furthermore, the information may include an LSPs reservation 
> even in the case where it is not yet made.  e.g., RFC2212 talks in terms 
> of reporting what the "flow might experience" which implies that the full 
> Tspec is accounted for in the initial ADSPEC.
>

OK

>>I think you need a little more care with the behavior for unknown object 
>>on a Resv since that error will propagate to the egress.
>
> This can only happen from a non-conformant implementation, i.e., one that 
> passes a new object in the path but then rejects it in the resv.

Or a node that has to handle a non-conformant node that generates an 
Upstream-TSpec when it did not receive an Upstream-Flowspec.

But let's leave it.

Thanks for the work.
Adrian

---

From: Lou Berger <[email-masked]>
Date: Thu, 24 Apr 2008 16:35:55 -0400

Adrian,
         Please see below.

At 03:58 PM 4/24/2008, Adrian Farrel wrote:
>>>Upstream_Adspec objects. By the time these objects are used (on 
>>>the Resv) the reservation has already been made using the 
>I think I found the "exactly the same" description a little strong. 
>But given our discussion (snipped) I think we are agreed on the usage.
>
>"When an egress receives an Upstream-Flowspec object, it responds 
>with an Upstream-TSpec for describe the traffic flow that it will 
>originate. When that Upstream-TSpec is received by the ingress, it 
>may determine that the original reservation is not sufficient to 
>satisfy the traffic flow. In this case it will issue a new Path 
>message with an updated Upstream-Flowspec object to mnodify the 
>resources reserved for the upstream traffic flow. This might also 
>require that the LSP is re-routed, and in extreme cases might result 
>in the LSP being torn down if sufficient resources are not available."

Added to section 2.2.1.

>>>===
>>>I believe it would be helpful to indicate in the Abstract that 
>>>this is an Experimental approach, and in the Introduction to 
>>>include a whole paragraph on why this is positioned as an Experimental RFC.
>>
>>Okay have added:
>>

done

>"The usage of asymmetrical bidirectional LSPs is not well developed 
>and no products have been developed yet. In consequence, the 
>procedures described in this document are experimental."

added: "the procedures described in this document are experimental."

>>>Looking ahead at Appendix A, it is hard to see that this 
>>>alternative has been rejected. In fact, it says "SHOULD NOT be 
>>>implemented". Nowhere is there a definitive reason why the 
>>>alternative has been rejected (although there are a few hints in 
>>>the introduction to the Appendix).
>>
>>well it does say:
>Well, I've just seen an I-D bounced by the IESG because it uses 
>"SHOULD" without explaining why you might actually do it. That is, 
>there is a claim that in 2119 language "SHOULD" implies that there 
>might be good reasons to deviate, so there needs to be text to 
>describe how the deviation is handled and why it might be introduced.
>
>Curiously, NOT RECOMMENDED would mean the same thing, but might be 
>more acceptable.

NOT RECOMMENDED it is.

>[SNIP]
>
>>I've changed the sec. 1.2. text to read "An alternative approach 
>>was considered and rejected in favor of the more generic approach 
>>Parameter while the approach presented above is suitable for use 
>>with any technology."
>
>That's good.
>Thanks.
>
>>>===
>>>Section 2.1.1
>>>I think you need to clarify whether the Upstream_Adspec reports 
>>>the available upstream resources before or after the reservation 
>>>for the LSP in hand.
>>
>>reservation even in the case where it is not yet made.  e.g., 
>>RFC2212 talks in terms of reporting what the "flow might 
>>experience" which implies that the full Tspec is accounted for in 
>>the initial ADSPEC.
>>
>>This can only happen from a non-conformant implementation, i.e., 
>>one that passes a new object in the path but then rejects it in the resv.
>

great.  Thanks for the comments!

Lou