Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 21 August 2013 17:30 UTC

Return-Path: <adrian@olddog.co.uk>
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 E5A9411E8120 for <ccamp@ietfa.amsl.com>; Wed, 21 Aug 2013 10:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level:
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599]
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 aU8Q9XwgYwpF for <ccamp@ietfa.amsl.com>; Wed, 21 Aug 2013 10:30:34 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB6E11E80FA for <ccamp@ietf.org>; Wed, 21 Aug 2013 10:30:32 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7LHUTmt021340; Wed, 21 Aug 2013 18:30:29 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7LHUSYt021323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Aug 2013 18:30:28 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Lou Berger'" <lberger@labn.net>, "'Daniele Ceccarelli'" <daniele.ceccarelli@ericsson.com>
References: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> <51F94497.8010402@labn.net> <044501ce9c3d$48007250$d80156f0$@olddog.co.uk> <5212818C.8030409@labn.net> <4A1562797D64E44993C5CBF38CF1BE481443D9@ESESSMB301.ericsson.se> <52137CD5.7000206@labn.net> <2517783c.1377099588810@mail.labn.net>
In-Reply-To: <2517783c.1377099588810@mail.labn.net>
Date: Wed, 21 Aug 2013 18:30:26 +0100
Message-ID: <013401ce9e94$20850520$618f0f60$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIXx93VA/UdhQko2wImjUTLAiqMbQK/MUvxAZHZ7gEBQfO11AHnqtqbAcOLrCMBduV/kgG5y/GfmKohKMA=
Content-Language: en-gb
Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org, ccamp@ietf.org
Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Wed, 21 Aug 2013 17:30:40 -0000

Go for it.

Thanks,
Adrian

> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: 21 August 2013 16:41
> To: Daniele Ceccarelli
> Cc: adrian@olddog.co.uk; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org;
> ccamp@ietf.org
> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model
> 
> Great! I think this closes the issue. As Adrian raised it we should confirm with him
> too.
> 
> Adrian?
> 
>  Thanks,
> Lou
> 
> On 10:39am, August 21, 2013, Daniele Ceccarelli wrote:
> > Lou,
> >
> > I've applied the text changes you proposed and added RFC1195 and RFC5307 as
> normative (correct?) references.
> >
> > If there is no other comment i go ahead with the ID submission.
> >
> > Thanks
> > Daniele
> >
> > > -----Original Message-----
> > > From: Lou Berger [mailto:lberger@labn.net]
> > > Sent: martedì 20 agosto 2013 16:28
> > > To: Daniele Ceccarelli
> > > Cc: adrian@olddog.co.uk; draft-ietf-ccamp-otn-g709-info-
> > > model@tools.ietf.org; ccamp@ietf.org
> > > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model
> > >
> > > Daniele,
> > > Thanks for looking at this.  I think we're almost there.  See below for
> > > details that hopefully let us close on this.
> > >
> > > On 8/20/2013 3:18 AM, Daniele Ceccarelli wrote:
> > > > Lou, Adrian,
> > > >
> > > > > > It may be the case that only a small proportion of CCAMP is
> > > > > > interested in IS-IS, and it may be the case that the intersection of
> > > > > > those people with those interested in OTN is vanishingly small. If
> > > > > > that is the case
> > > >
> > > > I think that's the case
> > > >
> > > > > > (I guess Lou can find out) we should excuse IS-IS in a more open and
> > > > > > blatant way while soliciting and offering to help work on IS-IS for OTN.
> > > >
> > > > I've searched the words routing and OSPF in the text. The word routing
> > > occurs 13 times (6 meaningful, i.e. not references, abstract etc) and OSPF 11
> > > times (4 meaningful).
> > > >
> > >
> > > I think you need to expand your search to include [RFC4203].
> > >
> > > s/as defined by [RFC4203],/as defined by [RFC4203], [RFC5307],
> > >
> > > s/[RFC4203] only allows/GMPLS OSPF [RFC4203] and GMPLS IS-IS [RFC5307]
> > > only allow
> > >
> > > s/tools provided by [RFC4203]/tools provided by [RFC4203] and [RFC5307]
> > >
> > > s/the OSPF-TE extensions defined in [RFC4203] require/the routing
> > > extensions defined in [RFC4203] and [RFC5307] require
> > >
> > > s/[RFC4202] and [RFC4203]/[RFC4202], [RFC4203] and [RFC5307]
> > >
> > > Can now drop:
> > >
> > > As far as it concerns routing, analogous considerations apply to
> > > IS-IS [RFC5307] but in the following only a gap analysis with respect
> > > to OSPF-TE is provided.
> > >
> > > > We might focus on the meaningful ones and see where IS-IS can be
> > > brought in.
> > > >
> > > > -Routing occurrence #6
> > > > "ODU3 H-LSP is eligible from ODU2 LSP
> > > > perspective since from the routing it is known that this ODU3
> > > > interface at node Z, supports an ODU2 termination exporting a TS
> > > > granularity 1.25Gbps/2.5Gbps."
> > > > [DC] it should be generic enough to cover both OSPF and IS-IS
> > > >
> > > > -Routing occurrence #7
> > > > "The TS granularity information is needed in the routing protocol as
> > > > the ingress node (A in the previous example) needs to know"
> > > > [DC] it should be generic enough to cover both OSPF and IS-IS
> > > >
> > > > -Routing occurrences #8 and #9
> > > > "In conclusion both routing and signaling needs to be extended to
> > > > appropriately represent the TS granularity/PT information.  Routing
> > > > needs to represent a link's TS granularity and PT capabilities as
> > > > well as the supported multiplexing hierarchy"
> > > > [DC] it should be generic enough to cover both OSPF and IS-IS
> > > >
> > > > -Routing occurrence #10
> > > > " From a routing perspective, [RFC4203] allows advertising [RFC4328]
> > > > interfaces (single TS type) without the capability of providing
> > > > precise information about bandwidth specific allocation."
> > > > [DC] We could change this into:
> > > > " From an OSPF perspective, [RFC4203] allows advertising [RFC4328]
> > > > interfaces (single TS type) without the capability of providing
> > > > precise information about bandwidth specific allocation. In the case of
> > > > IS-IS no extension is defined for [RFC4328].
> > > >
> > >
> > > see above for an alternate proposal.
> > >
> > > > - Routing occurrence #11
> > > > "With respect to the routing, please note that in case of multi stage
> > > > multiplexing hierarchy (e.g.  ODU1->ODU2->ODU3), not only the ODUk/
> > > > OTUk bandwidth (ODU3) and service layer bandwidth (ODU1) are
> > > needed,
> > > > but also the intermediate one (ODU2).  This is a typical case of
> > > > spatial allocation problem."
> > > > [DC] it should be generic enough to cover both OSPF and IS-IS
> > >
> > > should be "With respect to routing," (drop the)
> > > >
> > > > - OSPF occurrence #3
> > > > "In conclusion, the OSPF-TE extensions defined in [RFC4203] require a
> > > > different ISCD per signal type in order to advertise each supported
> > > > container."
> > > > [DC] We could change this into:
> > > > "In conclusion, the OSPF-TE extensions defined in [RFC4203] require a
> > > > different ISCD per signal type in order to advertise each supported
> > > > container, while in the case of IS-IS... (suggestions welcome).
> > > >
> > >
> > > see above.
> > >
> > > > - OSPF occurrence #4
> > > > "Per [RFC2328], OSPF messages are directly encapsulated in IP
> > > > datagrams and depend on IP fragmentation when transmitting packets
> > > > larger than the network MTU."
> > > > - OSPF occurrences #5 and #6
> > > > "[RFC2328] recommends that "IP
> > > > fragmentation should be avoided whenever possible."  This
> > > > recommendation further constraints solutions as OSPF does not support
> > > > any generic mechanism to fragment OSPF LSAs."
> > > > [DC] I only could find an expired draft regarding IS-IS encapsulation
> > > > in IP datagrams
> > > >
> > >
> > > Per [RFC2328] should start a new paragraph.
> > >
> > > You could add. "Even when used in IP environments IS-IS [RFC1195], does
> > > not support message sizes larger than a link's maximum frame size."
> > >
> > > I think that's it.
> > >
> > > Lou
> > >
> > > > BR
> > > > Daniele
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Lou Berger [mailto:lberger@labn.net]
> > > > > Sent: lunedì 19 agosto 2013 22:35
> > > > > To: adrian@olddog.co.uk; Daniele Ceccarelli;
> > > > > draft-ietf-ccamp-otn-g709-info- model@tools.ietf.org
> > > > > Cc: ccamp@ietf.org
> > > > > Subject: Re: [CCAMP] AD review of
> > > > > draft-ietf-ccamp-otn-g709-info-model
> > > > >
> > > > > Adrian,
> > > > >
> > > > > I suspect that we've been hit by some post-IETF vacationing.
> > > > >
> > > > > Daniele, Authors,
> > > > >
> > > > > Any additional thoughts on this one remaining open issue?
> > > > >
> > > > > Thanks,
> > > > > Lou
> > > > >
> > > > > On 8/18/2013 2:03 PM, Adrian Farrel wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > > > At the end of the intro we added the following sentence:
> > > > > > > > "  As far as it concerns routing, analogous considerations apply to IS-
> IS
> > > > > > > > [RFC5307] but in the following only a gap analysis with respect
> > > > > > > > to OSPF-TE
> > > > > > is
> > > > > > > > provided."
> > > > > > > >
> > > > > > >
> > > > > > > Given that the analysis for 5307 is pretty similar to 4203, I think
> > > > > > > you should take a pass at including it as well.  I'm happy to
> > > > > > > review/contribute as needed.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Lou (chair & doc shepherd)
> > > > > >
> > > > > > Was there any further progress on this?
> > > > > >
> > > > > > I see that the current revision addresses all other points. The note
> > > > > > added to excuse mentioning IS-IS is a bit skinny, and I would not
> > > > > > like to bet money on you having actually done the analysis to
> > > > > > support adding it :-)
> > > > > >
> > > > > > It may be the case that only a small proportion of CCAMP is
> > > > > > interested in IS-IS, and it may be the case that the intersection of
> > > > > > those people with those interested in OTN is vanishingly small. If
> > > > > > that is the case (I guess Lou can find out) we should excuse IS-IS
> > > > > > in a more open and blatant way while soliciting and offering to help work
> > > on IS-IS for OTN.
> > > > > >
> > > > > > Cheers,
> > > > > > Adrian
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > >
> >