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

[Lou Berger <[e-mail]>]

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