Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

From: Andrea Zanardi <[email-masked]>
Date: Mon, 03 Oct 2011 16:14:10 +0200

Hi Young,

I was following the discussion and I have a doubt about
your example related to the TE Link TLV.

It's true that the attributes sub-TLV are not mandatory per RFC 3630,
but I don't think that means that they can be not included in an LSA update
if unchanged (implying that the previous value persists).

As for my understanding of how OSPF-TE works, the managed TE DB entity is the LSA.
When an LSA update is processed, the previous version is deleted from the TE DB
and it is replaced by the new one: link attributes related to missing sub-TLV are
deleted, so they must be present even if unchanged.

In theory, the set of link attributes could be statically divided
in two different LSAs instances (updated independently),
but I don't think current implementations handle this scenario
(also because, in my opinion, it's not suggested by RFC 3630 and
  it gives no rule on how to divide them).

But I ask to the mailing list if this is the correct interpretation.

Regards,
Andrea

On 09/30/2011 11:16 PM, Leeyoung wrote:
> Hi Pierre,
>
> I got your point. Let me ask you this question. In the current GMPLS OSPF TE Link TLV are defined under Opaque TE LSA with the following attributes:
>
> - TE Metric
> - max B/W
> - max reservable b/w
> - unreserved b/w
> - Admin Group
> - Link Protection Type
> - SRLG
> - ISCD
> - etc.
>
> And these are a mixture of static and dynamic information and yet they are assembled together as one TE Link TLV. For instance the ISCD is quite similar to Resource Block Info in that it does not change often unless there are new elements added in the node or configuration changes and yet it is packaged together with other dynamic information.
>
> Why?
>
> There are many ways to keep static/unchanged information from being flooded. Only the Link Type and Link ID which are mandatory in the TE Link TLV per RFC3630. All other sub-TLV are optional and may occur at most once (when there are enough changes from the previous period that deserve an update) and need not be included in the TE Link TLV when there is no need for updating.
>
> I really don't see the need for a separate top-level TLV and/or a separate LSA for the Resource Block information.
>
> Regards,
> Young
>
>
>
> -----Original Message-----
> From: PELOSO, PIERRE (PIERRE) [mailto:[email-masked]]
> Sent: Friday, September 30, 2011 9:39 AM
> To: Leeyoung; [email-masked]
> Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>
> Hi Young,
>
> I understand the content of your answer, but I'm not satisfied with it.
> My concern deals with providing a unique reading/interpretation of the OSPF-TE extensions.
> We would like to make sure that any implementation complying to the drafts would provide the same LSAs when applied to the same network.
> With this perspective in mind, we wish to get drafts with sufficient documentation to make sure the LSA design process to be depicted, by design rules.
>
> Hence the content of your answer leaving me the "opportunity to do as I wish", is not pleasing me, I would rather have strict rules, and discussions with the WG on the design of those.
> That is why a first design rule, we could agree on is: to gather the Resource Block Information TLVs inside a dedicated LSA, possibly with a dedicated top-level TLV (which in my mind allows to enforce this design rule).
>
> Regards,
>
> - Pierre
>
> -----Message d'origine-----
> De : Leeyoung [mailto:[email-masked]]
> Envoyé : mercredi 28 septembre 2011 00:06
> À : PELOSO, PIERRE (PIERRE); [email-masked]
> Objet : RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>
> Hi Pierre,
>
> Please see-inline for my reply to your first point.
>
> Regards,
> Young
>
> -----Original Message-----
> From: PELOSO, PIERRE (PIERRE) [mailto:[email-masked]]
> Sent: Tuesday, September 27, 2011 3:28 AM
> To: Leeyoung; [email-masked]
> Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>
> Hi Young, and CCAMPers,
>
> I was off the mailing lists for the last two weeks and being back I notice a lot of exchanges, which I'm very glad of.
> I've also noticed many drafts have been updated.
> Concerning this specific draft-ietf-ccamp-wson-signal-compatibility-ospf-06, I wanted to comment section 3.
> Back in Quebec, I expressed my point of view (shared with Cyril, Julien and Giovanni) that current drafts were lacking guidance regarding the way to design LSAs that were to depict an WSON node with OEOs.
> This section 3 provides additional material to help designing the LSA.
> I would like to know whether authors are willing to pursue further in this direction, which is to my mind a real corner stone, that would help everyone agree on a solution.
> A first point could concern the Resource Block Information (reminder:<ResourceBlockInfo>  ::= ([<ResourceSet>]<InputConstraints>  <ProcessingCapabilities>  <OutputConstraints>):
>       We all agree that these information are static, that we should not replicate this TLV whatever the number not the layout of OEO boards of a given type.
> Then, we could dedicate a specific independant flooding entity. This would be defined once for all, and that would not leave room to different interpretations.
> What about this first point?
>
> YOUNG>>  If I understand you correctly, what you are saying is since the Resource Block Info sub-TLV is very static in nature, advertisement of this sub-TLV should be treated differently from the rest of static-TLVs (which may change over time). Is this what you are saying?
>
> If my interpretation of your comment is correct,
>
> - The current mechanism allows what you want: Please see the first paragraph in Section 3.2
>     "In the highly unlikely event that a WSON sub-TLV by itself would
>     result in an LSA exceeding the MTU, all five WSON specific sub-TLVs
>     in this document provide mechanisms that allow them to be subdivided
>     into smaller sub-TLVs that can be sent in separate OSPF TE LSAs."
>
> According to this clause, you can separate the Resource Block Info Sub-TLV as the sole entry defined in the Optical Node property TLV in a separate TE LSA from the rest if you will. Nothing prevents this particular way of packaging. (Isn't this what you meant "a specific independent flooding entity"?)
>
> - Please let me know if this explanation satisfies you. Thanks --- Young
>
> Regards,
>
> Pierre
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de Leeyoung Envoyé : jeudi 15 septembre 2011 21:59 À : [email-masked] Objet : Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>
> Hi all,
>
> After 05 version publication, Acee provided a number of valuable comments and suggestions. This revision (06) reflects those changes. Please note the following updates:
>
> - Change the title of the draft to "GMPLS OSPF Enhancement..." from "OSPF Enhancement..." to make sure the changes apply to the GMPLS OSPF rather than the base OSPF.
>
> - Add specific OSPF procedures on how sub-TLVs are packaged per [RFC3630] and editorial change including avoiding "multiple instances of TE LSA" to "multiple TE LSAs".
>
> Your comments are always appreciated. Thanks.
>
> Best Regards.
> Young
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, September 15, 2011 2:48 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.
>
> 	Title           : GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks
> 	Author(s)       : Young Lee
>                            Greg M. Bernstein
> 	Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
> 	Pages           : 14
> 	Date            : 2011-09-15
>
>     This document provides GMPLS OSPF routing enhancements to support
>     signal compatibility constraints associated with WSON network
>     elements. These routing enhancements are required in common optical
>     or hybrid electro-optical networks where not all of the optical
>     signals in the network are compatible with all network elements
>     participating in the network.
>
>     This compatibility constraint model is applicable to common optical
>     or hybrid electro optical systems such as OEO switches, regenerators,
>     and wavelength converters since such systems can be limited to
>     processing only certain types of WSON signals.
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

-- 
--------------------------------------------------------
Andrea Zanardi
CREATE-NET
Engineering & Fast Prototyping (ENGINE) Area
Senior Engineer
Via alla Cascata 56/D - 38123 Povo Trento (Italy)
e-mail: [email-masked]
Tel: (+39) 0461 408400 - interno/extension 1407
Mobile: (+39) 340 0011837
Fax: (+39) 0461 421157
Skype: zanardi_andrea
www.create-net.org
--------------------------------------------------------

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited according to the
Italian Law 196/2003 of the Legislature. If you received this in error,
please contact the sender and delete the material from any computer.

Le informazioni contenute in questo messaggio di posta elettronica e nei
file allegati sono da considerarsi strettamente riservate. Il loro utilizzo
e' consentito esclusivamente al destinatario del messaggio, per le finalita'
indicate nel messaggio stesso. Qualora riceveste questo messaggio senza
esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via
e-mail e di procedere alla cancellazione del messaggio stesso dal Vostro
sistema. Trattenere il messaggio stesso, divulgarlo anche in parte,
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalita'
diverse, costituisce comportamento contrario ai principi dettati dal D. Lgs.
196/2003.

---

From: Leeyoung <[email-masked]>
Date: Mon, 03 Oct 2011 19:34:27 +0000

Hi Andrea,

Thanks for your interest and input to this issue. 

My overall point was that the current GMPLS TE LSA (per RFC 3630) does not specify detail implementations as to how to divide up the TE Link TLVs into static vs. dynamic nor how to use multiple TE LSAs. The current WSON document follows a similar document philosophy with the GMPLS predecessor. 

Regarding your point on how the TE DB works in regard to missing sub-TLVs are deleted seems to me a particular implementation, which is most simplistic in nature. 

Best Regards,
Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrea Zanardi
Sent: Monday, October 03, 2011 9:14 AM
To: Leeyoung
Cc: [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Young,

Regards,
Andrea

---

From: Andrea Zanardi <[email-masked]>
Date: Tue, 04 Oct 2011 16:10:09 +0200

Hi Young,

with respect to the TE DB management of missing sub-TLVs in LSA updates,
I checked the behavior of a commercial OSPF-TE implementation.

The point is that, if the TE DB is the set of LSAs, that's how it works
as the TE DB contains only the latest version of an LSA instance
and you can not merge the content of different LSA versions
(you could keep an internal model for the links with their attributes
updated independently, but when two neighbors synchronize their DB,
they synchronize the LSA set, not the internal models).

With respect to RFC 3630, it states:

  2.4.2.  Link TLV

     The Link TLV describes a single link.

I read 'describes' as 'fully describes' (not 'partially describes');
so I don't see where it supports/suggests the division of the attributes on multiple
LSA instances and that's why I think that multiple LSA instances for the
same link is not supported by current implementations.

It's a possible implementation and it's fine to suggest it for other top level TLVs,
but it's not the one defined by RFC 3630 for TE Links, in my opinion.

My point is in avoiding ambiguities: if the support for multiple LSA instances for the
same entity top TLV is requested, it should be explicitly stated as mandatory
(possibly providing explicit rules for the subdivision, as in Chap. 3 of the draft).

Regards,
Andrea

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Tue, 4 Oct 2011 18:00:13 +0200

Young and Andrea,

I happen to have the same understanding as you have of the OSPF-TE implementation and update mechanisms.
I would have been refering also to pure OSPF v2 mechanisms (e.g. rfc2328#section-12.2 and section 13).
Young do you have in mind other references stating otherwise ?

Besides this point, my originating concern was to avoid ambiguities.
In the case of the Link LSA, there is no ambiguity, whatever the CP implementation the LSA will be similar to describe the same link.
Possibly, one implementation can be less verbous than an other by omitting some of the optional sub-TLVs, but there will be no differences in the structure.
And currently the WG drafts allow multiple TLVs layouts, that will conduct to different LSA structures for different CP implementation, and even worse, a CP implementation may itself follow different rules depending on the node structure.
These differences can come for example from the capability provided today of defining Resource Block Information that describe a group of similar devices or a single device.
I am afraid these lack of consistency in the design of TLV are putting at risks, CP restarts and implementation interops.
My opinion is that we could avoid these confusions, by defining some LSA design rules.

Then, I wished we could work together in providing more details to current section 3 of the draft.

Regards,

Pierre

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Andrea Zanardi
Envoyé : mardi 4 octobre 2011 16:10
À : Leeyoung
Cc : [email-masked]
Objet : Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Young,

with respect to the TE DB management of missing sub-TLVs in LSA updates, I checked the behavior of a commercial OSPF-TE implementation.

The point is that, if the TE DB is the set of LSAs, that's how it works as the TE DB contains only the latest version of an LSA instance and you can not merge the content of different LSA versions (you could keep an internal model for the links with their attributes updated independently, but when two neighbors synchronize their DB, they synchronize the LSA set, not the internal models).

  2.4.2.  Link TLV

I read 'describes' as 'fully describes' (not 'partially describes'); so I don't see where it supports/suggests the division of the attributes on multiple LSA instances and that's why I think that multiple LSA instances for the same link is not supported by current implementations.

It's a possible implementation and it's fine to suggest it for other top level TLVs, but it's not the one defined by RFC 3630 for TE Links, in my opinion.

My point is in avoiding ambiguities: if the support for multiple LSA instances for the same entity top TLV is requested, it should be explicitly stated as mandatory (possibly providing explicit rules for the subdivision, as in Chap. 3 of the draft).

Regards,
Andrea

On 10/03/2011 09:34 PM, Leeyoung wrote:
> Subject: Re: [CCAMP] I-D Action:
> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>
> Hi Young,
>
> I was following the discussion and I have a doubt about your example
> related to the TE Link TLV.
>
> but I don't think that means that they can be not included in an LSA
> update if unchanged (implying that the previous value persists).
>
> When an LSA update is processed, the previous version is deleted from
> the TE DB and it is replaced by the new one: link attributes related
> to missing sub-TLV are deleted, so they must be present even if unchanged.
>
> In theory, the set of link attributes could be statically divided in
> two different LSAs instances (updated independently), but I don't
> think current implementations handle this scenario (also because, in
> my opinion, it's not suggested by RFC 3630 and
>> From: PELOSO, PIERRE (PIERRE)
>> [mailto:[email-masked]]
>> Subject: RE: [CCAMP] I-D Action:
>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>>
>> Hi Young,
>>
>> De : Leeyoung [mailto:[email-masked]] Envoyé : mercredi 28
>> septembre 2011 00:06 À : PELOSO, PIERRE (PIERRE); [email-masked]
>> Objet : RE: [CCAMP] I-D Action:
>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>>
>> Hi Pierre,
>>
>> From: PELOSO, PIERRE (PIERRE)
>> [mailto:[email-masked]]
>> Subject: RE: [CCAMP] I-D Action:
>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>>
>> Hi Young, and CCAMPers,
>>
>> According to this clause, you can separate the Resource Block Info
>> Sub-TLV as the sole entry defined in the Optical Node property TLV in
>> a separate TE LSA from the rest if you will. Nothing prevents this
>> particular way of packaging. (Isn't this what you meant "a specific
>> independent flooding entity"?)
>>
>> De : [email-masked] [mailto:[email-masked]] De la
>> part de Leeyoung Envoyé : jeudi 15 septembre 2011 21:59 À :
>> [email-masked] Objet : Re: [CCAMP] I-D Action:
>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>>
>> Hi all,
>>
>> Subject: [CCAMP] I-D Action:
>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>>
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compa
>> tibility-ospf-06.txt _______________________________________________
>> CCAMP mailing list
>> [email-masked]

Engineering & Fast Prototyping (ENGINE) Area Senior Engineer Via alla Cascata 56/D - 38123 Povo Trento (Italy)

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited according to the Italian Law 196/2003 of the Legislature. If you received this in error, please contact the sender and delete the material from any computer.

Le informazioni contenute in questo messaggio di posta elettronica e nei file allegati sono da considerarsi strettamente riservate. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalita'
indicate nel messaggio stesso. Qualora riceveste questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla cancellazione del messaggio stesso dal Vostro sistema. Trattenere il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalita'
diverse, costituisce comportamento contrario ai principi dettati dal D. Lgs.
196/2003.

---

From: Acee Lindem <[email-masked]>
Date: Tue, 4 Oct 2011 13:03:21 -0400

Hi Andrea,

> (possibly providing explicit rules for the subdivision, as in Chap. 3 of the draft).

There are not multiple instances of the same LSA. Rather they are unique LSAs, as identified by the (Type, Link State ID, Advertising Router) tuple. In this case, they have different Link State IDs. One thing that is confusing is that RFC 3630 refers to the portion of the Link State ID providing uniqueness as "Instance". Also note that draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt doesn't include any additions to the Link TLV so I'm not sure why you are citing it in discussions of the new top-level TLVs.

Thanks,
Acee

---

From: Andrea Zanardi <[email-masked]>
Date: Tue, 04 Oct 2011 21:03:36 +0200

Hi Acee,

> On Oct 4, 2011, at 10:10 AM, Andrea Zanardi wrote:
....
> There are not multiple instances of the same LSA. Rather they are unique LSAs,
 > as identified by the (Type, Link State ID, Advertising Router) tuple.
 > In this case, they have different Link State IDs.
 > One thing that is confusing is that RFC 3630 refers to the portion of the Link State ID
 > providing uniqueness as "Instance".
 > Also note that draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt doesn't include any
 > additions to the Link TLV so I'm not sure why you are citing it in discussions of the new top-level TLVs.

I was replying to Young email providing the Link TLV and
RFC 3630 as an example of the usage of multiple LSAs and of
sending LSA updates with missing sub-TLVs;
I was discussing about the correctness of the example,
that's why I was citing the Link TLV.

The usage of the word "instance" is probably not correct.

What I meant by "multiple LSA instances" was different LSAs (with distinct LS ID
and both present in the TE DB at the same time) describing the same entity
(e.g. the same link by including the same Link Type / Link ID sub-TLVs)
each one providing a subset of the information (e.g. a subset of the other sub-TLVs).

Considering the draft TLVs, this should be the case of Chap. 3.2.1 "Sub-Division by Options", e.g.:
two LSAs with a Resource Block Information sub-TLV with the same RB Set Field
and different sub-sets of optional sub-sub-TLVs.

To avoid ambiguities, it should be clear that the options described in Chap. 3
are the only options and that, even if they "can" be used when generating
the LSAs, they "must" all be supported when receiving and 'using' the LSAs.

Regards,
Andrea

>> Engineering&  Fast Prototyping (ENGINE) Area
>> Senior Engineer

---

From: Julien Meuric <[email-masked]>
Date: Thu, 06 Oct 2011 17:22:51 +0200

Hi.

On this issue of layout ambiguities, I do expect from the /Common 
Control.../ WG to provide a strong level of commonalties in protocols.

Beyond common object encodings, common object packing into LSAs is also 
significant. The first impact is on the operational tools used to 
supervise and analyze protocol exchanges: the more strict the OSPF 
packing rules are, the more usable and efficient those tools will be. 
Furthermore, troubleshooting will be easier and people training always 
benefit from commonalties.

Not to mention the lack of benefits from operational experience if, 
because of layout discrepancies between OSPF implementations, two 
GMPLS-controlled sub-networks, with similar node designs, end up by 
requiring, for instance, different entities to identify, or very 
different dimensioning of signaling networks...

My 2 cents,

Julien

---

From: Leeyoung <[email-masked]>
Date: Thu, 06 Oct 2011 20:07:58 +0000

Hi Julien, 

There are two main discussions:

Case 1: Putting all sub-TLVs into the Optical Node Property TLV in the OSPF TE LSA. 

Case 2: In case the MTU exceeds 1500 byte limit, see Section 3.2 for this. (I don't see the need for breaking up TLV's into different OPSF TE LSAs for today's typical WSON node examples, but in case in the future, we encounter the need for breaking up TLV's, this section describes how to do it under current OPSF rules.)

Please note that Case 1 is our base case. We don't see the need for Case 2 for current WSON node examples. Case 2 is provided in case of the future and does not break the current OSPF rules and can exist with case 1. Please review the current texts presented below and see if there are any ambiguities and indicate any clarifying points by suggesting "new" texts. 

Section 2 describes Case 1 (base case) and Section 3.1 describes Case 2.  

--------------------begin (Case 1)----------------------------
2. The Optical Node Property TLV
   
   [RFC3630] defines OSPF TE LSA using an opaque LSA. This document adds
   a new top level TLV for use in the OSPF TE LSA: the Optical Node
   Property TLV. The Optical Node property TLV describes a single node.
   It is constructed of a set of sub-TLVs. There are no ordering
   requirements for the sub-TLVs. Only one Optical Node TLV shall be
   advertised in each LSA.

   The Optical Node Property TLV contains all WSON-specific node
   properties and signal compatibility constraints. The detailed
   encodings of these properties are defined in [WSON-Encode].

   The following sub-TLVs of the Optical Node Property TLV are defined:

   Value       Length      Sub-TLV Type

   TBA         variable    Resource Block Information
   TBA         variable    Resource Pool Accessibility
   TBA         variable    Resource Block Wavelength Constraints
   TBA         variable    Resource Pool State
   TBA         variable    Block Shared Access Wavelength Availability

...
   All sub-TLVs defined here may occur at most once in any given Optical
   Node TLV. These restrictions need not apply to future sub-TLVs.
   Unrecognized sub-TLVs are ignored.
--------------------------end-----------------------

Please let me know if there is any ambiguity in this description and the co-authors are more than willing to add more clarifying text if there is any ambiguity here. 

For Case 2, please read section 3.2 as below and indicate if there is any ambiguity here. 

------------------------- begin (Case 2)--------------------

3.2. Separating a Sub-TLV into Multiple OSPF TE LSAs

   In the highly unlikely event that a WSON sub-TLV by itself would
   result in an LSA exceeding the MTU, all five WSON specific sub-TLVs
   in this document provide mechanisms that allow them to be subdivided
   into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.

   Sub-Division by Sets

   All five sub-TLVs currently make use of one or more RB Set Fields
   [WSON-Encode] or Link Set Fields [Gen-Encode]. Long set fields can be
   decomposed into multiple smaller set fields resulting in multiple
   sub-TLVs that can be sent in multiple OSPF TE LSAs. The
   interpretation of the separate pieces is quite natural and reviewed
   in the following:

   Resource Block Information
     Information about different resources of similar types would get
     sent separately (LSAs). Path computation would not know a resource
     exists until it receives the instance of a sub-TLV that mentions
     that instance.

   Resource Pool Accessibility
     Information about accessibility to resources to/from ports would be
     in as separate pieces base on port or resource set separation. All
     pieces are combined to give complete resource/port accessibility
     view. Late/missing pieces would imply resources are not accessible
     to/from given ports.

   Resource Block Wavelength Constraints
     Information about resource wavelength constraints can be sent in
     separate pieces based on resource sub-sets. Late/missing pieces
     (LSAs) would imply resources accessible when they might not be.

   Resource Pool State
     Information about resource state can be sent in separate pieces
     based on resource sub-sets. Late/missing pieces (LSAs) could imply
     incorrect resources availability.

   Block Shared Access Wavelength Availability
     Information about resource shared access wavelength can be sent in
     separate pieces based on resource sub-sets. Late/missing pieces
     (LSAs) could imply incorrect shared wavelength availability.

   Due to the reliability mechanisms in OSPF the phenomena of late or
   missing pieces for relatively static information (first three types
   of sub-TLVs) would be relatively rare.

-----------------end----------------------------------------------------

Thanks,

Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: Thursday, October 06, 2011 10:23 AM
To: [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi.

My 2 cents,

Julien

---

From: Leeyoung <[email-masked]>
Date: Fri, 07 Oct 2011 22:46:25 +0000

Hi Andrea,

Sorry for my late response to your questions. Please see in-line for my comments. Thanks.

Young

-----Original Message-----
From: Andrea Zanardi [mailto:[email-masked]] 
Sent: Tuesday, October 04, 2011 9:10 AM
To: Leeyoung
Cc: [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Young,

YOUNG>> Here I assumed the LSAs are two different LSAs (identified by the LSA ID). 

YOUNG>> Here is a bit confusing. The TE DB synchronization process checks the same LSA and the sequence number (which you are referring as the version of an LSA instance). When the node identifies the same LSA with different sequence number, then it flushes the LSA with the lower sequence number. But the TE DB synch process does not check each other for different LSAs (which is identified by the LSA ID). 

  2.4.2.  Link TLV

YOUNG>> RFC3630 differentiates the mandatory element from other entities that can appear "at most" once. 
This is from RFC 3630 Section 2.4.2:

   The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
   exactly once.  All other sub-TLVs defined here may occur at most
   once.  These restrictions need not apply to future sub-TLVs.
   Unrecognized sub-TLVs are ignored.

YOUNG>> It does not mandate other sub-TLVs to appear exactly once; it rather says it may occur "at most once" -- sound like to me
YOUNG>> this is an optional element.  

YOUNG>> When you have different sub-sets of TLV's to be packaged under the OPSF TE LSA, you can use a different LSA ID from the previously used one to avoid ambiguities. Then these are simply two different LSAs and would not confuse the TE DB sync process as well as flooding process. 

Regards,
Andrea

---

From: Andrea Zanardi <[email-masked]>
Date: Sun, 09 Oct 2011 18:52:59 +0200

Hi Young,

I think I clarified what I meant in my reply to Acee comments.

Anyway, my original comments were related to:

a.  the possibility of sending a TE Link LSA update (same ID, new sequence number)
     without some sub-TLVs if their value is unchanged, as I understood when you wrote

     "All other sub-TLV are optional and may occur at most once
      (when there are enough changes from the previous period that deserve an update)
      and _need not_ be included in the TE Link TLV when there is no need for updating."

    (but correct me if I misunderstood your sentence)

    This clearly can't work due to how the TE DB synchronization works.

    Note that also creating a new LSA (new ID) with only the changed sub-TLVs doesn't
    work, as you will have two different values for the same sub-TLV
    (as the old LSA and the new LSA are both present in the TE DB)

    I read the "may occur at least once" in RFC 3630 as:
    "it may be omitted if it does not apply to the link";
    but if it applies, it must be present in all updates
    (unless you want to clear its value)

b. the fact that RFC 3630 allows the possibility of splitting the
    set of sub-TLVs of a TE Link in different LSAs (different IDs)
    [the implementation I checked doesn't support this scenario]

    This could be a matter of interpretation; but as it's not explicitly
    stated, the simplest interpretation is usually the one accepted.

I perfectly agree that splitting a set of attributes related to
a 'logical' instance in two or more different LSAs is a viable solution
(as far as you keep the subsets disjoint and the support for this
solution is explicitly requested; and this is somehow stated
in the draft in Chap. 3.2.1).

Even if, in my opinion, would be preferable to have some rule
defined; especially if the reason for the splitting is the dynamics
of the updates and not just the size.

Sorry if there has been any misunderstanding.

Regards
Andrea

---

From: Acee Lindem <[email-masked]>
Date: Mon, 10 Oct 2011 10:17:47 -0400

Hi Andrea, 

> that's why I was citing the Link TLV.

Ok. 

> the LSAs, they "must" all be supported when receiving and 'using' the LSAs.

Agreed. Splitting information across multiple LSAs will result in some added complexity. 
For TLVs or sub-TLVs that are required for a single WSON computation, the WSON path computation must concatenate them when doing that computation. 
Today, multiple OSPFv3 Router-LSAs may be originated and implementation MUST use the concatenation when doing the OSPFv3 SPF computation. 

Thanks,
Acee

---

From: Leeyoung <[email-masked]>
Date: Mon, 10 Oct 2011 16:35:08 +0000

Hi Andrea,

I see your point more clearly. You are concerned about the interoperability issue beyond the specification of the protocol to ensure two implementations should interoperate each other. To that end, please propose some text. Thanks.

Best Regards,
Young

-----Original Message-----
From: Andrea Zanardi [mailto:[email-masked]] 
Sent: Sunday, October 09, 2011 11:53 AM
To: Leeyoung
Cc: [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Young,

Regards
Andrea

---

From: Leeyoung <[email-masked]>
Date: Thu, 27 Oct 2011 13:46:48 +0000

Hi Andrea and Acee,

What I am proposing is this:

In Section 2, we have the following statement:

I will change the above statement to the following:

   All sub-TLVs defined here may occur at most once in any given Optical
   Node TLV. "At most once" means that if there is sub-TLV related information, 
   it will be always included. These restrictions need not apply to future 
   sub-TLVs. Unrecognized sub-TLVs are ignored. 

This statement assures that all the related sub-TLVs are always included in any given
Optical Node TLV leaving no room not to include such sub-TLVs in the Optical
Node TLV. 

In Section 3.2, we have the following statement:

I will change the above statement to the following:

   What is suggested as below is the only option allowed when dividing up 
   the current set of sub-TLVs into separate OSPF TE LSAs. This means
   each sub-TLV will be packaged as the sole element in an OSPF TE LSA
   with a unique LSA instance number. When such division is implemented, then
   the source node must flush the existing LSA (i.e., the original OSPF
   TE LSA with all sub-TLV's packaged together as described in Section 2). 
   This will avoid duplicating the same information being advertised across 
   multiple LSAs. 

Please let me know if these texts will remove any ambiguity of the current 
Texts. 

Best Regards,
Young
-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Monday, October 10, 2011 9:18 AM
To: Andrea Zanardi
Cc: Leeyoung; [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Andrea, 

Ok. 

Thanks,
Acee

---

From: Lou Berger <[email-masked]>
Date: Thu, 27 Oct 2011 09:58:19 -0400

Young, (And other WG document authors/editors),

	Just a general statement on Standards Track drafts (as opposed to
Informational drafts).  Narrative language is important, but a PS
ultimately must have normative, i.e., RFC2119, language or it will not
be approved as a Standards Track RFC. (Generally I include both type for
better clarity/understanding.)  So please ensure that there is such
language matching the narrative/non-normative text you have below (and
in the rest of the draft).

Much Thanks,
Lou (Chair hat squarely on)

---

From: Acee Lindem <[email-masked]>
Date: Fri, 28 Oct 2011 17:18:50 -0400

Hi Young,

>   This will avoid duplicating the same information being advertised across

s/LSA instance number/Link State ID/

So, it is not expected that a sub-TLV will exceed the IP MTU and, if it does, we simply rely on IP fragmentation/reassembly as we do in situations where the Router-LSAs and many interfaces in a single area. Correct?

Thanks,
Acee

---

From: Leeyoung <[email-masked]>
Date: Sun, 30 Oct 2011 20:41:44 +0000

Hi Acee,

I accepted your suggestion on

I have question on your statement: You said below: 

ACEE>> So, it is not expected that a sub-TLV will exceed the IP MTU and, if it does, we simply rely on IP fragmentation/reassembly as we do in situations where the Router-LSAs and many interfaces in a single area. Correct?

YOUNG>> What I meant is as follows: The Optical Node TLV under which five sub-TLVs are specified will not be expected to exceed the IP MTU. If it does, the suggestion is to define a set of five new Optical Node TLVs, each with a new unique LSA ID under which to specify only one sub-TLV respectively for each of the five new TLVs, to ensure each new Optical Node TLV does not exceed the IP MTU. This solution would prevent actually from relying on IP fragmentation/reassembly. Instead of sending one big TLV, we sub-divide into five smaller TLVs and send them one at a time with a new LSA ID. 

Please let me know if we are on the same page on this point. Thanks.

Young

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Friday, October 28, 2011 4:19 PM
To: Leeyoung
Cc: Andrea Zanardi; [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Young,

Thanks,
Acee