Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

Hi, Giovanni, 

  When we resize a LSP, the label value needs to change for sure in transport networks. An example would be OTN and captured in Section 7 of draft-ietf-ccamp-gmpls-signaling-g709v3-12. The procedure described/cited there should also be applicable to resizing a LSP in flexi-grid as well, if I understand correctly. The difference is, in OTN the data plane can support hitless adjustment of the bandwidth, thus the need of explanation of interaction of both planes; not sure it is the case for flexi grid at the moment. So, I wonder if change a bandwidth of a flex-lsp means taking the steps of tearing down the old one and establishing a new one, thus already supported by RFC3209 from control plane perspective? 

  I think we are discussing some advanced issues and currently won't be needed in solutions drafts. If needed, a note may be added somewhere to the framework draft. Thoughts?

Regards,
Xian  

-----Original Message-----
From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Giovanni Martinelli (giomarti)
Sent: 2014年1月31日 23:55
To: Daniel King
Cc: CCAMP
Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

Hi Dan,

a comment from my side. Nothing precluding the draft to progress but having the m value in the label make me thinking.

I know there was lots of discussion in the past and likely the result is somewhat described section 4.2 however the use case I have in mind is when an established flex-lsp (hence a w/ flexgrid labels)  needs to be enlarged/shrinked. This operation implies a label value change. 

Now, does this consideration needs room in this draft /within framework /nowhere? I don’t have strong opinion just throwing a doubt on the table.

Cheers
G

On 29 Jan 2014, at 18:06, Daniel King <daniel@olddog.co.uk> wrote:

> Hi CCAMP'rs,
> 
> The authors are planning a revision of this I-D before London, but the only
> changes will be the addition of an Implementation Status section as per
> RFC6982.
> 
> It seems to us that this I-D is stable and that there are no further
> technical issues. The label format documented in the I-D has been picked up
> by the RSVP-TE extensions draft and the ongoing OSPF work. 
> 
> We would like to take this opportunity to solicit feedback from the working
> group:
> 
> - Are there any changes you would like to see in the draft? 
> - Are you happy with the label format described? 
> - What do you think the next steps should be for this draft?
> 
> Thanks,
> Dan (for the authors)
> 
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp