Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-otn-g709-info-model-05.txt

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 11 Jan 2013 15:20:17 +0000

Hi Lou,

Please see in line.

Please also note that the references to G.798 amd2 and G.872 amd2 were changed into G.798 new revision and G.872 new revision. 
The first one is pre-published on the ITU-T ties web page and will be officially published on January 16th, while G.872 was published in October. Both of them are actually available for ties users only. 

These are the documents that should be requested to be publicly available (no clue on when they will be available and if it is worth waiting for them or a liaison might be more useful). 

BR
Daniele & Sergio

>-----Original Message-----
>From: Lou Berger [mailto:[email-masked]] 
>Sent: giovedì 20 dicembre 2012 16.07
>To: Daniele Ceccarelli
>Cc: [email-masked]; [email-masked]
>Subject: Re: [CCAMP] I-D Action: 
>draft-ietf-ccamp-otn-g709-info-model-05.txt
>
>Daniele / Authors,
>	Thank you for the response.  Please see below for my responses.
>
>
>
>On 12/20/2012 4:05 AM, Daniele Ceccarelli wrote:
>> Hi Lou,
>> 
>> Below you can find the last call comments pasted with 
>replies in line.
>> 
>> All nits, typos and suggested text changes without any 
>comment in line have been accepted/modified accordingly.
>> 
>> BR
>> Daniele & Sergio
>> 
>> 
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of Lou Berger
>>> Sent: sabato 20 ottobre 2012 0.06
>>> To: CCAMP; [email-masked]
>>> Subject: [CCAMP] WG Last Call comments on
>>> draft-ietf-ccamp-otn-g709-info-model-04
>>>
>>>
>>> Authors,
>>> 	I have the following LC comments:
>>>
>>> General comments:
>>>
>>> - There's a lot of text/concepts that is common to both 
>this document 
>>> and the framework document.  The document certainly adds additional 
>>> useful detail, but I'm not sure it's really provides an information 
>>> model of any kind.  Optimally, I think this document should 
>be merged 
>>> with the framework document.  I think this would yield a more 
>>> comprehensive and understandable result.  I really don't 
>see this as 
>>> a lot of work/time, although it clearly would be a major change
>>>
>>> If this is considered to be to onerous a proposal, then 
>this document 
>>> should at least be updated to (a) reduce duplication text with the 
>>> framework document and (b) remove any references to "model" 
>and just 
>>> talk about providing "Additional Information"
>> 
>> All duplicated text have been removed from this ID and kept 
>into the FWK (mostly End of section 1, whole sections 2 and 3).
>> 
>
>okay.
>
>> Title changed into:
>> Evaluation of existing GMPLS encoding against G.709v3 Optical 
>> Transport Networks (OTN)
>> 
>> And abstract into:
>> [...]
>>    This document provides an evaluation of existing Generalized
>>    Multiprotocol Label Switching (GMPLS) routing and 
>signaling methods
>>    against the G.709-2012 OTN networks.
>> 
>
>okay.
>
>>>
>>> - The document should be reviewed by the authors to ensure it is 
>>> consistent with the latest solutions documents and WG discussions.  
>>> For example, there are multiple references to the contentious and 
>>> much discussed "penultimate hop" case without any references to the 
>>> agreed upon approach.
>> 
>> Done. Please see section 3.2
>> 
>
>There still a number of instances where  penultimate hop 
>section of interface is mentioned.  As we discussed on the 
>list, this issue actually exists for any node that is 
>selecting the egress' nodes incoming interface.  This can be 
>at the ingress (in setting an ERO), a transit node (doing ERO 
>expansion), or the penultimate hop.  So there are some 
>additional fixes needed.
>

OK. When penultimate node is mentioned the text is changed so to say that it's also an issue 
of any intermediate node performing ERO expansions. It should not be an ingress
Node issue as the ingress is aware of the hierarchty.

>>>
>>> Editorial comments:
>>>
>>> - Please verify that abbreviations are defined before being used .
>>> There are a number of these.
>> 
>> Done
>>>
>>> - Please use a consistent decimal representation (sometimes commas 
>>> are used other times periods)
>
>There are instances where this is still an issue, e.g., search 
>for 1,25.
>
ok

>>>
>>> - the references [G709-v1] and [G709-v3] each actually refer to 
>>> multiple documents, each documented needs to have it's own
>>> (correct) reference, i.g., [G709-v1] and [G709-v1a1]. The document 
>>> text will need to be revisited to ensure the proper reference is 
>>> made.
>> 
>> RFC4328 for older versions of G709 and G709-2012 for the latest one 
>> (v4)
>> 
>
>great.
>
>>>
>>> -
>>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft
>> -ietf-ccamp-otn-g709-info-model-04.txt
>>> shows there are unresolved nits that need to resolved .  I'm using 
>>> line numbers from this url in my subsequent comments.
>>>
>>> Line 18: Suggest dropping "The recent revision of"
>>>
>
>This chance was not made, was this intentional? (and this 
>terminology continues to be used.)  -- Yes this is a style 
>comment -- so ignore as you see fit.

Just missed it. It was removed and just reference to 709-2012 left.

>
>>> Line 20/21: Suggest dropping the marketing phrase "enabling 
>optimized 
>>> support for an increasingly abundant service mix."
>>>
>
>This chance was not made, was this intentional?  I think form 
>of "marketing" doesn't belong in an PS -- just MO.

removed

>
>>> Lines 93-127 (through "of"): I don't see how this text provides any 
>>> value.  I suggest dropping it, or at most just reference the FWK 
>>> document.
>
>No real change here.  This text remains.  Why are LSA types 
>mentioned here at all? They aren't mentioned in the body of 
>the document so should be removed.

Agree. Removed.

>
>>>
>>> Lines 319-341: Instances of "G.709" should be "[G.709-V3]"
>>>
>
>still missing '[]'
>
>[...]
>

Last chages turned G.709 into G.709-2012. 

>Thanks I think that's it.
>Lou
>
>
>> 
>>>
>>> That's it on this document.
>>>
>>> Lou
>> 
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of Lou Berger
>>> Sent: giovedì 20 dicembre 2012 0.27
>>> To: [email-masked]; 
>>> [email-masked]
>>> Subject: Re: [CCAMP] I-D Action: 
>>> draft-ietf-ccamp-otn-g709-info-model-05.txt
>>>
>>> Authors?
>>>
>>> On 12/4/2012 3:31 PM, Lou Berger wrote:
>>>> Authors,
>>>> 	Please review any changes and how LC comments are addressed.
>>>>
>>>> Thank you,
>>>> Lou
>>>>
>>>> On 11/28/2012 2:36 AM, [email-masked] wrote:
>>>>>
>>>>> 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           : Evaluation of existing GMPLS encoding 
>>> against G.709v3 Optical Transport Networks (OTN)
>>>>> 	Author(s)       : Sergio Belotti
>>>>>                           Pietro Vittorio Grandi
>>>>>                           Daniele Ceccarelli
>>>>>                           Diego Caviglia
>>>>>                           Fatai Zhang
>>>>>                           Dan Li
>>>>> 	Filename        : draft-ietf-ccamp-otn-g709-info-model-05.txt
>>>>> 	Pages           : 22
>>>>> 	Date            : 2012-11-27
>>>>>
>>>>> Abstract:
>>>>>    The recent revision of ITU-T recommendation G.709
>>> [G.709-2012] has
>>>>>    introduced new fixed and flexible Optical Data Unit
>>> (ODU) containers
>>>>>    in Optical Transport Networks (OTNs), enabling optimized
>>> support for
>>>>>    an increasingly abundant service mix.
>>>>>
>>>>>    This document provides an evaluation of existing Generalized
>>>>>    Multiprotocol Label Switching (GMPLS) routing and
>>> signaling methods
>>>>>    against the G.709-2012 OTN networks.
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>>
>>> 
>https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-g709-info-model
>>>>>
>>>>> There's also a htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-05
>>>>>
>>>>> A diff from the previous version is available at:
>>>>>
>>> 
>http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-otn-g709-info-model
>>>>> -05
>>>>>
>>>>>
>>>>> 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
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>> 
>> 
>> 
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 11 Jan 2013 16:00:54 -0500

Daniele,

See below for detailed responses.  Also, look to
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-otn-g709-info-model-06.txt
for nits.

Much thanks,
Lou

On 1/11/2013 10:20 AM, Daniele Ceccarelli wrote:
>  Hi Lou,
> 
> Please see in line.
> 
> Please also note that the references to G.798 amd2 and G.872 amd2
> were changed into G.798 new revision and G.872 new revision.
> 

okay.  Whichever is most accurate should be listed.

> The first one is pre-published on the ITU-T ties web page and will be
> officially published on January 16th, while G.872 was published in
> October. Both of them are actually available for ties users only.
> 

I believe the 1st has been covered in today's on-list discussion.  The
second was sent over already (thanks to Malcolm!) in
https://datatracker.ietf.org/liaison/1204/

> These are the documents that should be requested to be publicly
> available (no clue on when they will be available and if it is worth
> waiting for them or a liaison might be more useful).
> 

Based on today's discussion, I think we're fine.

> Node issue as the ingress is aware of the hierarchty.

I think maintains the references to "penultimate node" may perpetuate
the confusion that resulted in so much discussion.  How about:

OLD
   to permit the penultimate hop
   choosing the correct interface towards the egress node or any
   intermediate node choosing the right path when performing ERO
   expansion
NEW
   to enable a downstream node to choose an appropriate interface, or
   interfaces, towards the egress node.

OLD
   The signaled TSGs information is not enough to have a complete choice
   since the penultimate hop node (or any intermediate node performing
   ERO expansion) has
NEW
   Signaled TSGs information is insufficient to completely identify
   interfaces that support the LSP's adaptation requirements as any
   downstream node performing ERO expansion has

OLD
   In this way, when
   the penultimate node (or the intermediate node performing ERO
   expansion) receives such object, together with the Traffic Parameters
   Object, is allowed to choose the correct interface towards the egress
   node.
NEW
   Such an object, together with the Traffic Parameters object,
   would enable any downstream node that performs ERO expansion to
   choose an appropriate interface, or interfaces, towards the egress
   node.

>> There are instances where this is still an issue, e.g., search 

s/2,5/2.5

> Just missed it. It was removed and just reference to 709-2012 left.

No problem.

> Last chages turned G.709 into G.709-2012. 

non sequitur...

Much thanks.
Lou