Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 17 Apr 2013 00:51:31 +0000

Hi Fred,

Thanks again for the suggestions. No worries, if this is a change that makes sense we can fix it before the second last call.

Just wanted a clarification (more loud thinking than a question): do you think that an interface might support different TSGs at the same time? If the answer is yes the bitmap makes sense, otherwise an enum would be more bits-saving.
I would say that until no LSP is configured it is possible to advertise/support multiple of them (e.g. The newest one plus the ones it is possible to rollback to for backward compatibility issues) and then, after the instantiation of the first LSP, a single one.

Best regards
Daniele

*** E-mail via DME powered by mobile broadband ***

--Original message---
Sender: "Gruman, Fred" <[email-masked]>
Sent time: 14/apr/2013 09:02
To: [email-masked], [email-masked]
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt

Hi Daniele,

Thanks for making the update to the TSG examples in Section 5.2

I have a one additional comments regarding TSG:

1) during an OIF conference call, Stephen Shew indicated that ITU may be considering additional tributary slot granularity in the future (in addition to 1.25 and 2.5G).  There was a concern about handling more complex combinations in the future.  

It was suggested that perhaps instead of enumerating each combination, the TSG be treated as bit flags where the first bit could indicate 1.25G, second bit indicates 2.5G, third bit and beyond (perhaps into the reserve fields in the future) could indicate future TSG rates.  The encoding could then be:
 00 - ignored
 10 - 1.25G only
 01 - 2.5G only
 11 - Both 1.25G and 2.5G supported

This may make it easier to understand the encoding if additional TSGs are added later.

I realize this comment may be coming in late so you might prefer to not make any changes (this is ok with me as the current encodings are technically correct).

Best Regards,
Fred

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Thursday, April 04, 2013 10:46 AM
To: [email-masked]
Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt

Dear OTNers,

Info model and OSPF drafts have been updated accordingly to the discussion in Orlando. The OSPF draft also includes some last call comments that had not been addressed in v05 and suggestions received on the list.

On the other side the framework draft doesn't need any change, while the signaling will be updated soon.

BR
Daniele, Sergio, Fatai

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of [email-masked]
>Sent: giovedì 4 aprile 2013 17.40
>To: [email-masked]
>Cc: [email-masked]
>Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt
>
>
>A New Internet-Draft is available from the on-line 
>Internet-Drafts directories.
> This draft is a work item of the Common Control and 
>Measurement Plane Working Group of the IETF.
>
>	Title           : Traffic Engineering Extensions to 
>OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 
>OTN Networks
>	Author(s)       : Daniele Ceccarelli
>                          Diego Caviglia
>                          Fatai Zhang
>                          Dan Li
>                          Sergio Belotti
>                          Pietro Vittorio Grandi
>                          Rajan Rao
>                          Khuzema Pithewan
>                          John E Drake
>	Filename        : draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt
>	Pages           : 35
>	Date            : 2013-04-04
>
>Abstract:
>   ITU-T Recommendation G.709 [G.709-2012] has introduced new fixed and
>   flexible Optical Data Unit (ODU) containers, enabling optimized
>   support for an increasingly abundant service mix.
>
>   This document describes Open Shortest Path First - Traffic
>   Engineering (OSPF-TE) routing protocol extensions to support
>   Generalized MPLS (GMPLS) control of all currently defined ODU
>   containers, in support of both sub-lambda and lambda level routing
>   granularity.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-06
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-gmpls-ospf-g709v3-06
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>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: John E Drake <[email-masked]>
Date: Wed, 17 Apr 2013 11:44:36 +0000

Fred,

Other than to demonstrate it is always possible to add additional complexity to OTN, is there any reason to add additional TSG values?

Irrespectively Yours,

John

> Sent: Tuesday, April 16, 2013 5:52 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-
> g709v3-06.txt
> 
> Hi Fred,
> 
> Thanks again for the suggestions. No worries, if this is a change that
> makes sense we can fix it before the second last call.
> 
> Just wanted a clarification (more loud thinking than a question): do
> you think that an interface might support different TSGs at the same
> time? If the answer is yes the bitmap makes sense, otherwise an enum
> would be more bits-saving.
> I would say that until no LSP is configured it is possible to
> advertise/support multiple of them (e.g. The newest one plus the ones
> it is possible to rollback to for backward compatibility issues) and
> then, after the instantiation of the first LSP, a single one.
> 
> Best regards
> Daniele
> 
> Sender: "Gruman, Fred" <[email-masked]> Sent time:
> 14/apr/2013 09:02
> 1) during an OIF conference call, Stephen Shew indicated that ITU may
> be considering additional tributary slot granularity in the future (in
> addition to 1.25 and 2.5G).  There was a concern about handling more
> complex combinations in the future.
> 
> It was suggested that perhaps instead of enumerating each combination,
> the TSG be treated as bit flags where the first bit could indicate
> 1.25G, second bit indicates 2.5G, third bit and beyond (perhaps into
> the reserve fields in the future) could indicate future TSG rates.  The
> encoding could then be:
>  00 - ignored
>  10 - 1.25G only
>  01 - 2.5G only
> I realize this comment may be coming in late so you might prefer to not
> make any changes (this is ok with me as the current encodings are
> technically correct).
> 
> Best Regards,
> Fred
> 
> 
> Info model and OSPF drafts have been updated accordingly to the
> discussion in Orlando. The OSPF draft also includes some last call
> comments that had not been addressed in v05 and suggestions received on
> the list.
> 
> >From: [email-masked] [mailto:[email-masked]] On Behalf
> >Of [email-masked]
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> > This draft is a work item of the Common Control and Measurement Plane
> >Working Group of the IETF.
> >
> >OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN
> >Networks

