Subject: Re: [CCAMP] Merging of the WSON specific OSPF extensions

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Fri, 5 Nov 2010 17:30:28 +0100

Hi Fatai and Young,

Let me comment the two items you mentionned.

1. Is there anything missed in [WSON-Encode] and [General-Encode]?
In these drafts there is no item (to my knowledge) that is lacking.
But I do not consider that answering no to this question means that we can directly move to your point (2).
Having the right items being treated in a draft, does not mean the solution described to address these items is the only one that works.
In that case we have the chance to have on the table two variations of a solution for each of which for sure we can find advantages and disadvantages.
Depending on the priorities between the evaluation criteria regarding the advantages and disadvantages, the WG may end-up with given bits of one solution or another.

[WSON-Encode] and [WSON OSPF] are drafts that needs refinement to my point in order to achieve the convergence. It is not just a matter of adding material to it, and their being WG documents entitle all the more the WG to propose changes to its content.

In order to speak on a common ground, we updated draft-peloso-ccamp-wson-ospf-oeo, by first lighting it from the points on which there was agreement and which were treated in draft-zhang-ccamp-general-constraints-ospf-ext<http://tools.ietf.org/id/draft-zhang-ccamp-general-constraints-ospf-ext-00.txt>. To the degree of details we are handling today, this one is ok for me, there may be needs to discuss some details, but that is premature now, and I take we will have time enough to address this before this document becomes definitive.
Still to speak on a common ground, we rewrote draft-peloso-ccamp-wson-ospf-oeo in order to re-use as much as possible the [WSON-Encode] draft.
Nevertheless, this rewritting of the draft has for implication to provide modifications to [WSON-Encode], not limited to adding some more items in it.

There is a real work to do in order to converge, but to cheer things up, that is not bad right now, we know what fits everyone, and we have isolated the differences that have to be worked on.

To conclude from my point of view:

 *
no need to urge on refining draft-zhang-ccamp-general-constraints-ospf-ext<http://tools.ietf.org/id/draft-zhang-ccamp-general-constraints-ospf-ext-00.txt> it is suitable as is in regards to the other documents.
 *
need to converge on the way OEO pools are depicted, knowing that we already aggree on what are the information to be conveyed are, but there is a diverging view on the way of organizing this information.

Best regards,

Pierre

P.S.: Unfortunately, last minute constraint force me to cancel my trip to Beijing, and I would be happy to keep on having these discussions by email.

________________________________
De : Fatai Zhang [mailto:[email-masked]]
Envoyé : vendredi 29 octobre 2010 11:54
À : Young Lee; PELOSO, PIERRE (PIERRE)
Cc : 'CCAMP'
Objet : Re: [CCAMP] Merging of the WSON specific OSPF extensions

Hi Pierre and Young,

A few points for clarifciation.

There are three OSPF drafts related to WSON:

(1) draft-ietf-ccamp-wson-signal-compatibility-ospf<http://tools.ietf.org/wg/ccamp/draft-ietf-ccamp-wson-signal-compatibility-ospf/>
(2) draft-peloso-ccamp-wson-ospf-oeo/
(3) draft-zhang-ccamp-general-constraints-ospf-ext<http://tools.ietf.org/id/draft-zhang-ccamp-general-constraints-ospf-ext-00.txt>

For (1) and (2), they are talking about WSON specific routing stuff, which (should) follow [WSON-Encode]. For (3), it is generic stuff, which follows [General-Encode].

So, to make things clear, I think we can divide the issues into two pieces.

(1) Is there anything missed in [WSON-Encode] and [General-Encode]?

     If yes, then list what is missed and go to these encoding drafts to refine them.

     If no, then we go to (2).

(2) Follow the [WSON-Encode] and [General-Encode] drafts to define protocol

