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

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

>-----Original Message-----
>From: Gruman, Fred [mailto:fred.gruman@us.fujitsu.com] 
>Sent: mercoledì 24 aprile 2013 18.12
>To: John E Drake; Daniele Ceccarelli
>Cc: ccamp@ietf.org
>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
>
>-----Original Message-----
>From: John E Drake [mailto:jdrake@juniper.net]
>Sent: Wednesday, April 17, 2013 5:45 AM
>To: Daniele Ceccarelli; Gruman, Fred
>Cc: ccamp@ietf.org
>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
>
>
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 
>On Behalf 
>> Of Daniele Ceccarelli
>> Sent: Tuesday, April 16, 2013 5:52 PM
>> To: fred.gruman@us.fujitsu.com
>> Cc: ccamp@ietf.org
>> 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
>> 
>> *** E-mail via DME powered by mobile broadband ***
>> 
>> --Original message---
>> Sender: "Gruman, Fred" <fred.gruman@us.fujitsu.com> Sent time:
>> 14/apr/2013 09:02
>> To: daniele.ceccarelli@ericsson.com, ccamp@ietf.org
>> 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: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 
>On Behalf 
>> Of Daniele Ceccarelli
>> Sent: Thursday, April 04, 2013 10:46 AM
>> To: ccamp@ietf.org
>> 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: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On 
>> >Behalf Of internet-drafts@ietf.org
>> >Sent: giovedì 4 aprile 2013 17.40
>> >To: i-d-announce@ietf.org
>> >Cc: ccamp@ietf.org
>> >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-0
>> >6
>> >
>> >
>> >Internet-Drafts are also available by anonymous FTP at:
>> >ftp://ftp.ietf.org/internet-drafts/
>> >
>> >_______________________________________________
>> >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
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>