---

From: "Gruman, Fred" <[email-masked]>
Date: Wed, 24 Apr 2013 16:11:42 +0000

Hi John/Daniele,

It was pointed out to me that ITU was thinking of additional TSGs when they look at beyond ODU4. There is no need to add additional TSGs until these are standardized in future versions of G.709. But if there are additional values, it may be more intuitive encoding to use bitmaps.  But as I mention in my email, there is really nothing wrong with the current method (ENUM).

In response to Daniele's question regarding "an interface might support different TSGs at the same time", I would agree that the only time this would probably be the case is before the first LO-ODU was provisioned and we want to show the potential to support different TSGs against the HO-ODU. Once the first LO-ODU was activated, then the TSG would be locked for that HO-ODU.

Best Regards,
Fred

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Wednesday, April 17, 2013 5:45 AM
To: Daniele Ceccarelli; Gruman, Fred
Cc: [email-masked]
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt

Fred,

Irrespectively Yours,

John

> Of Daniele Ceccarelli
> Of Daniele Ceccarelli

---

From: Daniele Ceccarelli <[email-masked]>
Date: Sun, 28 Apr 2013 17:34:15 +0000

Hi Fred,

It seems we are on the same page. All of the considerations below are more than reasonable but it seems at the time being we don't have enough info to state whether an enum is better than a bitmap or viceversa. I would suggest to keep the actual encoding but many thanks for raising up the issue.

Many thanks
Daniele

>From: Gruman, Fred [mailto:[email-masked]] 
>Sent: mercoledì 24 aprile 2013 18.12
>To: John E Drake; Daniele Ceccarelli
>Cc: [email-masked]
>Subject: RE: [CCAMP] FW: I-D Action: 
>draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt
>
>Hi John/Daniele,
>
>It was pointed out to me that ITU was thinking of additional 
>TSGs when they look at beyond ODU4. There is no need to add 
>additional TSGs until these are standardized in future 
>versions of G.709. But if there are additional values, it may 
>be more intuitive encoding to use bitmaps.  But as I mention 
>in my email, there is really nothing wrong with the current 
>method (ENUM).
>
>In response to Daniele's question regarding "an interface 
>might support different TSGs at the same time", I would agree 
>that the only time this would probably be the case is before 
>the first LO-ODU was provisioned and we want to show the 
>potential to support different TSGs against the HO-ODU. Once 
>the first LO-ODU was activated, then the TSG would be locked 
>for that HO-ODU.
>
>Best Regards,
>Fred
>
>Subject: RE: [CCAMP] FW: I-D Action: 
>draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt
>
>Fred,
>
>Other than to demonstrate it is always possible to add 
>additional complexity to OTN, is there any reason to add 
>additional TSG values?
>
>Irrespectively Yours,
>
>John
>
>
>On Behalf 
>> the reserve fields in the future) could indicate future TSG rates.  
>> The encoding could then be:
>>  00 - ignored
>>  10 - 1.25G only
>>  01 - 2.5G only
>> This may make it easier to understand the encoding if 
>additional TSGs 
>> are added later.
>> 
>> I realize this comment may be coming in late so you might prefer to 
>> not make any changes (this is ok with me as the current 
>encodings are 
>> technically correct).
>> 
>> Best Regards,
>> Fred
>> 
>> 
>On Behalf 
>> comments that had not been addressed in v05 and suggestions received 
>> on the list.
>> 
>> >From: [email-masked] [mailto:[email-masked]] On 
>> >Behalf Of [email-masked]
>> >Subject: [CCAMP] I-D Action: 
>> >draft-ietf-ccamp-gmpls-ospf-g709v3-06.txt
>> >
>> >
>> > This draft is a work item of the Common Control and Measurement 
>> >Plane Working Group of the IETF.
>> >