[CCAMP] ODUflex resize question in RFC7139 (3924)

["Gruman, Fred" <[e-mail]>]

Hi Fatai,

I'm reviewing the published OTNv3 RFCs to see if I need to update any of the work in OIF to remain aligned with these documents. As part of this review, I noticed the following regarding ODUflex resize (Section 7):

1. ODUflex resize - teardown of original connection

- For bandwidth increase, the PathTear message is used to delete the original connection
- For bandwidth decrease, the ResvErr message is used to delete the original connection

Is this really what we wanted?  If so, can you let me know why different procedures are required for the two cases?  (Or why not PathTear for both cases?)

I don't think that we've traditionally used ResvErr to teardown an LSP in GMPLS. We've used PathTear (or Path D&R followed by PathErr with path-state-removed). ResvErr is confusing to me, at least the specs in RFC 2205 that gets into discussions of blockage states, etc. Is this even appropriate to use ResvErr to tear down a connection, as my reading of RFC 2205 (although I'm not 100% certain on this) is that a ResvErr does not delete the Path or Resv states.


2. ODUflex resize setup with SE style.

Section 7 states: "Note that the SE style MUST be used at the beginning when creating a resizable ODuflex connection". For the bandwidth decreasing section, it states that "For the ingress node, a Path message with SE style SHOULD also be sent for decreasing the ODUflex bandwidth".  I would think that the "SHOULD" should be changed to "MUST".

Per RFC 2205 (Section 1.3), it is not possible to merge flowspecs when LSPs are signaled with different styles.  I think it would not be legal to have two LSPs with different signaling styles to share the same resource. 


I apologize for getting this question in now. I had thought I had kept up with the changes within the draft but I missed these details.

Lou, once these discussions are complete, I'll submit an errata to cover my issues.

Thanks, 
Fred