Re: [CCAMP] Change 1: Introduction of resource pool entity (was Re: Moving the WSON discussion forward)

[Leeyoung <[e-mail]>]

Hi Pierre,

In regards to the top-level TLV discussion, please recall what you have agreed while ago from the archive. 
Between you and Fatai and Greg and Acee and myself, we basically agreed what I proposed: 

·         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. 

As Greg, mentioned, we do NOT need to create multiple top level TLV's one for static and another for dynamic -- multi-instance is good enough, which has been well adopted practice. I just appended the archived emails to remind you what you have agreed in the past -- I thought this issue has been resolved clearly in the past. 

CCAMPers, please pardon me attaching a long list of email, but I just wanted to recall the WG what we have nailed down already with respect to one of the issues Pierre raised again recently. 

Thanks.

Young

--------------------------------------------------------------------------------
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

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

To: Greg Bernstein <gregb at grotto-networking.com>, Acee Lindem <acee.lindem at ericsson.com> 
Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: "PELOSO, PIERRE (PIERRE)" <pierre.peloso at alcatel-lucent.com> 
Date: Mon, 17 Jan 2011 22:19:56 +0100 
Accept-language: fr-FR, en-US 
Acceptlanguage: fr-FR, en-US 
Cc: CCAMP <ccamp at ietf.org> 
Delivered-to: ccamp at core3.amsl.com 
In-reply-to: <4D2DF17C.3000407 at grotto-networking.com> 
List-archive: <http://www.ietf.org/mail-archive/web/ccamp> 
List-help: <mailto:[e-mail]?subject=help> 
List-id: Discussion list for the CCAMP working group <ccamp.ietf.org> 
List-post: <mailto:[e-mail]> 
List-subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:[e-mail]?subject=subscribe> 
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:[e-mail]?subject=unsubscribe> 
References: <4D07B635.1030503 at grotto-networking.com> <CCBFBB7025DF984494DEC3285C0581521269ED11D9 at FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <4D21FF94.8090205 at grotto-networking.com> <F0BB74A9-08FC-4751-A72C-1899A0C73C9A at ericsson.com> <4D26072B.8040902 at grotto-networking.com> <CCBFBB7025DF984494DEC3285C0581521269FA5E69 at FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <745A5455E5D14361B3311D49116C8976 at china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E1736A6D4 at DFWEML501-MBX.china.huawei.com> <01D37ACD-AB16-4666-8252-517538B40484 at ericsson.com> <4D2DF17C.3000407 at grotto-networking.com> 
Thread-index: AcuyhcIrC8w+Q4OFQnWD57z9idnFawBqHDvg 
Thread-topic: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 

--------------------------------------------------------------------------------
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:gregb at grotto-networking.com] 
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)


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: 
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:


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: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] 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,


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: [phone]
Fax: [phone]

----- 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)


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:gregb at grotto-networking.com] 
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


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 

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 
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 : ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] 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 [phone]
 





-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]
 
<ATT00001..txt>







-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]
 

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

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






-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]


 

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

