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

[Daniele Ceccarelli <[e-mail]>]

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).

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].

- 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

- 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).

- 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

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
> >
> >
> >
> >
> >