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

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

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