References: 
[CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Greg Bernstein
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: PELOSO, PIERRE (PIERRE)
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Greg Bernstein
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Acee Lindem
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Greg Bernstein
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: PELOSO, PIERRE (PIERRE)
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Fatai Zhang
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Leeyoung
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Acee Lindem
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Greg Bernstein
Prev by Date: Re: [CCAMP] MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07 
Next by Date: [CCAMP] AD review of draft-ietf-ccamp-mpls-tp-cp-framework 
Previous by thread: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
Next by thread: Re: [CCAMP] Comment on draft-ietf-ccamp-oam-configuration-fwk 
Index(es): 
Date 
Thread  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of PELOSO, PIERRE (PIERRE)
Sent: Wednesday, July 13, 2011 10:44 AM
To: [e-mail]
Subject: [CCAMP] Change 1: Introduction of resource pool entity (was Re: Moving the WSON discussion forward)

Hi Greg and CCAMPer's,

As in the preceding mail which summarized the 3 main changes proposed by draft-peloso-ccamp-wson-ospf-oeo, become too big to be easily read through, I've been splitting the 3 points in 3 different threads, this one deals with change 1:  
Introduction of the Resource Pool entity inside the model, which allows the definition of several resource entites per node independantly floodable.
MOTIVATION: to decrease the size of flooding upon LSP changes (setup or tear down). (Resource Pool = group of resource blocks with same connectivity constraints).

Best Regards,

Pierre

[SNIP]

>>>       1. Introduction of the Resource Pool entity inside the model, 
>>> which allows the definition of several resource entites per node 
>>> independantly floodable.
>>> MOTIVATION: to decrease the size of flooding upon LSP changes (setup 
>>> or tear down). (Resource Pool = group of resource blocks with same 
>>> connectivity constraints)
>> -->  There is already a standard mechanism in OSPF-TE for achieving 
>> --> this
>> (multiple LSA instances) which is already in common use in MPLS and 
>> GMPLS so this change is unneeded. The current WSON encoding model 
>> includes very fine granularity in sub-TLVs hence this change would 
>> not achieve the stated "MOTIVATION" any better than the current approach.
> The change proposed by draft-peloso does mandate (implicitly, this 
> should be definitely changed) to have one LSA instance per top level TLV.
--> Hmm, other GMPLS specifications go the other way and restrict the
number of top level TLVs (usually one) per LSA.
This top level TLV is viewed as a container for a given type of information. If we have more than one "item" of information of a particular type you have the option of putting them in separate LSA instances. All the LSA instances together form the link state database and are used in path computation.  OSPF's reliable flooding mechanism will make sure the information gets there.  Note, that unlike the IP routing case where slightly out of date information can cause loops/blackholes, in the GMPLS case at worse the signaling request will fail somewhere along the path selected.
-->[Pierre]
My first comment here is that in our current case, WSON extensions are loading the CP heavily with various information, then as long as possible, the intent here is to avoid cranck-back. If cranck-back is not dammageable, it is as efficient to rely on a distributed wavelength assignment for which current GMPLS, possibly improved with signalling extensions provided in the relevant draft is sufficient. To sum-up my point, I personnaly hope that we are not doing all this work, to reach the conclusion that no better than without all these extensions if the signaling fails it is not important. 

> The solution of current WG-drafts is less explicit regarding how many 
> TLVs should/may be flooded.
--> This is implementation and situation specific.
> Would you then elaborate with text in the drafts giving recommendations
>   on how to process different LSA instances referring to same sub-TLVs 
> in the wson specific case.
--> We can add informative text to further explain the process. We'll
bring in some proposed text to Quebec City.
> The processing is not explicitly stated, according to 
> draft-ietf-ccamp-rwa-info-11, there is one ResourcePool per node and
> draft-ietf-ccamp-wson-signal-compatibility-ospf-04 state that this 
> ResourcePool is contained in the "Optical Node Property TLV".
>
> So according to the draft a LSP setup would impact the following sub-TLVs :
>    - "Resource Pool State Sub-TLV" : number of available device is changed
>    - "Block Shared Access Wavelength Availability Sub-TLV " is also 
> updated
>
> Should this be new instances or reuse existing instances? How to merge the information?
--> Think of the Optical Node Property TLV as the master container that
the OSPF working group has allocated to us. They have very limited "code space" and hence want us to use all existing mechanisms rather than asking them for more top level TLVs. Note all of GMPLS uses just one type of LSA.
We would not want to mix large amounts of static information (pool
accessibility) and dynamic information (pool state or shared access
state) in the same LSA instance.  So we could generally do something like the following schematic:
             LSA instance #1{ Node_Prop_TLV[Pools accessibility]}
             LSA instance #2{ Node_Prop_TLV[Resource info]}
             LSA instance #3{ Node_Prop_TLV[Pools accessibility]}
             LSA instance #4{ Node_Prop_TLV[Shared wave state]} A similar process can be used with link information where the top level container was defined way back in early MPLS days.
-->[Pierre]
When reading the preceding part, I end-up to the conclusion that when finally explicited, you finally prone something very similar to draft-peloso-ccamp-wson-ospf-oeo, which I am happy with, as it means, we can then certainly sort out the details. As I see, you are only differing in that you do not dare defining an explicit top-level TLV type for each of your type of LSA instance.
I understand that your motivation there comes from OSPF WG having allocated us a very limited "code space". That is not something I am aware of, would you provide the WG with reference(s) to this statement?
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp