Subject: [CCAMP] some comments on gmpls-ospf-g709v3-00

From: Lou Berger <[email-masked]>
Date: Tue, 25 Oct 2011 18:37:12 -0400

Authors,
	Nice job bringing this work to the point where it's been accepted as a
WG draft.  I have a few technical comments/questions on the draft that
I'd like to discuss with you and the WG (with chair hat off):

1) Switching types/caps

You say:
   A single ISCD MAY be used for the advertisement of unbundled or
   bundled links supporting homogeneous multiplexing hierarchies and the
   same Tributary Slot Granularity (TSG).  A different ISCD MUST be used
   for each different muxing hierarchy (muxing tree in the following
   examples) and different TSG supported within the TE Link, if it
   includes component links with differing characteristics.

Given this restriction why not use different switch caps, one for each
ODU (H) type, all which use the same ISCD format?

Unless I'm mistaken this would simplify operation in the simple/single
layer cases.  It also doesn't add any real complexity to the more
complex cases.  (For example, in your example the switch cap would be
set to correspond to the signal type used with #stages=0.)

3) SCSI TLV formatting

The field descriptions are missing format related conformance (RFC2119)
language.

3) SCSI TLV procedures

You have defined the formats of the TLVs in Section 4.1, but not
explicitly how they are to be used.  Some RFC2119 language really is
needed to cover how the SCSI is to be encoded and parsed.  At a minimum,
any TLV inclusion, ordering requirements, and exception handling should
be covered.  (For example, your examples always show a particular
ordering relative to Stage#, is this required, recommended, or just a
possibility.  You have some informative language, which is great, but
you also need some RFC2119 language.)

4) Type 2 and Type 3 TLVs

It seems that type 2 and type 3 TLVs are used in tandem, i.e., both are
either present or absent.  Is this correct?  If so, they should be
combined into a single TLV to simplify operation (e.g., there is no
error case where only one is present to check for.)

5) Note that the Encoding field may be impacted by the still unresolved
discussion related to TSG/PT that took place a couple of weeks ago on
the list.  (I'm personally leaning towards representing PT in encoding
as this better matches what happens in the data plane and is more
closely aligned to the general definition of the encoding field.)

6) Finally, some nits:
s/[OTN-INFO], the OSPF-TE/[OTN-INFO], OSPF-TE
s/list of them/list
s/Priority :8 bits/Priority (8 bits):
s/infer/imply

Much thanks,
Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 28 Oct 2011 12:18:29 +0200

Hi Lou,

Thanks for the careful review, please find comment/replies in line [DSP]

Daniele, Sergio, Pietro 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: mercoledì 26 ottobre 2011 0.37
To: [email-masked]
Cc: CCAMP
Subject: [CCAMP] some comments on gmpls-ospf-g709v3-00

Authors,
	Nice job bringing this work to the point where it's been accepted as a WG draft.  I have a few technical comments/questions on the draft that I'd like to discuss with you and the WG (with chair hat off):

1) Switching types/caps

You say:

Given this restriction why not use different switch caps, one for each ODU (H) type, all which use the same ISCD format?

Unless I'm mistaken this would simplify operation in the simple/single layer cases.  It also doesn't add any real complexity to the more complex cases.  (For example, in your example the switch cap would be set to correspond to the signal type used with #stages=0.)

[DSP] - It was present in an older version but we don't recall why we were asked to use a single switching capability. We have no objection with your proposal.

2) SCSI TLV formatting

The field descriptions are missing format related conformance (RFC2119) language.

[DSP] - Ok, will be fixed.

3) SCSI TLV procedures

You have defined the formats of the TLVs in Section 4.1, but not explicitly how they are to be used.  Some RFC2119 language really is needed to cover how the SCSI is to be encoded and parsed.  At a minimum, any TLV inclusion, ordering requirements, and exception handling should be covered.  (For example, your examples always show a particular ordering relative to Stage#, is this required, recommended, or just a possibility.  You have some informative language, which is great, but you also need some RFC2119 language.)

[DSP] - Ok 

It seems that type 2 and type 3 TLVs are used in tandem, i.e., both are either present or absent.  Is this correct?  If so, they should be combined into a single TLV to simplify operation (e.g., there is no error case where only one is present to check for.)

[DSP] - Type 2 and 3 refer to ODUflex, where the MAX LSP bandwdith is a required information, while the Unreserved Bandwidth is desired but does not give enough information on the number of ODUflex LSPs that can be carried over the advertised link. In other words there could be implementations using both of them and other using just the MAX LSP Bandwidth info. We could say that the Unreserved Bandwidht TLV (Type 2) is optional.

5) Note that the Encoding field may be impacted by the still unresolved discussion related to TSG/PT that took place a couple of weeks ago on the list.  (I'm personally leaning towards representing PT in encoding as this better matches what happens in the data plane and is more closely aligned to the general definition of the encoding field.)

[DSP] - This doc will be updated accordingly to the decision. Note taken!

6) Finally, some nits:
s/[OTN-INFO], the OSPF-TE/[OTN-INFO], OSPF-TE s/list of them/list s/Priority :8 bits/Priority (8 bits):
s/infer/imply

[DSP] - Ok

Much thanks,
Lou
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp