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

[Daniele Ceccarelli <[e-mail]>]

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:[e-mail]]
> Sent: martedì 20 agosto 2013 16:28
> To: Daniele Ceccarelli
> Cc: [e-mail]; draft-ietf-ccamp-otn-g709-info-
> [e-mail]; [e-mail]
> 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:[e-mail]]
> >> Sent: lunedì 19 agosto 2013 22:35
> >> To: [e-mail]; Daniele Ceccarelli;
> >> draft-ietf-ccamp-otn-g709-info- [e-mail]
> >> Cc: [e-mail]
> >> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >