[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


I would contest that what you really have is...
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.


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


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


okay.


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

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



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


okay.


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

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


===
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.
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>)
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! 

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)




===
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
okay, the should is lower case as this document cannot dictate behavior of non-conforming implementations ;-) 



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


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

okay have added some words on this.

===
Section 7.1
[MEF-TRAFFIC] has been revised.
Does it need to be a normative reference? It is only cited as an example.


moved.


===
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")
===


isn't an appendix a section of the document?

Thanks for the usual detailed review & comments...
Lou