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

[Leeyoung <[e-mail]>]

Hi Andrea,

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

Young

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

Hi Young,

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

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

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

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



With respect to RFC 3630, it states:

  2.4.2.  Link TLV

     The Link TLV describes a single link.

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

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

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

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

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

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


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

Regards,
Andrea

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


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

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

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