Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

From: Greg Bernstein <[email-masked]>
Date: Mon, 03 Jan 2011 08:55:48 -0800

Hi Pierre, do you think we should still try to use the "node attribute 
top level TLV" from RFC5786? A complete node description may require 
multiple connectivity matrices and these could potentially become large. 
RFC5786 has the constraint:
     "*/The Node Attribute TLV MUST NOT appear in more than one TE LSA 
originated by a router/*.  Furthermore, such an LSA MUST NOT include 
more than one Node Attribute TLV."

So we couldn't split them up for MTU purposes. It seems that one new top 
level TLV for a node without the RFC5786 constraints would suffice. Do 
you think we need two? How would we justify two new top level TLVs to 
the OSPF WG when we have the ability to use multiple instances?

Other opinions?

Best Regards

Greg
On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote:
> Hi Greg,
> To start with, I am pretty in-line with the part related to the link 
> TLV, which was already agreed.
> Regarding the node related information, I am happy to see that you 
> consider splitting its information over 2 top-level TLVs, which we 
> have been proning in order to ease the scalability and the information 
> organisation.
> I do encourage you to adopt even more the concepts proned in 
> draft-peloso-ccamp-won-ospf-oeo, by defining this new top-level TLV in 
> a way that allows to have multiple instance of it, one for each 
> conistent entity of ressoruces.
> To detail my point of view, considering that I bet you would keep 
> inside the node attribute top-level TLV the connectivity matrix 
> object, and transfer the informations concerning the OEO ressources to 
> the new top-level TLV that you suggest to name Node Property. I have 
> no hard convinctions on any name, and this one can fit with me, it is 
> not the important thing anyway.
> I insist that, what seems more important to me is really to benefit 
> fully from the advantages brought by introducing a new top-level TLV 
> (which was apparently one of the thinks you were reluctant to do), 
> namely the capability to have one instance of this type per pool. Here 
> a pool, being a consistent bunch of OEO resources, sharing the fact 
> that updating the usage of one of them will have consequences on the 
> accessibility of the others. Which is to my mind the smallest 
> information entity that will need a single update on the modification 
> of usage of one of its members, hence the most compliant with scalability.
> To summarize, once the cost of introducing a new top-level TLV is 
> accepted, let's use the advantages of the concepts introduced in our 
> solution to their full extent, and then use a layout of information 
> compliant with that. Does this sems reasonnable for you, and for the WG ?
> - pierre
> P.S. Let's keep aside right now the discussions concerning the 
> administrative group, and TE metric sub-TLVs.
> ------------------------------------------------------------------------
> *De :* [email-masked] [mailto:[email-masked]] *De la 
> part de* Greg Bernstein
> *Envoyé :* mardi 14 décembre 2010 19:24
> *À :* CCAMP
> *Objet :* [CCAMP] Top Level TLVs for WSON and General Constraint 
> Extensions to OSPF (long)
>
>     Hi all two weeks ago we updated
>     draft-ietf-ccamp-general-constraint-encode and
>     draft-ietf-ccamp-rwa-wson-encode based on comments from the list
>     and the Beijing meeting. These changes were editorial in nature
>     and consisted of removing some informational text.
>     To move things forward in general we need to reach agreement on
>     the top level TLVs to be used to carry this information.  We have
>     two main types of information: (a) link related, and (b) node
>     related.  In addition, depending on the complexity of the system
>     we may want to split the information for a particular node or link
>     into multiple LSAs  to keep the size of the LSA below a particular
>     limit or to separate rapidly changing node or link information
>     from relatively static. In general multiple TE LSA instances
>     provide a mechanism for this.
>
>     *For Link information* *RFC3630* defines the "Traffic Engineering
>     LSA". This has area scope.
>     "One new LSA is defined, the Traffic Engineering LSA.  This LSA
>     describes routers, point-to-point links, and connections to
>     multi-access networks (similar to a Router LSA)."
>
>     Multiple instances can exist from a single source:
>     "The Instance field is an arbitrary value used to maintain
>     multiple Traffic Engineering LSAs.  A maximum of 16777216 Traffic
>     Engineering LSAs may be sourced by a single system."
>
>     Two top level TLVs are defined: Router Address TLV (section 2.4.1)
>     and Link TLV (section 2.4.2). The router address is just as it
>     says. The link TLV is the generally useful one for us:
>     "The Link TLV describes a single link.  It is constructed of a set
>     of sub-TLVs.  There are no ordering requirements for the sub-TLVs.
>     Only one Link TLV shall be carried in each LSA, allowing for fine
>     granularity changes in topology."
>
>     There does not appear to be any constraints on breaking up
>     information about a single link into multiple LSAs. For WSON use
>     we may want to keep static information (port wavelength
>     constraints) separate from dynamic information (wavelength
>     availability).
>
>     *For Node Level information* (such as connectivity matrices,
>     resource block information, resource block usage state) it seemed
>     like *RFC 5786* which has extensions for advertising a routers
>     local addresses in TE extensions would be useful. It defines the
>     OSPF TE LSA Node TLV and they state:
>     "It is anticipated that the Node Attribute TLV will also prove
>     more generally useful."
>     However in section 4.2 (Operation) they state:
>     "*/The Node Attribute TLV MUST NOT appear in more than one TE LSA
>     originated by a router/*.  Furthermore, such an LSA MUST NOT
>     include more than one Node Attribute TLV."
>
>     The first of these restrictions on use seems to preclude us from
>     separating traffic matrices, resource block descriptions, and
>     resource block utilization status into separate LSA instances
>     using this TLV. Unless this rule can be changed it seems that we
>     will need a new top level "node properties" TLV for use in both
>     WSON specific and General constraint extensions to OSPF.  Pierre
>     and Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to
>     define a new top level TLV for the resource block information,
>     however it seems that we probably should ask for a general "node
>     properties" (or whatever better name we can think of) top level
>     TLV that could be applied to the general constraint node
>     information (connectivity matrices) as well as the various
>     resource related quantities.
>
>     Pierre and Giovanni does this sound like a reasonable way forward?
>     Or do you have a different suggestion.  Comments and suggestions
>     from all are welcome.
>
>     Best Regards
>
>     Greg B.
>
>     -- 
>     ===================================================
>     Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>

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

---

From: Acee Lindem <[email-masked]>
Date: Thu, 6 Jan 2011 12:24:41 -0500

Hi Greg, 
I think it is better to get 1 or 2 new top-level TE TLVs than to overload the TE Node Attribute TLV" with the optical capabilities information. 
Thanks,
Acee 
On Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote:

> Hi Pierre, do you think we should still try to use the "node attribute top level TLV" from RFC5786? A complete node description may require multiple connectivity matrices and these could potentially become large. RFC5786 has the constraint: 
>     "The Node Attribute TLV MUST NOT appear in more than one TE LSA originated by a router.  Furthermore, such an LSA MUST NOT include more than one Node Attribute TLV." 
> 
> So we couldn't split them up for MTU purposes. It seems that one new top level TLV for a node without the RFC5786 constraints would suffice. Do you think we need two? How would we justify two new top level TLVs to the OSPF WG when we have the ability to use multiple instances?
> 
> Other opinions?
> 
> Best Regards
> 
> Greg 
>> To start with, I am pretty in-line with the part related to the link TLV, which was already agreed.
>>  
>> Regarding the node related information, I am happy to see that you consider splitting its information over 2 top-level TLVs, which we have been proning in order to ease the scalability and the information organisation.
>> I do encourage you to adopt even more the concepts proned in draft-peloso-ccamp-won-ospf-oeo, by defining this new top-level TLV in a way that allows to have multiple instance of it, one for each conistent entity of ressoruces.
>>  
>> To detail my point of view, considering that I bet you would keep inside the node attribute top-level TLV the connectivity matrix object, and transfer the informations concerning the OEO ressources to the new top-level TLV that you suggest to name Node Property. I have no hard convinctions on any name, and this one can fit with me, it is not the important thing anyway.
>> I insist that, what seems more important to me is really to benefit fully from the advantages brought by introducing a new top-level TLV (which was apparently one of the thinks you were reluctant to do), namely the capability to have one instance of this type per pool. Here a pool, being a consistent bunch of OEO resources, sharing the fact that updating the usage of one of them will have consequences on the accessibility of the others. Which is to my mind the smallest information entity that will need a single update on the modification of usage of one of its members, hence the most compliant with scalability.
>>  
>> To summarize, once the cost of introducing a new top-level TLV is accepted, let's use the advantages of the concepts introduced in our solution to their full extent, and then use a layout of information compliant with that. Does this sems reasonnable for you, and for the WG ?
>>  
>> - pierre
>>  
>> P.S. Let's keep aside right now the discussions concerning the administrative group, and TE metric sub-TLVs.
>> De : [email-masked] [mailto:[email-masked]] De la part de Greg Bernstein
>> Envoyé : mardi 14 décembre 2010 19:24
>> À : CCAMP
>> Objet : [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)
>> 
>> Hi all two weeks ago we updated draft-ietf-ccamp-general-constraint-encode and draft-ietf-ccamp-rwa-wson-encode based on comments from the list and the Beijing meeting. These changes were editorial in nature and consisted of removing some informational text. 
>> To move things forward in general we need to reach agreement on the top level TLVs to be used to carry this information.  We have two main types of information: (a) link related, and (b) node related.  In addition, depending on the complexity of the system we may want to split the information for a particular node or link into multiple LSAs  to keep the size of the LSA below a particular limit or to separate rapidly changing node or link information from relatively static. In general multiple TE LSA instances provide a mechanism for this.
>> 
>> For Link information RFC3630 defines the "Traffic Engineering LSA". This has area scope.
>> "One new LSA is defined, the Traffic Engineering LSA.  This LSA describes routers, point-to-point links, and connections to multi-access networks (similar to a Router LSA)."
>> 
>> "The Instance field is an arbitrary value used to maintain multiple Traffic Engineering LSAs.  A maximum of 16777216 Traffic Engineering LSAs may be sourced by a single system."
>> 
>> Two top level TLVs are defined: Router Address TLV (section 2.4.1) and Link TLV (section 2.4.2). The router address is just as it says. The link TLV is the generally useful one for us:
>> "The Link TLV describes a single link.  It is constructed of a set of sub-TLVs.  There are no ordering requirements for the sub-TLVs. Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology."
>> 
>> There does not appear to be any constraints on breaking up information about a single link into multiple LSAs. For WSON use we may want to keep static information (port wavelength constraints) separate from dynamic information (wavelength availability).
>> 
>> For Node Level information (such as connectivity matrices, resource block information, resource block usage state) it seemed like RFC 5786 which has extensions for advertising a routers local addresses in TE extensions would be useful. It defines the OSPF TE LSA Node TLV and they state:
>> "It is anticipated that the Node Attribute TLV will also prove more generally useful."
>> "The Node Attribute TLV MUST NOT appear in more than one TE LSA originated by a router.  Furthermore, such an LSA MUST NOT include more than one Node Attribute TLV."
>> 
>> The first of these restrictions on use seems to preclude us from separating traffic matrices, resource block descriptions, and resource block utilization status into separate LSA instances using this TLV. Unless this rule can be changed it seems that we will need a new top level "node properties" TLV for use in both WSON specific and General constraint extensions to OSPF.  Pierre and Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to define a new top level TLV for the resource block information, however it seems that we probably should ask for a general "node properties" (or whatever better name we can think of) top level TLV that could be applied to the general constraint node information (connectivity matrices) as well as the various resource related quantities.  
>> 
>> Pierre and Giovanni does this sound like a reasonable way forward? Or do you have a different suggestion.  Comments and suggestions from all are welcome.
>> 
>> Best Regards
>> 
>> Greg B.
>> 
>> -- 
> <ATT00001..txt>

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 06 Jan 2011 10:17:15 -0800

Thanks Acee.
Okay CCAMPers (Fatai and Pierre in particular) do we need one or two?  
What would be the justification for two new Top level TLVs for node 
related information?
We've talked before about static versus dynamic information, but for 
link information we seemed to have settled on using multiple LSA 
instances for this purpose, i.e., keep the static stuff in LSA instances 
different from the dynamic stuff (e.g. wavelength availability).  Hence 
I don't see the need for two top level TLVs.

Greg

On 1/6/2011 9:24 AM, Acee Lindem wrote:
> Hi Greg,
> I think it is better to get 1 or 2 new top-level TE TLVs than to 
> overload the TE Node Attribute TLV" with the optical capabilities 
> information.
> Thanks,
> Acee
>> Hi Pierre, do you think we should still try to use the "node 
>> attribute top level TLV" from RFC5786? A complete node description 
>> may require multiple connectivity matrices and these could 
>> potentially become large. RFC5786 has the constraint:
>> So we couldn't split them up for MTU purposes. It seems that one new 
>> top level TLV for a node without the RFC5786 constraints would 
>> suffice. Do you think we need two? How would we justify two new top 
>> level TLVs to the OSPF WG when we have the ability to use multiple 
>> instances?
>>
>> Other opinions?
>>
>> Best Regards
>>
>> Greg
>>> have been proning in order to ease the scalability and the 
>>> information organisation.
>>> draft-peloso-ccamp-won-ospf-oeo, by defining this new top-level TLV 
>>> in a way that allows to have multiple instance of it, one for each 
>>> object, and transfer the informations concerning the OEO ressources 
>>> to the new top-level TLV that you suggest to name Node Property. I 
>>> have no hard convinctions on any name, and this one can fit with me, 
>>> it is not the important thing anyway.
>>> namely the capability to have one instance of this type per pool. 
>>> Here a pool, being a consistent bunch of OEO resources, sharing the 
>>> fact that updating the usage of one of them will have 
>>> consequences on the accessibility of the others. Which is to my mind 
>>> the smallest information entity that will need a single update on 
>>> the modification of usage of one of its members, hence the most 
>>> compliant with scalability.
>>>     the top level TLVs to be used to carry this information.  We
>>>     have two main types of information: (a) link related, and (b)
>>>     node related.  In addition, depending on the complexity of the
>>>     system we may want to split the information for a particular
>>>     node or link into multiple LSAs  to keep the size of the LSA
>>>     below a particular limit or to separate rapidly changing node or
>>>     link information from relatively static. In general multiple TE
>>>     LSA instances provide a mechanism for this.
>>>
>>>     *For Link information* *RFC3630* defines the "Traffic
>>>     Engineering LSA". This has area scope.
>>>     multiple Traffic Engineering LSAs.  A maximum of 16777216
>>>     Traffic Engineering LSAs may be sourced by a single system."
>>>
>>>     Two top level TLVs are defined: Router Address TLV (section
>>>     2.4.1) and Link TLV (section 2.4.2). The router address is just
>>>     as it says. The link TLV is the generally useful one for us:
>>>     "The Link TLV describes a single link.  It is constructed of a
>>>     set of sub-TLVs.  There are no ordering requirements for the
>>>     sub-TLVs. Only one Link TLV shall be carried in each LSA,
>>>     allowing for fine granularity changes in topology."
>>>
>>>     resource block information, resource block usage state) it
>>>     seemed like *RFC 5786* which has extensions for advertising a
>>>     routers local addresses in TE extensions would be useful. It
>>>     defines the OSPF TE LSA Node TLV and they state:
>>>     "*/The Node Attribute TLV MUST NOT appear in more than one TE
>>>     LSA originated by a router/*.  Furthermore, such an LSA MUST NOT
>>>     and Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted
>>>     to define a new top level TLV for the resource block
>>>     information, however it seems that we probably should ask for a
>>>     general "node properties" (or whatever better name we can think
>>>     of) top level TLV that could be applied to the general
>>>     constraint node information (connectivity matrices) as well as
>>>     the various resource related quantities.
>>>
>>>     Pierre and Giovanni does this sound like a reasonable way
>>>     forward? Or do you have a different suggestion.  Comments and
>>>     suggestions from all are welcome.
>>>
>>>     Best Regards
>>>
>>>     Greg B.
>>>
>>>     --

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Fri, 7 Jan 2011 18:13:12 +0100

Hi Greg, Acee and Every CCAMPers,

My answer is definitively two, Acee mentions there is no issue implementing one or two regarding OSPF, hence I really see no blocking point against two new Top level TLV.
On top of ensuring the split between static and dynamic information. It also provides an intrinsic structure of information organization.
One type of LSA is structured around the connectivity constraints of the nodes.
Another type of LSA is structured around the resources in the node. One instance per ressource block. Hence one LSA of this type updated only at each time.
This feature is achieved with no extra-cost on the overall information to be conveyed, while the one to be updated is intrinsically placed in independant LSA.
To conclude I am all the more convinced that we need to benefit of the inherent organization of information spread over multiple type of LSAs. It provides an inherent solution to address static and dynamic information inside nodes, which is altogether efficient regarding the amount of information to be updated, while providing a clear layout of information for OSPF-TE.

Pierre

________________________________
De : Greg Bernstein [mailto:[email-masked]]
Envoyé : jeudi 6 janvier 2011 19:17
À : Acee Lindem
Cc : PELOSO, PIERRE (PIERRE); CCAMP
Objet : Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Thanks Acee.
Okay CCAMPers (Fatai and Pierre in particular) do we need one or two?  What would be the justification for two new Top level TLVs for node related information?
We've talked before about static versus dynamic information, but for link information we seemed to have settled on using multiple LSA instances for this purpose, i.e., keep the static stuff in LSA instances different from the dynamic stuff (e.g. wavelength availability).  Hence I don't see the need for two top level TLVs.

Greg

Other opinions?

Best Regards

Greg

- pierre

P.S. Let's keep aside right now the discussions concerning the administrative group, and TE metric sub-TLVs.
________________________________
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Greg Bernstein
Envoyé : mardi 14 décembre 2010 19:24
À : CCAMP
Objet : [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Best Regards

Greg B.

<ATT00001..txt>

---

From: Leeyoung <[email-masked]>
Date: Fri, 07 Jan 2011 19:26:57 +0000

Hi,

Before we jump to discussing how many Top Level Node TLV we need for WSON implementation, I have a question on the restriction of Node Attribute TLV not allowing more than one TE LSA in RFC 5786.
Greg quoted the following clause from RFC 5786, section 4.2 (Operation) in his previous email:

Can anyone explain the rational for this restriction? In addition, in what context such an appeared-to-be unreasonable restriction have come along?

It may be worth exploring lifting up this restriction as an alternative. Perhaps the authors of RFC 5786 give us the original intent of this restriction.

If there is a strong reason not to lift-up this restriction, I am fine with exploring the thread of discussion on top level TLV issue.
Thanks.

Young

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of PELOSO, PIERRE (PIERRE)
Sent: Friday, January 07, 2011 11:13 AM
To: Greg Bernstein; Acee Lindem
Cc: CCAMP
Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Pierre

Greg

Other opinions?

Best Regards

Greg

- pierre

Best Regards

Greg B.

--

--

<ATT00001..txt>

--

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 10 Jan 2011 09:58:41 +0800

Hi Pierre and Greg,

I need to remind you both that [OSPF-Gen] ("draft-zhang-ccamp-general-constraints-ospf-ext-00.txt") is general (not specific to WSON). 

"Connectivity Matrix" defined in [OSPF-Gen] is a kind of node attribute, and it is static like "IPv4/v6 Local Address" defined in RFC5786, so we can resue "Node Attribute" top TLV to advertise Connectivity Matrix information without breaking the existing rules/restrictions defined in RFC5786.

For WSON specific information(ie., OEO stuff), I think we should define a new top TLV in order to comply with the rules defined in RFC5786 (or we may  life-up this restriction defined in RFC5786 as Young suggested).

Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

  ----- Original Message ----- 
  From: PELOSO, PIERRE (PIERRE) 
  To: Greg Bernstein ; Acee Lindem 
  Cc: CCAMP 
  Sent: Saturday, January 08, 2011 1:13 AM
  Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

  Pierre

----------------------------------------------------------------------------

    Thanks Acee.  

    Greg

        Other opinions?

        Best Regards

        Greg 

          - pierre

----------------------------------------------------------------------

            Best Regards

            Greg B.

<ATT00001..txt>

------------------------------------------------------------------------------

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

---

From: Leeyoung <[email-masked]>
Date: Tue, 11 Jan 2011 22:21:13 +0000

Hi Pierre, Greg and Fatai,

I tend to agree with Fatai. Since the connectivity matrix is a generic aspect, we still can use existing TOP-level Node Attribute TLV. Please make sure that the connectivity matrix is non-WSON property. I think it was the intention of the CCAMP co-chairs to delineate WSON specific from Generic stuffs.

If we can agree with this, I think we can create ONE new TOP level TLV, "Node Attribute for Optical Resources" (tentative name) in which to advertise all Optical Resource related information.

Although I still have problem understanding the RFC 5786 restriction on why the TE LSA wouldn't allow more than one Node Attribute TLV, I want to resolve this issue and move the stalled OSPF extensions.

So Pierre, Greg and Fatai, can we agree on this discussion. In summary:

·         Use existing Node Attribute TLV for the connectivity matrix encoding
·         Create ONE NEW top level node TLV (name to TBD) to encode all the optical resource related information.

If we can agree, I think we can move on. If that is the case, I will update current WSON-specific WG draft (http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibility-ospf/) to recommend use of a new top level node TLV for the encoding of all optical resource related information.

And there is no change in Fatai's draft (http://datatracker.ietf.org/doc/draft-zhang-ccamp-general-constraints-ospf-ext/)

I look forward to hearing from you.

Best Regards,
Young

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Sunday, January 09, 2011 7:59 PM
To: PELOSO, PIERRE (PIERRE); Greg Bernstein; Acee Lindem
Cc: CCAMP
Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Hi Pierre and Greg,

Thanks

Fatai

----- Original Message -----
From: PELOSO, PIERRE (PIERRE)<mailto:[email-masked]>
To: Greg Bernstein<mailto:[email-masked]> ; Acee Lindem<mailto:[email-masked]>
Cc: CCAMP<mailto:[email-masked]>
Sent: Saturday, January 08, 2011 1:13 AM
Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Pierre

Greg

Other opinions?

Best Regards

Greg

- pierre

Best Regards

Greg B.

--

--

<ATT00001..txt>

--

---

From: Acee Lindem <[email-masked]>
Date: Tue, 11 Jan 2011 20:34:48 -0500

Hi Young, Fatai, and Greg, 

I'm not too concerned about lifting the restriction on the single TE LSA containing the TE Node Attribute TLV. In fact, we are removing this restriction for ASON single in order for a control place node to advertise reachability information for more than one node in the transport place. However, I still don't think that the WSON switching capabilities belong here. As for the general constraints document, this looks more along the lines of what could go here. 

Thanks,
Acee

On Jan 11, 2011, at 5:21 PM, Leeyoung wrote:

> If we can agree with this, I think we can create ONE new TOP level TLV, “Node Attribute for Optical Resources” (tentative name) in which to advertise all Optical Resource related information.
>  
> Although I still have problem understanding the RFC 5786 restriction on why the TE LSA wouldn’t allow more than one Node Attribute TLV, I want to resolve this issue and move the stalled OSPF extensions.
>  
> And there is no change in Fatai’s draft (http://datatracker.ietf.org/doc/draft-zhang-ccamp-general-constraints-ospf-ext/)
>

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 12 Jan 2011 10:22:52 -0800

Hi Acee, Young, Fatai and Pierre,
the approach outlined below by Young and Acee below sounds great to me!
Best Regards
Greg
On 1/11/2011 5:34 PM, Acee Lindem wrote:
> I'm not too concerned about lifting the restriction on the single TE 
> LSA containing the TE Node Attribute TLV. In fact, we are removing 
> this restriction for ASON single in order for a control place node to 
> advertise reachability information for more than one node in the 
> transport place. However, I still don't think that the WSON switching 
> capabilities belong here. As for the general constraints document, 
> this looks more along the lines of what could go here.
>
> Thanks,
> Acee
>
>> I tend to agree with Fatai. Since the connectivity matrix is a 
>> generic aspect, we still can use existing TOP-level Node Attribute 
>> TLV. Please make sure that the connectivity matrix is non-WSON 
>> property. I think it was the intention of the CCAMP co-chairs to 
>> delineate WSON specific from Generic stuffs.
>>
>> If we can agree with this, I think we can create ONE new TOP level 
>> TLV, “Node Attribute for Optical Resources” (tentative name) in which 
>> to advertise all Optical Resource related information.
>>
>> Although I still have problem understanding the RFC 5786 restriction 
>> on why the TE LSA wouldn’t allow more than one Node Attribute TLV, I 
>> want to resolve this issue and move the stalled OSPF extensions.
>>
>> ·Use existing Node Attribute TLV for the connectivity matrix encoding
>>
>> ·Create ONE NEW top level node TLV (name to TBD) to encode all the 
>> optical resource related information.
>>
>> If we can agree, I think we can move on. If that is the case, I will 
>> update current WSON-specific WG draft 
>> (http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibility-ospf/) 
>> to recommend use of a new top level node TLV for the encoding of all 
>> optical resource related information.
>>
>> And there is no change in Fatai’s draft 
>> (http://datatracker.ietf.org/doc/draft-zhang-ccamp-general-constraints-ospf-ext/) 
>>
>>
>> *From:[email-masked] <mailto:[email-masked]> 
>> [mailto:[email-masked]] *On Behalf Of *Fatai Zhang
>> *Sent:* Sunday, January 09, 2011 7:59 PM
>> *To:* PELOSO, PIERRE (PIERRE); Greg Bernstein; Acee Lindem
>> *Cc:* CCAMP
>> *Subject:* Re: [CCAMP] Top Level TLVs for WSON and General Constraint 
>> I need to remind you both that [OSPF-Gen] 
>> ("draft-zhang-ccamp-general-constraints-ospf-ext-00.txt") is general 
>> (not specific to WSON).
>>
>> "Connectivity Matrix" defined in [OSPF-Gen] is a kind of node 
>> attribute, and it is static like "IPv4/v6 Local Address" defined in 
>> RFC5786, so we can resue "Node Attribute" top TLV to advertise 
>> Connectivity Matrix information without breaking the existing 
>> rules/restrictions defined in RFC5786.
>>
>> For WSON specific information(ie., OEO stuff), I think we should 
>> define a new top TLV in order to comply with the rules defined in 
>> RFC5786 (or we may  life-up this restriction defined in RFC5786 as 
>> Young suggested).
>>
>>
>> Thanks
>>
>> Fatai
>>
>>     *From:*PELOSO, PIERRE (PIERRE)
>>     <mailto:[email-masked]>
>>
>>     *To:*Greg Bernstein <mailto:[email-masked]> ; Acee
>>     Lindem <mailto:[email-masked]>
>>
>>     *Cc:*CCAMP <mailto:[email-masked]>
>>
>>     *Sent:*Saturday, January 08, 2011 1:13 AM
>>
>>     *Subject:*Re: [CCAMP] Top Level TLVs for WSON and General
>>     Constraint Extensions to OSPF (long)
>>
>>     My answer is definitively two, Acee mentions there is no issue
>>     implementing one or two regarding OSPF, hence I really see no
>>     blocking point against two new Top level TLV.
>>
>>     On top of ensuring the split between static and dynamic
>>     information. It also provides an intrinsic structure of
>>     information organization.
>>
>>     Another type of LSA is structured around the resources in the
>>     node. One instance per ressource block. Hence one LSA of this
>>     type updated only at each time.
>>
>>     This feature is achieved with no extra-cost on the overall
>>     information to be conveyed, while the one to be updated is
>>     intrinsically placed in independant LSA.
>>
>>     To conclude I am all the more convinced that we need to benefit
>>     of the inherent organization of information spread over multiple
>>     type of LSAs. It provides an inherent solution to address static
>>     and dynamic information inside nodes, which is altogether
>>     efficient regarding the amount of information to be updated,
>>     while providing a clear layout of information for OSPF-TE.
>>
>>     Pierre
>>
>>         *De :*Greg Bernstein [mailto:[email-masked]]
>>         *Envoyé :* jeudi 6 janvier 2011 19:17
>>         *À :* Acee Lindem
>>         *Cc :* PELOSO, PIERRE (PIERRE); CCAMP
>>         *Objet :* Re: [CCAMP] Top Level TLVs for WSON and General
>>         Constraint Extensions to OSPF (long)
>>
>>         Thanks Acee.
>>         Okay CCAMPers (Fatai and Pierre in particular) do we need one
>>         or two?  What would be the justification for two new Top
>>         level TLVs for node related information?
>>         We've talked before about static versus dynamic information,
>>         but for link information we seemed to have settled on using
>>         multiple LSA instances for this purpose, i.e., keep the
>>         static stuff in LSA instances different from the dynamic
>>         stuff (e.g. wavelength availability).  Hence I don't see the
>>         need for two top level TLVs.
>>
>>         Greg
>>
>>
>>         I think it is better to get 1 or 2 new top-level TE TLVs than
>>         to overload the TE Node Attribute TLV" with the optical
>>         capabilities information.
>>
>>         Thanks,
>>
>>         Acee
>>
>>         attribute top level TLV" from RFC5786? A complete node
>>         description may require multiple connectivity matrices and
>>         these could potentially become large. RFC5786 has the
>>         constraint:
>>             "*/The Node Attribute TLV MUST NOT appear in more than
>>         one TE LSA originated by a router/*.  Furthermore, such an
>>         LSA MUST NOT include more than one Node Attribute TLV."
>>
>>         So we couldn't split them up for MTU purposes. It seems that
>>         one new top level TLV for a node without the RFC5786
>>         constraints would suffice. Do you think we need two? How
>>         would we justify two new top level TLVs to the OSPF WG when
>>         we have the ability to use multiple instances?
>>
>>         Other opinions?
>>
>>         Best Regards
>>
>>         Greg
>>         Regarding the node related information, I am happy to see
>>         that you consider splitting its information over 2 top-level
>>         TLVs, which we have been proning in order to ease the
>>         scalability and the information organisation.
>>
>>         draft-peloso-ccamp-won-ospf-oeo, by defining this new
>>         top-level TLV in a way that allows to have multiple instance
>>         of it, one for each conistent entity of ressoruces.
>>
>>         To detail my point of view, considering that I bet you would
>>         keep inside the node attribute top-level TLV the connectivity
>>         matrix object, and transfer the informations concerning the
>>         OEO ressources to the new top-level TLV that you suggest to
>>         name Node Property. I have no hard convinctions on any name,
>>         and this one can fit with me, it is not the important thing
>>         anyway.
>>
>>         I insist that, what seems more important to me is really to
>>         benefit fully from the advantages brought by introducing a
>>         new top-level TLV (which was apparently one of the thinks you
>>         were reluctant to do), namely the capability to have one
>>         instance of this type per pool. Here a pool, being a
>>         consistent bunch of OEO resources, sharing the fact that
>>         updating the usage of one of them will have consequences on
>>         the accessibility of the others. Which is to my mind the
>>         smallest information entity that will need a single update on
>>         the modification of usage of one of its members, hence the
>>         most compliant with scalability.
>>
>>         To summarize, once the cost of introducing a new top-level
>>         TLV is accepted, let's use the advantages of the concepts
>>         introduced in our solution to their full extent, and then use
>>         a layout of information compliant with that. Does this sems
>>         reasonnable for you, and for the WG ?
>>
>>         - pierre
>>
>>         P.S. Let's keep aside right now the discussions concerning
>>         the administrative group, and TE metric sub-TLVs.
>>
>>         *De :[email-masked] <mailto:[email-masked]>
>>         [mailto:[email-masked]] *De la part de* Greg Bernstein
>>         *Objet :* [CCAMP] Top Level TLVs for WSON and General
>>         Constraint Extensions to OSPF (long)
>>
>>             draft-ietf-ccamp-rwa-wson-encode based on comments from
>>             the list and the Beijing meeting. These changes were
>>             editorial in nature and consisted of removing some
>>             informational text.
>>             To move things forward in general we need to reach
>>             agreement on the top level TLVs to be used to carry this
>>             information.  We have two main types of information: (a)
>>             link related, and (b) node related.  In addition,
>>             depending on the complexity of the system we may want to
>>             split the information for a particular node or link into
>>             multiple LSAs  to keep the size of the LSA below a
>>             particular limit or to separate rapidly changing node or
>>             link information from relatively static. In general
>>             multiple TE LSA instances provide a mechanism for this.
>>
>>             "One new LSA is defined, the Traffic Engineering LSA. 
>>             This LSA describes routers, point-to-point links, and
>>             connections to multi-access networks (similar to a Router
>>             LSA)."
>>
>>             "The Instance field is an arbitrary value used to
>>             maintain multiple Traffic Engineering LSAs.  A maximum of
>>             16777216 Traffic Engineering LSAs may be sourced by a
>>             single system."
>>
>>             Two top level TLVs are defined: Router Address TLV
>>             (section 2.4.1) and Link TLV (section 2.4.2). The router
>>             address is just as it says. The link TLV is the generally
>>             useful one for us:
>>             "The Link TLV describes a single link.  It is constructed
>>             of a set of sub-TLVs.  There are no ordering requirements
>>             for the sub-TLVs. Only one Link TLV shall be carried in
>>             each LSA, allowing for fine granularity changes in topology."
>>
>>             There does not appear to be any constraints on breaking
>>             up information about a single link into multiple LSAs.
>>             For WSON use we may want to keep static information (port
>>             wavelength constraints) separate from dynamic information
>>             (wavelength availability).
>>
>>             *For Node Level information* (such as connectivity
>>             matrices, resource block information, resource block
>>             usage state) it seemed like *RFC 5786* which has
>>             extensions for advertising a routers local addresses in
>>             TE extensions would be useful. It defines the OSPF TE LSA
>>             Node TLV and they state:
>>             "*/The Node Attribute TLV MUST NOT appear in more than
>>             one TE LSA originated by a router/*.  Furthermore, such
>>             an LSA MUST NOT include more than one Node Attribute TLV."
>>
>>             The first of these restrictions on use seems to preclude
>>             us from separating traffic matrices, resource block
>>             descriptions, and resource block utilization status into
>>             separate LSA instances using this TLV. Unless this rule
>>             can be changed it seems that we will need a new top level
>>             "node properties" TLV for use in both WSON specific and
>>             General constraint extensions to OSPF.  Pierre and
>>             Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt
>>             wanted to define a new top level TLV for the resource
>>             block information, however it seems that we probably
>>             should ask for a general "node properties" (or whatever
>>             better name we can think of) top level TLV that could be
>>             applied to the general constraint node information
>>             (connectivity matrices) as well as the various resource
>>             related quantities.
>>
>>             forward? Or do you have a different suggestion.  Comments
>>             and suggestions from all are welcome.
>>
>>             Best Regards
>>
>>             Greg B.
>>
>>
>>             -- 
>>
>>             DrGreg Bernstein, Grotto Networking (510) 573-2237
>>
>>               
>>
>>
>>
>>
>>         -- 
>>
>>         DrGreg Bernstein, Grotto Networking (510) 573-2237
>>
>>           
>>
>>         <ATT00001..txt>
>>
>>
>>
>>
>>         -- 
>>
>>         DrGreg Bernstein, Grotto Networking (510) 573-2237
>>
>>           
>>

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Mon, 17 Jan 2011 22:19:56 +0100

Hi everyone,

Point 1: I do agree as well to have a top level TLV for the connectivity matrix and another type of top level TLV to place the information related to oeo encoding.
Then I feel that we can conclude as agreed the usage of TE node attribute for the connectivity matrix.

Point 2: Regarding the oeo, creating a new type of TLV is a perfect solution, that I am supporting for sure.
Once this being agreed and before jumping too fast in editing http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibility-ospf/, I am convinced that it is the right time to discuss how the encodings provided in http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-07.txt can be organized in the newly created top level TLV. Actually, for my part I see different options to take the best of this novelty concerning this layout of encodings.

Hence, as a WG, we have here a genuine opportunity to examine these options, thus possibly addressing during this review how those difference in layouts can influence the size of the corresponding LSA in order for those to fit in a single MTU as often as possible, while insuring OSPF scalability.

[For clarification needs, I do not mean changing the inner content of the encodings, I would just make sure that the way they are gathered inside the newly created top-level TLV is addressing everyone needs.]

Any comments?

Regards to all,

Pierre

________________________________
De : Greg Bernstein [mailto:[email-masked]]
Envoyé : mercredi 12 janvier 2011 19:23
À : Acee Lindem
Cc : Leeyoung; Fatai Zhang; PELOSO, PIERRE (PIERRE); CCAMP
Objet : Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Thanks,
Acee

*         Use existing Node Attribute TLV for the connectivity matrix encoding
*         Create ONE NEW top level node TLV (name to TBD) to encode all the optical resource related information.
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Fatai Zhang

Thanks

Fatai

----- Original Message -----
From: PELOSO, PIERRE (PIERRE)<mailto:[email-masked]>
To: Greg Bernstein<mailto:[email-masked]> ; Acee Lindem<mailto:[email-masked]>
Cc: CCAMP<mailto:[email-masked]>
Sent: Saturday, January 08, 2011 1:13 AM
Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Greg

Other opinions?

Best Regards

Greg

Best Regards

Greg B.

--

--

<ATT00001..txt>

--