Does [draft-ietf-ccamp-wson-signal-compatibility-ospf<http://tools.ietf.org/wg/ccamp/draft-ietf-ccamp-wson-signal-compatibility-ospf/>] follow [WSON-Encode]? What is missed?
Does [draft-peloso-ccamp-wson-ospf-oeo] follow [WSON-Encode]? What should be added to  [draft-ietf-ccamp-wson-signal-compatibility-ospf<http://tools.ietf.org/wg/ccamp/draft-ietf-ccamp-wson-signal-compatibility-ospf/>]?

Does [draft-zhang-ccamp-general-constraints-ospf-ext<http://tools.ietf.org/id/draft-zhang-ccamp-general-constraints-ospf-ext-00.txt>] follow [General-Encode]?

Yes. What else should be refined?

Best Regards

Fatai

----- Original Message -----
From: Young Lee<mailto:[email-masked]>
To: 'CCAMP'<mailto:[email-masked]>
Sent: Friday, October 29, 2010 12:50 AM
Subject: [CCAMP] Merging of the WSON specific OSPF extensions

Hi Pierre,

This email is to discuss the pending issues in regard to merging two drafts that discusses WSON specific OSPF extensions:

Currently we have one WG draft:
http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/.

And your individual draft:
http://datatracker.ietf.org/doc/draft-peloso-ccamp-wson-ospf-oeo/

We are more than happy to incorporate any new addition from your draft into the aforementioned existing WG draft. Let me summarized the key issues we need to discuss in the following:

 *   I think we agreed on the encoding of the TLV's that are necessary for WSON specific information according to: http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/

 *   Let me try to understand your rationale to create a new Top Level RBA TLV. Your original rationale for O-E-O TLV (old name for RBA TLV) was to differentiate dynamic information from static. But I don't see your original rationale in your revision. If that is still an implicit rationale, you need to clearly state that.

    *   If so, Fatai's draft clearly state the way to differentiate dynamic info from static info using an Opaque LSA mechanism discussed in Section 4 of http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/. In such as, we don't need to create a new TOP Level TLV.

    *   If not, I am still not sure why we need a new TOP TLV.

       *   Why not just use the Top Level OSPF TE LSA node attribute TLV which is existing TOP level TLV?  Please let me know why this TLV would not be proper?

·         Our approach is to RE-use the OSPF TE LSA node attribute TLV under which we define all the necessary sub-TLVs.

·         I still have some problem as to why you still have these sub-TLV:

Sub-TLV Type       Length     Name

     TBD        4 Bytes    TE-metric [alike RFC3630]

     TBD        4 Bytes    Administrative Group [alike RFC3630]

     TBD        8 Bytes    Link Local/Remote Identifiers [alike RFC4203]

     TBD        variable   Shared Risk Link Group [alike RFC4203]

·         Section 2.4 is not clear to me.  You didn't include sub-TLV in Section 2.  Are you saying that connectivity matrix is a part of your RBA TLV? How is this connectivity matrix different from the one defined in section 3.5 in http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/ ?

Regards,

Greg & Young

________________________________

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

---

From: Young Lee <[email-masked]>
Date: Mon, 08 Nov 2010 05:49:23 -0600

Hi Pierre, 

On the second point you indicated below, I am not sure if we have agreed on
the information to be conveyed. In my previous email, I asked you why we
need the following sub-TLV in the resource block attribute (RBA) TLV:

Sub-TLV Type       Length     Name

These sub-TLV seem internal link (if not please clarify) and are duplicate
with already existing TE TLV. 

Again, when you want to create a brand new Top level TLV, you have to answer
why you need these new TLV when the existing mechanism works well. We are
not simply talking about two different ways of putting information together.
One method (yours) requires new processing on control plane s/w while the
other method (ours) does not add additional overhead on existing control
plane s/w. 

Young

  _____  

From: PELOSO, PIERRE (PIERRE) [mailto:[email-masked]] 
Sent: Friday, November 05, 2010 11:30 AM
To: Fatai Zhang; Young Lee
Cc: 'CCAMP'
Subject: RE: [CCAMP] Merging of the WSON specific OSPF extensions

Hi Fatai and Young,

But I do not consider that answering no to this question means that we can
directly move to your point (2).

Having the right items being treated in a draft, does not mean the solution
described to address these items is the only one that works.

In that case we have the chance to have on the table two variations of a
solution for each of which for sure we can find advantages and
disadvantages.

Depending on the priorities between the evaluation criteria regarding the
advantages and disadvantages, the WG may end-up with given bits of one
solution or another.

[WSON-Encode] and [WSON OSPF] are drafts that needs refinement to my point
in order to achieve the convergence. It is not just a matter of adding
material to it, and their being WG documents entitle all the more the WG to
propose changes to its content.

In order to speak on a common ground, we updated
draft-peloso-ccamp-wson-ospf-oeo, by first lighting it from the points on
which there was agreement and which were treated in
<http://tools.ietf.org/id/draft-zhang-ccamp-general-constraints-ospf-ext-00.
txt> draft-zhang-ccamp-general-constraints-ospf-ext. To the degree of
details we are handling today, this one is ok for me, there may be needs to
discuss some details, but that is premature now, and I take we will have
time enough to address this before this document becomes definitive.

Still to speak on a common ground, we rewrote
draft-peloso-ccamp-wson-ospf-oeo in order to re-use as much as possible the
[WSON-Encode] draft.

Nevertheless, this rewritting of the draft has for implication to provide
modifications to [WSON-Encode], not limited to adding some more items in it.

There is a real work to do in order to converge, but to cheer things up,
that is not bad right now, we know what fits everyone, and we have isolated
the differences that have to be worked on.

*	no need to urge on refining
<http://tools.ietf.org/id/draft-zhang-ccamp-general-constraints-ospf-ext-00.
txt> draft-zhang-ccamp-general-constraints-ospf-ext it is suitable as is in
regards to the other documents.
*	need to converge on the way OEO pools are depicted, knowing that we
already aggree on what are the information to be conveyed are, but there is
a diverging view on the way of organizing this information.

Best regards,

Pierre

P.S.: Unfortunately, last minute constraint force me to cancel my trip to
Beijing, and I would be happy to keep on having these discussions by email.

  _____  

Hi Pierre and Young,

(1) draft-ietf-ccamp-wson-signal-compatibility-ospf
<http://tools.ietf.org/wg/ccamp/draft-ietf-ccamp-wson-signal-compatibility-o
spf/> 

(3)
<http://tools.ietf.org/id/draft-zhang-ccamp-general-constraints-ospf-ext-00.
txt> draft-zhang-ccamp-general-constraints-ospf-ext 

For (1) and (2), they are talking about WSON specific routing stuff, which
(should) follow [WSON-Encode]. For (3), it is generic stuff, which follows
[General-Encode].

     If yes, then list what is missed and go to these encoding drafts to
refine them. 

Does [draft-ietf-ccamp-wson-signal-compatibility-ospf
<http://tools.ietf.org/wg/ccamp/draft-ietf-ccamp-wson-signal-compatibility-o
spf/> ] follow [WSON-Encode]? What is missed? 

Does [draft-peloso-ccamp-wson-ospf-oeo] follow [WSON-Encode]? What should be
added to  [draft-ietf-ccamp-wson-signal-compatibility-ospf
<http://tools.ietf.org/wg/ccamp/draft-ietf-ccamp-wson-signal-compatibility-o
spf/> ]?

Does [draft-zhang-ccamp-general-constraints-ospf-ext
<http://tools.ietf.org/id/draft-zhang-ccamp-general-constraints-ospf-ext-00.
txt> ] follow [General-Encode]? 

 

Best Regards
 
Fatai

----- Original Message ----- 

From: Young Lee <mailto:[email-masked]>  

To: 'CCAMP' <mailto:[email-masked]>  

Hi Pierre, 

This email is to discuss the pending issues in regard to merging two drafts
that discusses WSON specific OSPF extensions: 

We are more than happy to incorporate any new addition from your draft into
the aforementioned existing WG draft. Let me summarized the key issues we
need to discuss in the following: 

*	I think we agreed on the encoding of the TLV’s that are necessary
for WSON specific information according to:
http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/ 

*	Let me try to understand your rationale to create a new Top Level
RBA TLV. Your original rationale for O-E-O TLV (old name for RBA TLV) was to
differentiate dynamic information from static. But I don’t see your original
rationale in your revision. If that is still an implicit rationale, you need
to clearly state that. 

*	If so, Fatai’s draft clearly state the way to differentiate dynamic
info from static info using an Opaque LSA mechanism discussed in Section 4
of
http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/.
In such as, we don’t need to create a new TOP Level TLV. 

*	Why not just use the Top Level OSPF TE LSA node attribute TLV which
is existing TOP level TLV?  Please let me know why this TLV would not be
proper? 

*         Our approach is to RE-use the OSPF TE LSA node attribute TLV under
which we define all the necessary sub-TLVs. 
 
*         I still have some problem as to why you still have these sub-TLV:

Sub-TLV Type       Length     Name

*         Section 2.4 is not clear to me.  You didn’t include sub-TLV in
Section 2.  Are you saying that connectivity matrix is a part of your RBA
TLV? How is this connectivity matrix different from the one defined in
section 3.5 in
http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/
? 
 
Regards,
Greg & Young

  _____

---

From: Giovanni Martinelli <[email-masked]>
Date: Mon, 08 Nov 2010 17:31:06 +0100

Hi Young,

On 11/8/10 12:49 PM, Young Lee wrote:
>
> Hi Pierre,
>
> On the second point you indicated below, I am not sure if we have 
> agreed on the information to be conveyed. In my previous email, I 
> asked you why we need the following sub-TLV in the resource block 
> attribute (RBA) TLV:
>
> Sub-TLV Type       Length     Name
>
> These sub-TLV seem internal link (if not please clarify) and are 
> duplicate with already existing TE TLV.
>
for internal link
>
> Again, when you want to create a brand new Top level TLV, you have to 
> answer why you need these new TLV when the existing mechanism works 
> well. We are not simply talking about two different ways of putting 
> information together. One method (yours) requires new processing on 
> control plane s/w while the other method (ours) does not add 
> additional overhead on existing control plane s/w.
>
Well, we were thinking about triggering this discussion. Pls find some 
answer in slide 9 (for wed session) I guess slide are already available.

Cheers
G

> Young
>
> ------------------------------------------------------------------------
>
> *From:*PELOSO, PIERRE (PIERRE) [mailto:[email-masked]]
> *Sent:* Friday, November 05, 2010 11:30 AM
> *To:* Fatai Zhang; Young Lee
> *Cc:* 'CCAMP'
> *Subject:* RE: [CCAMP] Merging of the WSON specific OSPF extensions
>
> Hi Fatai and Young,
>
> Having the right items being treated in a draft, does not mean the 
> solution described to address these items is the only one that works.
>
> In that case we have the chance to have on the table two variations of 
> a solution for each of which for sure we can find advantages and 
> disadvantages.
>
> Depending on the priorities between the evaluation criteria regarding 
> the advantages and disadvantages, the WG may end-up with given bits of 
> one solution or another.
>
> [WSON-Encode] and [WSON OSPF] are drafts that needs refinement to my 
> point in order to achieve the convergence. It is not just a matter of 
> adding material to it, and their being WG documents entitle all the 
> more the WG to propose changes to its content.
>
> draft-peloso-ccamp-wson-ospf-oeo, by first lighting it from the points 
> on which there was agreement and which were treated in 
> draft-zhang-ccamp-general-constraints-ospf-ext 
> <http://tools.ietf.org/id/draft-zhang-ccamp-general-constraints-ospf-ext-00.txt>. 
> To the degree of details we are handling today, this one is ok for me, 
> there may be needs to discuss some details, but that is premature now, 
> and I take we will have time enough to address this before this 
> document becomes definitive.
>
> draft-peloso-ccamp-wson-ospf-oeo in order to re-use as much as 
> possible the [WSON-Encode] draft.
>
> Nevertheless, this rewritting of the draft has for implication to 
> provide modifications to [WSON-Encode], not limited to adding some 
> more items in it.
>
> There is a real work to do in order to converge, but to cheer things 
> up, that is not bad right now, we know what fits everyone, and we have 
> isolated the differences that have to be worked on.
>
>       draft-zhang-ccamp-general-constraints-ospf-ext
>       <http://tools.ietf.org/id/draft-zhang-ccamp-general-constraints-ospf-ext-00.txt> it
>       is suitable as is in regards to the other documents.
>     * need to converge on the way OEO pools are depicted, knowing that
>       we already aggree on what are the information to be conveyed
>       are, but there is a diverging view on the way of organizing this
>       information.
>
> Best regards,
>
> Pierre
>
> P.S.: Unfortunately, last minute constraint force me to cancel my trip 
> to Beijing, and I would be happy to keep on having these discussions 
> by email.
>
> ------------------------------------------------------------------------
>
> *De :*Fatai Zhang [mailto:[email-masked]]
> *Envoyé :* vendredi 29 octobre 2010 11:54
> *À :* Young Lee; PELOSO, PIERRE (PIERRE)
> *Cc :* 'CCAMP'
> *Objet :* Re: [CCAMP] Merging of the WSON specific OSPF extensions
>
>     Hi Pierre and Young,
>
>     <http://tools.ietf.org/wg/ccamp/draft-ietf-ccamp-wson-signal-compatibility-ospf/>
>
>     (2) _draft-peloso-ccamp-wson-ospf-oeo/_
>
>     (3) draft-zhang-ccamp-general-constraints-ospf-ext
>     <http://tools.ietf.org/id/draft-zhang-ccamp-general-constraints-ospf-ext-00.txt>
>
>     For (1) and (2), they are talking about WSON specific routing
>     stuff, which (should) follow [WSON-Encode]. For (3), it is generic
>     stuff, which follows [General-Encode].
>
>     <http://tools.ietf.org/wg/ccamp/draft-ietf-ccamp-wson-signal-compatibility-ospf/>]
>     follow [WSON-Encode]? What is missed?
>
>     Does [_draft-peloso-ccamp-wson-ospf-oeo]_ follow [WSON-Encode]?
>     What should be added to 
>     [draft-ietf-ccamp-wson-signal-compatibility-ospf
>     <http://tools.ietf.org/wg/ccamp/draft-ietf-ccamp-wson-signal-compatibility-ospf/>]?
>
>     <http://tools.ietf.org/id/draft-zhang-ccamp-general-constraints-ospf-ext-00.txt>]
>     follow [General-Encode]?
>
>         *From:*Young Lee <mailto:[email-masked]>
>
>         *To:*'CCAMP' <mailto:[email-masked]>
>
>         *Sent:*Friday, October 29, 2010 12:50 AM
>
>         *Subject:*[CCAMP] Merging of the WSON specific OSPF extensions
>
>         Hi Pierre,
>
>         This email is to discuss the pending issues in regard to
>         merging two drafts that discusses WSON specific OSPF extensions:
>
>             * I think we agreed on the encoding of the TLV's that are
>               necessary for WSON specific information according to:
>             * Let me try to understand your rationale to create a new
>               Top Level RBA TLV. Your original rationale for O-E-O TLV
>               (old name for RBA TLV) was to differentiate dynamic
>               information from static. But I don't see your original
>               rationale in your revision. If that is still an implicit
>               rationale, you need to clearly state that.
>
>                   o If so, Fatai's draft clearly state the way to
>                     differentiate dynamic info from static info using
>                     an Opaque LSA mechanism discussed in Section 4 of
>                     In such as, we don't need to create a new TOP
>                     Level TLV.
>
>                   o If not, I am still not sure why we need a new TOP
>                     TLV.
>
>                         + Why not just use the Top Level OSPF TE LSA
>                           node attribute TLV which is existing TOP
>                           level TLV?  Please let me know why this TLV
>                           would not be proper?
>
>         ·          Our approach is to RE-usethe OSPF TE LSA node attribute TLV under which we define all the necessary sub-TLVs.
>
>           
>
>         ·          Section 2.4 is not clear to me.  You didn't include sub-TLV in Section 2.  Are you saying that connectivity matrix is a part of your RBA TLV? How is this connectivity matrix different from the one defined in section 3.5 inhttp://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/  ?
>
>           
>
>         Regards,
>
>         Greg&  Young
>
>
>         ------------------------------------------------------------------------
>

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 08 Nov 2010 23:55:05 -0800

Hi Giovanni and Pierre, so it sounds like you want to define the 
equivalent of
     (a) TE Metric,
     (b) Admin Group, and
     (c) SRLGs
for "internal links" within a switch with OEO pools. This would then be 
utilized to make decisions for the path to be/taken within a node/. In 
addition, GMPLS signaling would need to be further extended to be able 
to describe the paths to be taken within a "node".

The current WSON information model and WSON encoding provides a 
representation of an WSON node for use in path selection *within the 
network*, but not within a node. This was in keeping with a minimalistic 
approach to representing a node and assumed very little about either 
internal node structure or control.

If path selection choice is actually needed within an "optical system" 
it seems to make more sense to model the system by multiple nodes and 
links, then one can just use the already defined GMPLS link attributes 
(TE Metric, Admin Group, SRLGs), WSON WG drafts, and not require any 
modifications to GMPLS signaling.

Greg & Young

On 11/8/2010 8:31 AM, Giovanni Martinelli wrote:
>> In that case we have the chance to have on the table two 
>> variations of a solution for each of which for sure we can find 
>> advantages and disadvantages.
>>
>> the advantages and disadvantages, the WG may end-up with given bits 
>> of one solution or another.
>>
>> draft-peloso-ccamp-wson-ospf-oeo, by first lighting it from the 
>> points on which there was agreement and which were treated in 
>> To the degree of details we are handling today, this one is ok for 
>> me, there may be needs to discuss some details, but that is 
>> premature now, and I take we will have time enough to address this 
>> before this document becomes definitive.
>>
>> up, that is not bad right now, we know what fits everyone, and we 
>> have isolated the differences that have to be worked on.
>>
>>     * need to converge on the way OEO pools are depicted, knowing
>>       that we already aggree on what are the information to be
>>       conveyed are, but there is a diverging view on the way of
>>       organizing this information.
>>
>> Best regards,
>>
>> Pierre
>>
>> P.S.: Unfortunately, last minute constraint force me to cancel my 
>> trip to Beijing, and I would be happy to keep on having these 
>> discussions by email.
>>
>>     stuff, which (should) follow [WSON-Encode]. For (3), it is
>>     generic stuff, which follows [General-Encode].
>>
>>               Top Level RBA TLV. Your original rationale for O-E-O
>>               TLV (old name for RBA TLV) was to differentiate dynamic
>>               rationale in your revision. If that is still an
>>               implicit rationale, you need to clearly state that.
>>

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

---

From: Giovanni Martinelli <[email-masked]>
Date: Tue, 09 Nov 2010 13:05:50 +0100

Hi Greg and Young,

much thx for the reply (well, I guess  we still have bandwidth before 
reaching DOS attack level)

I would probably try first to move the focus on where do we place the 
Resource Block Information, as you know there are different opinions 
here. We did not find as suitable places neither the link TLV nor the 
node TLV so we suggest using a new one.

plus few comments inline

On 11/9/10 8:55 AM, Greg Bernstein wrote:
> for "internal links" within a switch with OEO pools. This would then 
> be utilized to make decisions for the path to be/taken within a node/. 
> In addition, GMPLS signaling would need to be further extended to be 
> able to describe the paths to be taken within a "node".
Well the goal was to expose some interesting properties that may 
influence your path computation

> network*, but not within a node. This was in keeping with a 
> minimalistic approach to representing a node and assumed very little 
> about either internal node structure or control.
In term of node representation itself  your statement is still true. For 
OEO pools we all agree we need to know something (e.g. WSON i/f 
compatibility lists: FEC etc.) this does not mean to expose internal 
node topology but I would say we expose constrains.

Cheers
G

>>> Again, when you want to create a brand new Top level TLV, you have 
>>> to answer why you need these new TLV when the existing mechanism 
>>> works well. We are not simply talking about two different ways of 
>>> putting information together. One method (yours) requires new 
>>> processing on control plane s/w while the other method (ours) does 
>>> not add additional overhead on existing control plane s/w.
>>>
>> Well, we were thinking about triggering this discussion. Pls find 
>> some answer in slide 9 (for wed session) I guess slide are already 
>> available.
>>
>> Cheers
>> G
>>
>>
>>> Young
>>>
>>> *From:*PELOSO, PIERRE (PIERRE) 
>>> [mailto:[email-masked]]
>>> Depending on the priorities between the evaluation criteria 
>>> regarding the advantages and disadvantages, the WG may end-up with 
>>> given bits of one solution or another.
>>>
>>> point in order to achieve the convergence. It is not just a matter 
>>> of adding material to it, and their being WG documents entitle all 
>>> the more the WG to propose changes to its content.
>>>
>>>             * I think we agreed on the encoding of the TLV's that
>>>               are necessary for WSON specific information according
>>>               to:
>>>             * Let me try to understand your rationale to create a
>>>               new Top Level RBA TLV. Your original rationale for
>>>               O-E-O TLV (old name for RBA TLV) was to differentiate
>>>               dynamic information from static. But I don't see your
>>>               original rationale in your revision. If that is still
>>>               an implicit rationale, you need to clearly state that.
>>>
>>>                     differentiate dynamic info from static info
>>>                     using an Opaque LSA mechanism discussed in
>>>                     Section 4 of
>>>                   o If not, I am still not sure why we need a new
>>>                     TOP TLV.
>>>
>>>                           level TLV?  Please let me know why this
>>>                           TLV would not be proper?
>>>

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Tue, 9 Nov 2010 17:43:01 +0100

Hi Greg, Yound and Giovanni,

Just to add some more comments to the discussion.

I concur with Giovanni that the point of discussion ahead should be focused on where to place the Ressource Block Information (RBI). And the slides Giovanni will be presenting during ccamp session are dealing with that.

Regards,

Pierre

P.S.
Let me just make a short comment (aside the main stream of discussion related to place for RBI). This topic is related to the add-ons objects TE-metric, admin group, and SRLGs, those are additional bits of information that the operator would be entitled the right to use to enrich its path computation. This enrichement may lead to the selection of one OEO pool or another (either in the same node or in different nodes). But to my opinion, this topic can come in a later time, that is not the the hotest point.

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Giovanni Martinelli
Envoyé : mardi 9 novembre 2010 13:06
À : Greg Bernstein
Cc : 'CCAMP'
Objet : Re: [CCAMP] Merging of the WSON specific OSPF extensions

Hi Greg and Young,

much thx for the reply (well, I guess  we still have bandwidth before reaching DOS attack level)

I would probably try first to move the focus on where do we place the Resource Block Information, as you know there are different opinions here. We did not find as suitable places neither the link TLV nor the node TLV so we suggest using a new one.

plus few comments inline

On 11/9/10 8:55 AM, Greg Bernstein wrote:
Hi Giovanni and Pierre, so it sounds like you want to define the equivalent of
    (a) TE Metric,
    (b) Admin Group, and
    (c) SRLGs
for "internal links" within a switch with OEO pools. This would then be utilized to make decisions for the path to be taken within a node. In addition, GMPLS signaling would need to be further extended to be able to describe the paths to be taken within a "node".
Well the goal was to expose some interesting properties that may influence your path computation

The current WSON information model and WSON encoding provides a representation of an WSON node for use in path selection within the network, but not within a node. This was in keeping with a minimalistic approach to representing a node and assumed very little about either internal node structure or control.
In term of node representation itself  your statement is still true. For OEO pools we all agree we need to know something (e.g. WSON i/f compatibility lists: FEC etc.) this does not mean to expose internal node topology but I would say we expose constrains.

Cheers
G

If path selection choice is actually needed within an "optical system" it seems to make more sense to model the system by multiple nodes and links, then one can just use the already defined GMPLS link attributes (TE Metric, Admin Group, SRLGs), WSON WG drafts, and not require any modifications to GMPLS signaling.

Greg & Young

On 11/8/10 12:49 PM, Young Lee wrote:
Hi Pierre,
On the second point you indicated below, I am not sure if we have agreed on the information to be conveyed. In my previous email, I asked you why we need the following sub-TLV in the resource block attribute (RBA) TLV:
Sub-TLV Type       Length     Name
     TBD        4 Bytes    TE-metric [alike RFC3630]
     TBD        4 Bytes    Administrative Group [alike RFC3630]
     TBD        8 Bytes    Link Local/Remote Identifiers [alike RFC4203]
     TBD        variable   Shared Risk Link Group [alike RFC4203]
These sub-TLV seem internal link (if not please clarify) and are duplicate with already existing TE TLV.
for internal link
Again, when you want to create a brand new Top level TLV, you have to answer why you need these new TLV when the existing mechanism works well. We are not simply talking about two different ways of putting information together. One method (yours) requires new processing on control plane s/w while the other method (ours) does not add additional overhead on existing control plane s/w.
Well, we were thinking about triggering this discussion. Pls find some answer in slide 9 (for wed session) I guess slide are already available.

Cheers
G

Young

 *   no need to urge on refining draft-zhang-ccamp-general-constraints-ospf-ext<http://tools.ietf.org/id/draft-zhang-ccamp-general-constraints-ospf-ext-00.txt> it is suitable as is in regards to the other documents.
 *   need to converge on the way OEO pools are depicted, knowing that we already aggree on what are the information to be conveyed are, but there is a diverging view on the way of organizing this information.
Best regards,
Pierre

Best Regards

Fatai

----- Original Message -----
From: Young Lee<mailto:[email-masked]>
To: 'CCAMP'<mailto:[email-masked]>
Sent: Friday, October 29, 2010 12:50 AM
Subject: [CCAMP] Merging of the WSON specific OSPF extensions
Hi Pierre,

*         Our approach is to RE-use the OSPF TE LSA node attribute TLV under which we define all the necessary sub-TLVs.

Sub-TLV Type       Length     Name

*         Section 2.4 is not clear to me.  You didn't include sub-TLV in Section 2.  Are you saying that connectivity matrix is a part of your RBA TLV? How is this connectivity matrix different from the one defined in section 3.5 in http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/ ?

Regards,

Greg & Young

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

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

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

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 11 Nov 2010 00:40:06 -0800

Hi Giovanni, I'm still trying to understand the differences that could 
affect the WSON info or encoding drafts.  Hopefully the minutes from the 
meeting captured the comments from the OSPF chair so we can take those 
into account in revising the high level TLV structure in the OSPF drafts 
if necessary. Please see my comments inline with yours to see if we have 
agreement/understanding or if we are missing some functionality.

Best Regards
Greg
On 11/9/2010 4:05 AM, Giovanni Martinelli wrote:
>> be utilized to make decisions for the path to be/taken within a 
>> node/. In addition, GMPLS signaling would need to be further extended 
>> to be able to describe the paths to be taken within a "node".
--> But, do we need these on "internal links"? Are we really giving the 
user choices of links within a node? Do you have a particular 
application or OEO architecture in mind where this is needed and 
wouldn't be better handled with a different mechanism. On a previously 
resolved issue you had a particular optical node architecture that we 
added some extensions to model, i.e., we had to modify WSON info and 
encoding.
> In term of node representation itself  your statement is still true. 
> For OEO pools we all agree we need to know something (e.g. WSON i/f 
---> This sounds like we are in agreement on this basic notions.  Do you 
or don't you need  the TE metric, Admin group, or SRLGs on "internal 
links" within the node?  If needed wouldn't an explicit multi-node model 
be just as effective and require fewer GMPLS enhancements?
>
> Cheers
> G
>
>>
>> If path selection choice is actually needed within an "optical 
>> system" it seems to make more sense to model the system by multiple 
>> nodes and links, then one can just use the already defined GMPLS link 
>> attributes (TE Metric, Admin Group, SRLGs), WSON WG drafts, and not 
>> require any modifications to GMPLS signaling.
>>
>> Greg & Young
>>
>>>> [WSON-Encode] and [WSON OSPF] are drafts that needs refinement to 
>>>> my point in order to achieve the convergence. It is not just a 
>>>> matter of adding material to it, and their being WG documents 
>>>> entitle all the more the WG to propose changes to its content.
>>>>
>>>> There is a real work to do in order to converge, but to cheer 
>>>> things up, that is not bad right now, we know what fits everyone, 
>>>> and we have isolated the differences that have to be worked on.
>>>>
>>>>                         + Why not just use the Top Level OSPF TE
>>>>                           LSA node attribute TLV which is existing
>>>>                           TOP level TLV?  Please let me know why
>>>>                           this TLV would not be proper?
>>>>

---

From: Acee Lindem <[email-masked]>
Date: Sun, 14 Nov 2010 17:55:31 -0500

Hi Greg,
My comment was that since this is a new top-level TLV, you could define the semantics such that the OEO pools could be split over multiple opaque LSAs and concatenated during the optical path computation. Note that you cannot change the semantics for LSAs containing the existing Link-TLV.

My other comments was with respect to LSA size. The protocol limit for LSA length is 64K. However, you really want each LSA to fit in a single LS Update without requiring IP fragmentation and reassembly.

Thanks,
Acee

On Nov 11, 2010, at 3:40 AM, Greg Bernstein wrote:

Hi Giovanni, I'm still trying to understand the differences that could affect the WSON info or encoding drafts.  Hopefully the minutes from the meeting captured the comments from the OSPF chair so we can take those into account in revising the high level TLV structure in the OSPF drafts if necessary. Please see my comments inline with yours to see if we have agreement/understanding or if we are missing some functionality.

Best Regards
Greg

plus few comments inline

--> But, do we need these on "internal links"? Are we really giving the user choices of links within a node? Do you have a particular application or OEO architecture in mind where this is needed and wouldn't be better handled with a different mechanism. On a previously resolved issue you had a particular optical node architecture that we added some extensions to model, i.e., we had to modify WSON info and encoding.

The current WSON information model and WSON encoding provides a representation of an WSON node for use in path selection within the network, but not within a node. This was in keeping with a minimalistic approach to representing a node and assumed very little about either internal node structure or control.
In term of node representation itself  your statement is still true. For OEO pools we all agree we need to know something (e.g. WSON i/f compatibility lists: FEC etc.) this does not mean to expose internal node topology but I would say we expose constrains.
---> This sounds like we are in agreement on this basic notions.  Do you or don't you need  the TE metric, Admin group, or SRLGs on "internal links" within the node?  If needed wouldn't an explicit multi-node model be just as effective and require fewer GMPLS enhancements?

Cheers
G

Greg & Young

Cheers
G

Young

Hi Fatai and Young,

Best regards,

Pierre

Best Regards

Fatai

----- Original Message -----
From: Young Lee<mailto:[email-masked]>
To: 'CCAMP'<mailto:[email-masked]>
Sent: Friday, October 29, 2010 12:50 AM
Subject: [CCAMP] Merging of the WSON specific OSPF extensions

Hi Pierre,

 *   I think we agreed on the encoding of the TLV’s that are necessary for WSON specific information according to: http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/

 *   Let me try to understand your rationale to create a new Top Level RBA TLV. Your original rationale for O-E-O TLV (old name for RBA TLV) was to differentiate dynamic information from static. But I don’t see your original rationale in your revision. If that is still an implicit rationale, you need to clearly state that.

    *   If so, Fatai’s draft clearly state the way to differentiate dynamic info from static info using an Opaque LSA mechanism discussed in Section 4 of http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/. In such as, we don’t need to create a new TOP Level TLV.

•         Our approach is to RE-use the OSPF TE LSA node attribute TLV under which we define all the necessary sub-TLVs.

•         I still have some problem as to why you still have these sub-TLV:

Sub-TLV Type       Length     Name

•         Section 2.4 is not clear to me.  You didn’t include sub-TLV in Section 2.  Are you saying that connectivity matrix is a part of your RBA TLV? How is this connectivity matrix different from the one defined in section 3.5 in http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/ ?

Regards,

Greg & Young

<ATT00001..txt>

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 15 Nov 2010 13:05:52 -0800

Hi Acee, for WSON specific OSPF extensions we have "blocks of resources" 
that need to be taken into during path computation. The information 
about these blocks is decomposed into the following "pieces":
(a) Resource block accessibility (a sparse matrix representation of the 
accessibility of a resource block to/from ingress and egress ports).
(b) Resource block wavelength constraints (models constraints on what 
wavelength can ingress/egress a resource block)
(c) Resource block information (# resources in the block, modulation, 
processing characteristics)
(d) Resource block state (dynamic)
(e) Block Share access wavelength availability (dynamic)

Most optical nodes have a fair amount of symmetry and hence any of the 
individual pieces above should fit in an MTU. The pieces are "self 
identifying" via a resource block identifier.
My simplistic assumption was to not ask for a new top level TLV and just 
use multiple opaque LSA instances of the existing top level node TLV to 
(a) separate relatively dynamic from relatively static information, and 
(b) send any of the above pieces separately if we can't fit them all 
within one MTU.
Is there a flaw in this logic?  If you are willing to give us a 
top-level TLV how would it make this any easier or efficient?

Thanks

Greg B.

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 15 Nov 2010 13:19:24 -0800

Hi Pierre, Giovanni and CCAMPers, see comments below.
Greg B.
On 11/9/2010 8:43 AM, PELOSO, PIERRE (PIERRE) wrote:
> I concur with Giovanni that the point of discussion ahead should 
> be focused on where to place the Ressource Block Information (RBI). 
> And the slides Giovanni will be presenting during ccamp session are 
> dealing with that.
--> Okay, I just sent an e-mail on this to see if we can establish the 
advantages/disadvantages between a new top level TLV or just using 
multiple opaque LSA instances.
> Regards,
> Pierre
> P.S.
> Let me just make a short comment (aside the main stream of discussion 
> related to place for RBI). This topic is related to the add-ons 
> objects TE-metric, admin group, and SRLGs, those are additional bits 
> of information that the operator would be entitled the right to use to 
> enrich its path computation. This enrichement may lead to the 
> selection of one OEO pool or another (either in the same node or in 
> different nodes). But to my opinion, this topic can come in a later 
> time, that is not the the hotest point.
--> This is a fundamental change since it introduces the requirement of 
"intra-node" path computation and control.  I don't see this as specific 
to WSON.  A number of large switches are assembled via the 
interconnection of subunits (racks, etc...).  As such they may wish to 
model this interconnection structure with the full complement of SRLG, 
TE-metric, admin group on the "intra-node links".  However this is a 
whole separate topic and it is not within the WSON Framework 
requirements.  I'm not sure if it would be within the CCAMP WG charter.  
But since it is a separate and more general topic, I think it is out of 
scope for the current WSON discussions.