Subject: [CCAMP] Current WSON WG encoding with many types of regenerators

From: Greg Bernstein <[email-masked]>
Date: Tue, 05 Jul 2011 08:24:44 -0700

Hi CCAMPers in Peloso-03 it was claimed that there was some type of 
issue with the current WG WSON drafts when multiple types of 
regenerators or wavelength converters are used in an optical system of 
some sort.  This is not true. The current WSON related WG drafts provide 
mechanisms commonly used in GMPLS routing and signaling. However these 
mechanisms do not furnish a "unique representation" of a given problem 
and never have. It is up to the user of the GMPLS routing or signaling 
protocol to choose the most appropriate mechanism, e.g., "range" or 
"list" to achieve an efficient encoding. Note that this is true of many 
standards beyond GMPLS.

In the enclosed note we show how a degree 4 optical node with resource 
pool connectivity constraints and multiple types of resources (10 or 
more different types of wavelength converters in this case) can be 
efficiently encoded. We also demonstrate that this encoding is 
minimalistic.  The analysis proceeds from a high level description of 
the system including a block diagram of system structure, and includes 
descriptions of the pertinent sub-TLVs used from the existing WSON WG 
documents, and their scaling properties.  As such one can see that the 
current WSON WG drafts excel in their ability to handle this case 
without further modification.l

Best Regards

Greg

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Fri, 8 Jul 2011 18:22:48 +0200

Hi Greg and CCAMPer's

Thanks for your example, which is as you said really specified.
We then took the opportunity to work on this example with our own solution, and to do the compilation of size. 

---------------------------------------------------
Summary of information flooded with solution depicted in draft-peloso:
   - 1 static node attribute LSA: 108 bytes 
   - 1 static resource description container LSA: 1004 bytes 
   - 4 dynamic resource pool LSAs: 132 bytes each 
  Total size: 1640 bytes
  Size of update: 132 bytes

Summary of information flooded with solution depicted in current WG drafts:
   - 1 dynamic optical property LSA: 1540 bytes
  Total size: 1540 bytes
  Size of update: 1540 bytes

The solution here are comparable regarding the overall size usage, 100 bytes at the advantage of Greg's solution.
Ours focuses on reducing the size of updated information, with an intrinsic mechanism to perform the updates, without ambiguity for the flooding and merges.
To avoid the pitfall introduced by the number of resources being defined in the resource block information, the example provided by Greg had to assign a Resource Block for each Wavelength Converter (200 in that case), then as many Resource Block IDs, and to enforce an appropriate Resource Block ID ordering that enables the usage of inclusive range for the definition of Resource Block Sets. This trick applied to other node's architecture, would have contrary effect on size. This point is being commented with others inside the annoted version of Greg's example.

Regards,

- p

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Greg Bernstein
Envoyé : mardi 5 juillet 2011 17:25
À : CCAMP
Objet : [CCAMP] Current WSON WG encoding with many types of regenerators

Hi CCAMPers in Peloso-03 it was claimed that there was some type of issue with the current WG WSON drafts when multiple types of regenerators or wavelength converters are used in an optical system of some sort.  This is not true. The current WSON related WG drafts provide mechanisms commonly used in GMPLS routing and signaling. However these mechanisms do not furnish a "unique representation" of a given problem and never have. It is up to the user of the GMPLS routing or signaling protocol to choose the most appropriate mechanism, e.g., "range" or "list" to achieve an efficient encoding. Note that this is true of many standards beyond GMPLS.

In the enclosed note we show how a degree 4 optical node with resource pool connectivity constraints and multiple types of resources (10 or more different types of wavelength converters in this case) can be efficiently encoded. We also demonstrate that this encoding is minimalistic.  The analysis proceeds from a high level description of the system including a block diagram of system structure, and includes descriptions of the pertinent sub-TLVs used from the existing WSON WG documents, and their scaling properties.  As such one can see that the current WSON WG drafts excel in their ability to handle this case without further modification.l

Best Regards

Greg

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 13 Jul 2011 12:58:22 -0700

Once again Pierre your dynamic numbers are wrong for the current WG 
draft since your are not using OSPF-TE standard multiple instances to 
separate dynamic from static information.  Please review OSPF-TE 
standards, before asking for any changes associated with separating 
dynamic and static information.  This issue was addressed very early on 
in WSON development.
Greg

---

From: Lou Berger <[email-masked]>
Date: Thu, 14 Jul 2011 10:17:02 -0700

Greg,
	A minor point, you really are referring to the use of "multiple LSA
IDs" (which in TE is based on the instance field within the LSA ID).
The term "multiple instances" can also be interpreted to refer to
Multi-Instance OSPF, so we should avoid this opportunity for confusion...

Lou

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 15 Jul 2011 07:01:46 -0700

Thanks Lou. RFC3630 has the "Instance" field. So was using the term 
"multiple instance" in this case. Rather than multiple OSPF instances.
Greg

---

From: Acee Lindem <[email-masked]>
Date: Fri, 15 Jul 2011 10:56:50 -0400

It still is very peculiar to refer to this as a multi-instance LSA since the instance field is only a portion of the opaque LSA Identifier. I agree with Lou that this terminology should be avoided. Also, you'll note that Lou is the author of RFC 5250. It would be more appropriate to refer to these as "multiple instances of the TE LSA" rather than a "Multi-instance LSA". 

On Jul 15, 2011, at 10:01 AM, Greg Bernstein wrote:

> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 15 Jul 2011 13:43:53 -0700

Thanks Acee. From now on we will refer to this technique as "multiple 
instances of the TE LSA originated from single system".
Note that the current WSON encoding is efficient and allows information 
to be broken down into units of information so that when using the 
"multiple instances of a TE LSA originated from a single system" 
mechanism we have no problem keeping OSPF packet small.
When we first started WSON work we considered three mechanisms to 
separate relatively static from relatively dynamic information:
(a) Get a new TE LSA types for static versus dynamic information
(b) Get new top level TLVs for static versus dynamic information
(c) Use existing "multiple instances of a TE LSA originated from a 
single system" mechanism.

We went with (c) a couple years ago since it was the recommended 
approach. Please let us know if this has changed.

Greg