Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ospf-g709v3

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Tue, 27 August 2013 15:00 UTC

Return-Path: <daniele.ceccarelli@ericsson.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFCA11E8381 for <ccamp@ietfa.amsl.com>; Tue, 27 Aug 2013 08:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEPwq6T57KOd for <ccamp@ietfa.amsl.com>; Tue, 27 Aug 2013 08:00:33 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7664D11E836F for <ccamp@ietf.org>; Tue, 27 Aug 2013 08:00:32 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-ae-521cbf0a74cb
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8E.0E.03802.A0FBC125; Tue, 27 Aug 2013 17:00:26 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Tue, 27 Aug 2013 17:00:26 +0200
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org>
Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ospf-g709v3
Thread-Index: Ac6gLgpkZoIREJ3nTwOKEbtl2Arm1AC60ZZg
Date: Tue, 27 Aug 2013 15:00:25 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE4814ACAB@ESESSMB301.ericsson.se>
References: <04eb01cea02e$0d005b30$27011190$@olddog.co.uk>
In-Reply-To: <04eb01cea02e$0d005b30$27011190$@olddog.co.uk>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjS7Xfpkgg+Y7ChY/em4wWzyZc4PF 4m/DaxYHZo8lS34yeazYvJLR48vlz2wBzFFcNimpOZllqUX6dglcGbNeT2QvWOFVMenMZ6YG xlWWXYycHBICJhKrj0xmgbDFJC7cW88GYgsJHGaU2NDo38XIBWQvYZR4PXUNUIKDg03ASuLJ IR+QuIjAHEaJD1umMoM0MAuoSrRdP8UKUiMs4CLR8LMIJCwi4Cpxdu4iJgjbSOLgqiNg5SxA 5T9/TmEEsXkFvCVaL61gAmkVAhr/YKcLSJhTwFpiefNzsHMYBWQlJuxexAixSVzi1pP5TBAn C0gs2XOeGcIWlXj5+B8rhK0o0f60AapeT+LG1ClsELa2xLKFr5kh1gpKnJz5hGUCo9gsJGNn IWmZhaRlFpKWBYwsqxjZcxMzc9LLjTYxAmPm4JbfqjsY75wTOcQozcGiJM67We9MoJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbGKqWO/OzqUyni3/9JBu6NO7ptSmVL2G2uN2em5XGK3Lsi tUXrru1r5s7aRRv3T+GzKMhWfuLUVBq/ord2ruf/RIYpiwOuOtw+3+ub1NcV47Kr1Sn1y+Vv P+Vv7V0naPpp5cbdoqkTU5TYz26oXPhSx32DD5cP4+pTTYzrzjdOm2V/Zt1FW745SizFGYmG WsxFxYkAnlQ8xWcCAAA=
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ospf-g709v3
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2013 15:00:38 -0000

Hi Adrian,

Thanks for the review. Let's see in line if I manage to convince you.

BR
Daniele

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Adrian Farrel
> Sent: venerdì 23 agosto 2013 20:25
> To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org
> Cc: ccamp@ietf.org
> Subject: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ospf-g709v3
> 
> Hi authors and working group,
> 
> I have done my usual AD review on receiving a publication request for this
> document to smooth out any issues before IETF last call and IESG evaluation.
> 
> As you'll see below, I have a few small issues that I would like to work
> through.  The result will either be some email discussion where you convince
> me that no change is needed, or a revised version of the document.
> 
> Thanks for the work,
> Adrian
> 
> ===
> 
> I have a thread with the authors about why they need to list nine authors on
> the front page. The RFC Editor has a norm of no more than five unless there
> is a specific reason.
> 
[[DC]] working on that to reduce to <=5

> ---
> 
> This document does not update 4203. Extending mechanisms is not an
> update, and this document doesn't really even extend the mechanisms; it
> simply defines a new ISCD and describes how it is used.
[[DC]] Reasonable. Removed.
> 
> ---
> 
> Section 2 has a reference to [swcaps-update]. I suspect this is meant to be
> draft-ietf-ccamp-swcaps-update.  You need to add this to the informative
> references section.
> 
[[DC]] added
> ---
> 
> Section 2 is wrongly named! The section does describe the requirements, but
> there is actually nothing in the section that is specific to OSPF and certainly no
> description of OSPF extensions.
> 
> I found the material useful, but wondered why it was in this document and
> not in the information model document since it perfectly describes the
> information model that needs to be applied.  I am not requiring you to do
> anything about this, but I would ask you think hard about whether this text
> should be moved to the other document and simply pointed to from here.

[[DC]] you're right, there is no OSPF extension but I think the section is a good intro to what comes next.
How about deleting section 2 and moving all the text at the end of the intro? (section1).


> 
> ---
> 
> Section 3 is a fine and concise section. But it seems to me that this material
> also belongs in the information model document, not here.
> Again, I am not requiring you to make a change here, but please think about
> whether the section could be moved and replaced with a pointer.

[[DC]] Maybe this one is a better candidate for moving to the info model draft. How about between section 2 and section 3 of the info model draft?

> 
> ---
> 
> Section 4
> 
> OLD
>    - Encoding Type = G.709 ODUk (Digital Path) [as defined in RFC4328] NEW
>    - Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328] END
> 
[[DC]] ok
> ---
> 
> The description of the table in section 4 caused me some grief. You have...
> 
>    The bandwidth unit is in bytes per second and the encoding MUST
>    be in Institute of Electrical and Electronic Engineers (IEEE)
>    floating point format.  The discrete values for various ODUs is shown
>    in the table below.
> 
> Could you please do two things:
> 
> 1. Remind the reader that there are 1000 bits in a kbit according to
>    normal practices in telecommunications. (Probably add a note to the
>    quoted text.)
> 2. Clarify that the third column shows a floating point value. (Update
>    the column heading.)
> 
[[DC]] done
> 
> However, I do also note that the use of bandwidth in section 4.1.3 are
> described as (for example)...
> 
>       This field
>       MUST be set to the bandwidth, in bits/s in IEEE floating point
>       format, available at the indicated Signal Type for a particular
>       priority level.
> 
> So you also need to sort that out.

[[DC]] right, either we need to express the bandwidth in bits/s or bytes/sec everywhere. Any preference? Bytes/sec is ok? 

> 
> ---
> 
> Section 4.
> In the table, could you fix up the notation of ODU3 to use 0x not 0X
> 
[[DC]] done
> ---
> 
> I wonder whether the text and figure for the example in Figure 10 needs its
> own section.
> 
[[DC]] the whole example 5.2.1 is an example of different TS granularities utilization. Figure 9 shows the encoding and figure 10 shows when such a can occur. I would say it make sense to have them in the same section but I am open to change if needed. 
> ---
> 
> I think there are some issues (or possibly some unspoken points) with
> section 6.
> 
> 1. Suppose you have an old implementation. How will it treat these new
>    advertisements?
>    For this you are just stating facts. There is nothing you can define
>    because you cannot influence how old implementations work. But you
>    can say how they will behave according to existing specs.

[[DC]] don't remember if unknown values are silently discarded or blindly forwarded but if we say something we fall in the same issue of information repeated over different documents. I.e. if some day RFC4203 is updated we need to update this id also. Maybe we could say that "old nodes" behave as described in RFC4203

> 
> 2. If a new implementation only supports this spec and not RFC 4328 how
>    will it handle an RFC 4328 advertisement?
>    This is something you can and must describe.

[[DC]] ok. How about: 
"All implementations of this document MAY support also advertisement as
    defined in RFC4328. In case they don't, they MUST flood OSPF message without modifying them. "

> 
> 3. For a new implementation that supports this spec and RFC 4328, I don't
>    understand what you have written.
> 
>      When nodes support both advertisement
>      methods, implementations MUST support the configuration of which
>      advertisement method is followed.
> 
>    I *think* this says that
>    - a node MUST NOT use more than one advertisement method to advertise
>      the resources on a single OTN link
>    It also appears to say that
>    - a node MUST NOT use more than one advertisement method to advertise
>      across *all* of its advertisements

[[DC]]  How about:
  " When nodes support both advertisement
    methods, they MUST NOT use more than one advertisement method to advertise
   the resources on a single OTN link and across all of its advertisements.

> 
>    You go on to say...
> 
>      This enables
>      nodes following each method to identify similar supporting nodes
>      and compute paths using only the appropriate nodes.
> 
>    ...which seems to imply that it is not possible to compute a path
>    end-to-end across nodes using a mix of the old and new advertisement
>    types. Is that *really* what you want to say?

[[DC]] An old node cannot understand new advertisement, hence can only establish lsps along a path of old nodes only.
A new node may not understand old advertisement and hence only e able to setup an lsp along a path of new nodes only.
If a new node understands old advertisement it is possible to setup lsps along a path including a mix of new and old nodes.
This is the idea. If it is acceptable could you please help me with some text clearly stating it?

> 
> ---
> 
> It might be helpful to break section 8 into subsections.
> 
[[DC]] switching types and new tlvs I guess. Correct?
> ---
> 
> Section 8
> 
> For the new Switching Type you need to remind IANA to make the update in
> the IANA-GMPLS-TC-MIB at
> https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib
> 
[[DC]] ok
> ---
> 
> Section 8
> 
> 
>    Upon approval of this document, IANA will create and maintain a new
>    registry, the "Types for sub-TLVs of OTN-TDM SCSI (Switch Capability
>    Specific Information)" registry under the "Open Shortest Path First
>    (OSPF) Traffic Engineering TLVs" registry, see http://www.iana.org/
>    assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xml, with the
>    TLV types as follows:
> 
> 
>       This document defines new TLV types as follows:
> 
>    Value      Sub-TLV                       Reference
>    ---------  --------------------------    ----------
>    0           Reserved                     [This.I-D]
> 
> 1. What does "Reserved" mean? Does it mean "Reserved and not to be
>    allocated"? Does it mean "Reserved but a future RFC may assign it"?
>    Does it mean "Unassigned and available for normal allocation"?
>    You need to decide and make it clear for IANA

[[DC]] personally don't care. Looking at recent RFCs I only found "reserved". Suggestions are welcome.

> 
> 2. IANA will need to know what the range of available values is.
>    3 up to what limit?

[[DC]]  I've added: 
3-65535	    Unassigned. 
We might consider splitting into two ranges. A range unassigned and one for experimental use? (just loud thinking). Suggestions?
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp