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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 18 Aug 2013 19:03:44 +0100

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

---

From: Lou Berger <[email-masked]>
Date: Mon, 19 Aug 2013 16:35:24 -0400

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 20 Aug 2013 07:18:12 +0000

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:[email-masked]]
> Sent: lunedì 19 agosto 2013 22:35
> To: [email-masked]; Daniele Ceccarelli; draft-ietf-ccamp-otn-g709-info-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model
> 
> Adrian,
> 
> >> 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
> > 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
> >
> >
> >
> >
> >

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Aug 2013 10:27:33 -0400

Daniele,
	Thanks for looking at this.  I think we're almost there.  See below for
details that hopefully let us close on this.

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

>   IS-IS no extension is defined for [RFC4328].

see above for an alternate proposal.

> [DC] it should be generic enough to cover both OSPF and IS-IS

should be "With respect to routing," (drop the)
>    container, while in the case of IS-IS... (suggestions welcome).

see above.

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 21 Aug 2013 14:39:30 +0000

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

> Sent: martedì 20 agosto 2013 16:28
> To: Daniele Ceccarelli
> Cc: [email-masked]; draft-ietf-ccamp-otn-g709-info-
> [email-masked]; [email-masked]
> >>> 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'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).
> >
> 
> >> To: [email-masked]; Daniele Ceccarelli;
> >> draft-ietf-ccamp-otn-g709-info- [email-masked]
> >> Cc: [email-masked]
> >>> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >

---

From: Lou Berger <[email-masked]>
Date: Wed, 21 Aug 2013 11:40:51 -0400 (EDT)

Great! I think this closes the issue. As Adrian raised it we should confirm with him too. 

Adrian?

 Thanks,
Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 21 Aug 2013 18:30:26 +0100

Go for it.

Thanks,
Adrian

> Sent: 21 August 2013 16:41
> To: Daniele Ceccarelli
> Cc: [email-masked]; [email-masked];
> [email-masked]