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

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Mon, 3 Mar 2014 17:07:56 +0000

Hi Xian,

sorry for the late reply
On 08 Feb 2014, at 11:36, Zhangxian (Xian) <[email-masked]> wrote:

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

GM> yep that’s a good starting point

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

GM> IMHO yes.

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

GM> this was a bare minimum option

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

GM> I would say yes… 

Cheers
G

> Regards,
> Xian  
> 
> -----Original Message-----
> From: CCAMP [mailto:[email-masked]] 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 <[email-masked]> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ccamp
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 3 Mar 2014 17:26:41 -0000

Hey Giovani,

> > 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.
> 
> GM> IMHO yes.

I think you are saying that in your opinion hitless resizing in flexigrid is
possible.

We might need to be careful with terminology. Some people say "hitless" and
allow a few frames to be dropped. Some mean no frames will be dropped.

We asked Q6/15, if I recall correctly, and got told "no" (need to check the
liaison?). That does not preclude vendors making products that support this.

>From a GMPLS perspective, I think we do support hitless reassignment of labels.
It is as complicated as it would be if you used the management plane because
coordination is needed between all network nodes. It is far nicer to do
make-before-break onto a completely different piece of spectrum.

Cheers,
Adrian

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Mon, 3 Mar 2014 18:22:52 +0000

Hi Adrian,

> allow a few frames to be dropped. Some mean no frames will be dropped.

GM> resizing as  “adding more bandwidth” to an existing LSP without hit on traffic alreday running on the LSP itself.  Now, as you know I’m an old-optical guys so in prinpriple I don’t know the traffic on top of the SSON LSP (either otn, packet etc.). For sure resizing in “narrowing the bandwidth” of existing LSP should be managed with care.

> liaison?). That does not preclude vendors making products that support this.

GM> undestood. However sounds to me a similar problem to spectrum granularity … sometime technlogy is a bit ahead of std bodies.

> coordination is needed between all network nodes.

GM> agree that we do something with existing GMPLS.  While writing not sure what the best to do, either leaving everything as is or at least spending few words (may be in fwk document?) about implications of having a certain label format. May be some flex grid fas has other ideas

> It is far nicer to do

GM> well, this sounds to me more like an operational choice… btw in this case I would say likely not hitless

Cheers,
G