Subject: [CCAMP] Comment regarding draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02

From: Jonathan Harrison <[email-masked]>
Date: Thu, 20 Oct 2011 07:23:20 +0000

Hi authors,

I don't know if you've been following the thread below, but the discussion appears to have some relevance to draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.

The discussion below is about the Link TLV defined in RFC 3630.  The problem is that RFC 3630 is not clear whether information about a single link can be spread across more than one Link TLV.  Significantly, RFC 3630 does not provide any rules as to how an OSPF implementation should generate multiple TE link TLVs for the same link.  Similarly, it does not indicate how an OSPF implementation should handle multiple received Link TLVs for the same link.  For example, if an OSPF implementation receives two Link TLVs, both of which have the same link type and link ID sub-TLVs, but different values for the Unreserved bandwidth sub-TLV, what should it do?

In summary, the behavior of an OSPF implementation receiving multiple Link TLVs for the same link is not well defined.  I suspect that most OSPF implementations assume that there is at most one Link TLV for each link.  Hence the suggestion of section 5 of draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02 for using multiple Link TLVs is likely to lead to interoperability problems.

The solution might be to define a new TLV type (Generic Link TLV?) for distributing the Port Label Restrictions, Available Labels and Available Shared Backup Label sub-TLVs in OSPF, along with a clear description of its use.  In particular, we need the following.

-       A clear statement that multiple TLVs are allowed for the same link.

-       Rules specifying how sub-TLVs can be distributed across the multiple TLVs (e.g. there must be at most one Available Labels sub-TLV across all TLVs for the same link).

-       Rules specifying how multiple TLVs should be interpreted.  (This should be simple if the rules for building the TLVs are well defined.)

Let me know what you think.

Thanks,
Jon

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

Hi Andrea,

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

Best Regards,

Young

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

From: Andrea Zanardi [mailto:[email-masked]]

Sent: Sunday, October 09, 2011 11:53 AM

To: Leeyoung

Cc: [email-masked]

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

Hi Young,

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

Anyway, my original comments were related to:

a.  the possibility of sending a TE Link LSA update (same ID, new sequence number)

     without some sub-TLVs if their value is unchanged, as I understood when you wrote

     "All other sub-TLV are optional and may occur at most once

      (when there are enough changes from the previous period that deserve an update)

      and _need not_ be included in the TE Link TLV when there is no need for updating."

    (but correct me if I misunderstood your sentence)

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

    Note that also creating a new LSA (new ID) with only the changed sub-TLVs doesn't

    work, as you will have two different values for the same sub-TLV

    (as the old LSA and the new LSA are both present in the TE DB)

    I read the "may occur at least once" in RFC 3630 as:

    "it may be omitted if it does not apply to the link";

    but if it applies, it must be present in all updates

    (unless you want to clear its value)

b. the fact that RFC 3630 allows the possibility of splitting the

    set of sub-TLVs of a TE Link in different LSAs (different IDs)

    [the implementation I checked doesn't support this scenario]

    This could be a matter of interpretation; but as it's not explicitly

    stated, the simplest interpretation is usually the one accepted.

I perfectly agree that splitting a set of attributes related to

a 'logical' instance in two or more different LSAs is a viable solution

(as far as you keep the subsets disjoint and the support for this

solution is explicitly requested; and this is somehow stated

in the draft in Chap. 3.2.1).

Even if, in my opinion, would be preferable to have some rule

defined; especially if the reason for the splitting is the dynamics

of the updates and not just the size.

Sorry if there has been any misunderstanding.

Regards

Andrea

On 10/08/2011 12:46 AM, Leeyoung wrote:

> Hi Andrea,

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

> Young

> -----Original Message-----

> From: Andrea Zanardi [mailto:[email-masked]]

> Sent: Tuesday, October 04, 2011 9:10 AM

> To: Leeyoung

> Cc: [email-masked]

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

> Hi Young,

> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Andrea Zanardi

>> Sent: Monday, October 03, 2011 9:14 AM

>> To: Leeyoung

>> Cc: [email-masked]

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

>> Hi Young,

>> I was following the discussion and I have a doubt about

>> your example related to the TE Link TLV.

>> It's true that the attributes sub-TLV are not mandatory per RFC 3630,

>> but I don't think that means that they can be not included in an LSA update

>> if unchanged (implying that the previous value persists).

>> As for my understanding of how OSPF-TE works, the managed TE DB entity is the LSA.

>> When an LSA update is processed, the previous version is deleted from the TE DB

>> and it is replaced by the new one: link attributes related to missing sub-TLV are

>> deleted, so they must be present even if unchanged.

>> In theory, the set of link attributes could be statically divided

>> in two different LSAs instances (updated independently),

>> but I don't think current implementations handle this scenario

>> (also because, in my opinion, it's not suggested by RFC 3630 and

>>     it gives no rule on how to divide them).

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

>> Regards,

>> Andrea

>> On 09/30/2011 11:16 PM, Leeyoung wrote:

>>> Hi Pierre,

>>> I got your point. Let me ask you this question. In the current GMPLS OSPF TE Link TLV are defined under Opaque TE LSA with the following attributes:

>>> - TE Metric

>>> - max B/W

>>> - max reservable b/w

>>> - unreserved b/w

>>> - Admin Group

>>> - Link Protection Type

>>> - SRLG

>>> - ISCD

>>> - etc.

>>> And these are a mixture of static and dynamic information and yet they are assembled together as one TE Link TLV. For instance the ISCD is quite similar to Resource Block Info in that it does not change often unless there are new elements added in the node or configuration changes and yet it is packaged together with other dynamic information.

>>> Why?

>>> There are many ways to keep static/unchanged information from being flooded. Only the Link Type and Link ID which are mandatory in the TE Link TLV per RFC3630. All other sub-TLV are optional and may occur at most once (when there are enough changes from the previous period that deserve an update) and need not be included in the TE Link TLV when there is no need for updating.

>>> I really don't see the need for a separate top-level TLV and/or a separate LSA for the Resource Block information.

>>> Regards,

>>> Young

>>> -----Original Message-----

>>> From: PELOSO, PIERRE (PIERRE) [mailto:[email-masked]]

>>> Sent: Friday, September 30, 2011 9:39 AM

>>> To: Leeyoung; [email-masked]

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

>>> Hi Young,

>>> I understand the content of your answer, but I'm not satisfied with it.

>>> My concern deals with providing a unique reading/interpretation of the OSPF-TE extensions.

>>> We would like to make sure that any implementation complying to the drafts would provide the same LSAs when applied to the same network.

>>> With this perspective in mind, we wish to get drafts with sufficient documentation to make sure the LSA design process to be depicted, by design rules.

>>> Hence the content of your answer leaving me the "opportunity to do as I wish", is not pleasing me, I would rather have strict rules, and discussions with the WG on the design of those.

>>> That is why a first design rule, we could agree on is: to gather the Resource Block Information TLVs inside a dedicated LSA, possibly with a dedicated top-level TLV (which in my mind allows to enforce this design rule).

>>> Regards,

>>> - Pierre

>>> -----Message d'origine-----

>>> De : Leeyoung [mailto:[email-masked]]

>>> Envoyé : mercredi 28 septembre 2011 00:06

>>> À : PELOSO, PIERRE (PIERRE); [email-masked]

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

>>> Hi Pierre,

>>> Please see-inline for my reply to your first point.

>>> Regards,

>>> Young

>>> -----Original Message-----

>>> From: PELOSO, PIERRE (PIERRE) [mailto:[email-masked]]

>>> Sent: Tuesday, September 27, 2011 3:28 AM

>>> To: Leeyoung; [email-masked]

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

>>> Hi Young, and CCAMPers,

>>> I was off the mailing lists for the last two weeks and being back I notice a lot of exchanges, which I'm very glad of.

>>> I've also noticed many drafts have been updated.

>>> Concerning this specific draft-ietf-ccamp-wson-signal-compatibility-ospf-06, I wanted to comment section 3.

>>> Back in Quebec, I expressed my point of view (shared with Cyril, Julien and Giovanni) that current drafts were lacking guidance regarding the way to design LSAs that were to depict an WSON node with OEOs.

>>> This section 3 provides additional material to help designing the LSA.

>>> I would like to know whether authors are willing to pursue further in this direction, which is to my mind a real corner stone, that would help everyone agree on a solution.

>>> A first point could concern the Resource Block Information (reminder:<ResourceBlockInfo>    ::= ([<ResourceSet>]<InputConstraints>    <ProcessingCapabilities>    <OutputConstraints>):

>>>         We all agree that these information are static, that we should not replicate this TLV whatever the number not the layout of OEO boards of a given type.

>>> Then, we could dedicate a specific independant flooding entity. This would be defined once for all, and that would not leave room to different interpretations.

>>> What about this first point?

>>> YOUNG>>    If I understand you correctly, what you are saying is since the Resource Block Info sub-TLV is very static in nature, advertisement of this sub-TLV should be treated differently from the rest of static-TLVs (which may change over time). Is this what you are saying?

>>> If my interpretation of your comment is correct,

>>> - The current mechanism allows what you want: Please see the first paragraph in Section 3.2

>>>       "In the highly unlikely event that a WSON sub-TLV by itself would

>>>       result in an LSA exceeding the MTU, all five WSON specific sub-TLVs

>>>       in this document provide mechanisms that allow them to be subdivided

>>>       into smaller sub-TLVs that can be sent in separate OSPF TE LSAs."

>>> According to this clause, you can separate the Resource Block Info Sub-TLV as the sole entry defined in the Optical Node property TLV in a separate TE LSA from the rest if you will. Nothing prevents this particular way of packaging. (Isn't this what you meant "a specific independent flooding entity"?)

>>> - Please let me know if this explanation satisfies you. Thanks --- Young

>>> Regards,

>>> Pierre

>>> -----Message d'origine-----

>>> De : [email-masked] [mailto:[email-masked]] De la part de Leeyoung Envoyé : jeudi 15 septembre 2011 21:59 À : [email-masked] Objet : Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

>>> Hi all,

>>> After 05 version publication, Acee provided a number of valuable comments and suggestions. This revision (06) reflects those changes. Please note the following updates:

>>> - Change the title of the draft to "GMPLS OSPF Enhancement..." from "OSPF Enhancement..." to make sure the changes apply to the GMPLS OSPF rather than the base OSPF.

>>> - Add specific OSPF procedures on how sub-TLVs are packaged per [RFC3630] and editorial change including avoiding "multiple instances of TE LSA" to "multiple TE LSAs".

>>> Your comments are always appreciated. Thanks.

>>> Best Regards.

>>> Young

>>> -----Original Message-----

>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]

>>> Sent: Thursday, September 15, 2011 2:48 PM

>>> To: [email-masked]

>>> Cc: [email-masked]

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

>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

>>>   Title           : GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks

>>>   Author(s)       : Young Lee

>>>                              Greg M. Bernstein

>>>   Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

>>>   Pages           : 14

>>>   Date            : 2011-09-15

>>>       This document provides GMPLS OSPF routing enhancements to support

>>>       signal compatibility constraints associated with WSON network

>>>       elements. These routing enhancements are required in common optical

>>>       or hybrid electro-optical networks where not all of the optical

>>>       signals in the network are compatible with all network elements

>>>       participating in the network.

>>>       This compatibility constraint model is applicable to common optical

>>>       or hybrid electro optical systems such as OEO switches, regenerators,

>>>       and wavelength converters since such systems can be limited to

>>>       processing only certain types of WSON signals.

--

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

Andrea Zanardi

CREATE-NET

Engineering & Fast Prototyping (ENGINE) Area

Senior Engineer

Via alla Cascata 56/D - 38123 Povo Trento (Italy)

e-mail: [email-masked]

Tel: (+39) 0461 408400 - interno/extension 1407

Mobile: (+39) 340 0011837

Fax: (+39) 0461 421157

Skype: zanardi_andrea

www.create-net.org

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

The information transmitted is intended only for the person or entity to

which it is addressed and may contain confidential and/or privileged

material. Any review, retransmission, dissemination or other use of, or

taking of any action in reliance upon, this information by persons or

entities other than the intended recipient is prohibited according to the

Italian Law 196/2003 of the Legislature. If you received this in error,

please contact the sender and delete the material from any computer.

Le informazioni contenute in questo messaggio di posta elettronica e nei

file allegati sono da considerarsi strettamente riservate. Il loro utilizzo

e' consentito esclusivamente al destinatario del messaggio, per le finalita'

indicate nel messaggio stesso. Qualora riceveste questo messaggio senza

esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via

e-mail e di procedere alla cancellazione del messaggio stesso dal Vostro

sistema. Trattenere il messaggio stesso, divulgarlo anche in parte,

distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalita'

diverse, costituisce comportamento contrario ai principi dettati dal D. Lgs.

196/2003.

_______________________________________________

CCAMP mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ccamp

---

From: Zhangfatai <[email-masked]>
Date: Thu, 20 Oct 2011 12:43:04 +0000

Hi Jonathan,

I agree with you that RFC 3630 does not state explicitly how an OSPF implementation should generate multiple TE link TLVs for the same link.

I only saw a sentence to describe the relationship between Link TLV and LSA:  “Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology.”

However, obviously, RFC 3630 does not provent to advertise a TE link information  by multiple LSAs (including only one link TLV respectively).

This draft [GEN-OSPF] describes the extensions to RFC 3630, so it can define these procedures.

I agree with you that we should have clear descriptions on your three points. For the first point, I think this draft has stated this explicitly in Section 4 and 5.1. For the other two points, we need some refinements to address them.

We will add some text to address them in the next version.

==================================================================================

Thanks

Fatai

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Harrison
Sent: 2011年10月20日 15:23
To: [email-masked]
Cc: [email-masked]
Subject: [CCAMP] Comment regarding draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02

Hi authors,

I don’t know if you’ve been following the thread below, but the discussion appears to have some relevance to draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.

Thanks,
Jon

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

Hi Andrea,

Best Regards,

Young

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

To: Leeyoung

Cc: [email-masked]

Hi Young,

Regards

Andrea

--

Andrea Zanardi

CREATE-NET

Senior Engineer

Fax: (+39) 0461 421157

Skype: zanardi_andrea

www.create-net.org

196/2003.

CCAMP mailing list

[email-masked]

---

From: Acee Lindem <[email-masked]>
Date: Thu, 20 Oct 2011 09:52:57 -0400

Hi Fatai,

On Oct 20, 2011, at 8:43 AM, Zhangfatai wrote:

Hi Jonathan,

It doesn't explicitly prevent it but it does so implicitly. If you advertise multiple OSPF TE LSAs with a top-level Link TLV for the same link, there is no way to correlate them since RFC 3630 does specify that the Link ID sub-TLV may only occur at most once.

While I admit there is some ambiguity here, I concur with Jonathan that this would result in incompatibility problems with existing implementations. Do we really think have more information for a single link than will normally fit in an LSA that be advertised over a standard ethernet link (MTU 1500 bytes) without IP fragmentation? If this is a rare case, I'd say that it is ok for the LSA to become large, i.e., require IP fragmentation for advertisement. If the we expect the constraint information to normally require fragmentation, I'd recommend a new top-level TLV, the Link-Constraint TLV.

Thanks, Acee

Thanks

Fatai

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jonathan Harrison
Sent: 2011年10月20日 15:23
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [CCAMP] Comment regarding draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02

Hi authors,

Thanks,
Jon

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: 10 October 2011 17:36
To: Andrea Zanardi
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Andrea,

Best Regards,
Young

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

Hi Young,

Regards
Andrea

On 10/08/2011 12:46 AM, Leeyoung wrote:
> Cc: [email-masked]<mailto:[email-masked]>
>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Andrea Zanardi
>> Cc: [email-masked]<mailto:[email-masked]>
>>> To: Leeyoung; [email-masked]<mailto:[email-masked]>
>>> À : PELOSO, PIERRE (PIERRE); [email-masked]<mailto:[email-masked]>
>>> To: Leeyoung; [email-masked]<mailto:[email-masked]>
>>> De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Leeyoung Envoyé : jeudi 15 septembre 2011 21:59 À : [email-masked]<mailto:[email-masked]> Objet : Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>>>
>>> Hi all,
>>>
>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
>>> To: [email-masked]<mailto:[email-masked]>
>>> Cc: [email-masked]<mailto:[email-masked]>

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

_______________________________________________
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: Zhangfatai <[email-masked]>
Date: Mon, 24 Oct 2011 03:03:18 +0000

Hi Acee,

You said as follows, please see inline.

===============================================================

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.

[Fatai] I think the restriction for this paragraph should be in the scope of one Link TLV or one LSA. If a TE link is advertised by multiple LSAs (with multiple Link TLVs), the Link ID and Link type MUST be advertised respectively, and then we can use Link ID and Link Type to correlate them for the same TE link.

[Fatai] I think for the typical cases, one LSA (or one Link TLV) may be sufficient for a TE link, but some people like to give some rare or extreme examples to justify their thought. Compared with a new top-level TLV, I would say I would like to re-use the existing top-level Link TLV because this follows the “G” of GMPLS.

Thanks

Fatai

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]]
Sent: 2011年10月20日 21:53
To: Zhangfatai
Cc: Jonathan Harrison; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment regarding draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02

Hi Fatai,

Hi Jonathan,

Thanks, Acee

Thanks

Fatai

Sent: 2011年10月20日 15:23

Hi authors,

Thanks,

Jon

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

To: Andrea Zanardi

Hi Andrea,

Best Regards,

Young

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

To: Leeyoung

Hi Young,

Regards

Andrea

--

Andrea Zanardi

CREATE-NET

Senior Engineer

Fax: (+39) 0461 421157

Skype: zanardi_andrea

196/2003.

CCAMP mailing list

CCAMP mailing list

---

From: Acee Lindem <[email-masked]>
Date: Mon, 24 Oct 2011 11:00:43 -0400

Hi Fatai,

On Oct 23, 2011, at 11:03 PM, Zhangfatai wrote:

Hi Acee,

RFC 3630 makes no provision for multiple OSPF TE LSAs with a top-level Link TLV for a given link. It could be made to work as you suggest but it certainly isn't specified.

I'll let Lou and other comment on what is more consistent with GMPLS. However, I share the concern that this extension will be incompatible with existing implementations.

Thanks,
Acees

Thanks

Fatai

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]]
Sent: 2011年10月20日 21:53
To: Zhangfatai
Cc: Jonathan Harrison; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] Comment regarding draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02

Hi Fatai,

Hi Jonathan,

Thanks, Acee

Thanks

Fatai

Hi authors,

Thanks,
Jon

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: 10 October 2011 17:36
To: Andrea Zanardi
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Andrea,

Best Regards,
Young

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

Hi Young,

Regards
Andrea

---

From: Lou Berger <[email-masked]>
Date: Tue, 25 Oct 2011 17:45:30 -0400

Acee,

In short I agree with you 100%.  See below for more detailed  responses
in-line.

On 10/24/2011 11:00 AM, Acee Lindem wrote:
> It doesn't explicitly prevent it but it does so implicitly. If you
> advertise multiple OSPF TE LSAs with a top-level Link TLV for the
> same link, there is no way to correlate them since RFC 3630 does
> specify that the Link ID sub-TLV may only occur at most once.
> 
> 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.
> 
> [Fatai] I think the restriction for this paragraph should be in the
> scope of one Link TLV or one LSA. If a TE link is advertised by
> multiple LSAs (with multiple Link TLVs), the Link ID and Link type
> MUST be advertised respectively, and then we can use Link ID and Link
> Type to correlate them for the same TE link.
> 
> RFC 3630 makes no provision for multiple OSPF TE LSAs with a
> top-level Link TLV for a given link. It could be made to work as you
> suggest but it certainly isn't specified.
> 
> While I admit there is some ambiguity here, I concur with Jonathan
> that this would result in incompatibility problems with existing
> implementations. 

I completely agree.  I'd need to check code to see if the implementation
I have easy access to will handle this case on receive, but I can't
think of case where such usage would be generated.

> Do we really think have more information for a
> single link than will normally fit in an LSA that be advertised over
> a standard ethernet link (MTU 1500 bytes) without IP fragmentation?
> If this is a rare case, I'd say that it is ok for the LSA to become
> large, i.e., require IP fragmentation for advertisement. If the we
> expect the constraint information to normally require fragmentation,
> I'd recommend a new top-level TLV, the Link-Constraint TLV.

Again, agree with both comments/recommendations.  Perhaps call it the
Link-Fragment TLV, or Partial Link TLV...

> 
> [Fatai] I think for the typical cases, one LSA (or one Link TLV) may
> be sufficient for a TE link, but some people like to give some rare
> or extreme examples to justify their thought. Compared with a new
> top-level TLV, I would say I would like to re-use the existing
> top-level Link TLV because this follows the “G” of GMPLS.
> 
> I'll let Lou and other comment on what is more consistent with GMPLS.

Well this is something for the WG to discuss.  My personal (not chair)
perspective seems aligned with yours (Acee's).

> However, I share the concern that this extension will be incompatible
> with existing implementations.

Could not agree more.  My impression (as chair) is that much of the WSON
related discussion has to do with the degree that the current WG drafts
are open to different interpretations (and possible incompatible
implementations).  I think the more specific/detailed we can make them,
the faster the open discussions will be resolved.

Lou

---

From: Zhangfatai <[email-masked]>
Date: Wed, 26 Oct 2011 09:35:08 +0000

Hi Lou, Acee and all,

I am fine to have a new top level Link TLV to include the generic link information if the WG like that.

To avoid this work back and forth, please share your concerns before we update this draft.

Thanks
 
Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: 2011年10月26日 5:46
To: Acee Lindem
Cc: Zhangfatai; Jonathan Harrison; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment regarding draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02

Acee,

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 26 Oct 2011 08:20:35 -0400

Fatai,

> To avoid this work back and forth, please share your concerns before we update this draft.

I'm not sure what additional input you're looking for.  My only
additional comment is:
> I think the more specific/detailed we can make them,

In other words, I believe that some more conformance language and
specific requirements on formatting and TLV construction/parsing would
be beneficial.

Lou

---

From: Zhangfatai <[email-masked]>
Date: Thu, 27 Oct 2011 01:19:13 +0000

Hi Lou,

I got your points.

My last sentence should go to the WG, I just wanted to see whether there are other opinions on the new top level link TLV. 

Thanks
 
Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: 2011年10月26日 20:21
To: Zhangfatai
Cc: Acee Lindem; Jonathan Harrison; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment regarding draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02

Fatai,

Lou

---

From: Zhangfatai <[email-masked]>
Date: Thu, 27 Oct 2011 02:35:27 +0000

Hi Acee, Jonathan and Lou,

When I was going to update the draft, I found that it cannot separate the dynamic and static link information by introducing a new top Level Link TLVs, i.e., if we still need to separate the dynamic and static link information, we may still need the similar procedures defined in Section 4 and 5.1 of this draft, please have a look at these sections.

When I looked at what Acee said below again, I think people including me may mix the node information and link information at some extent. Actually, the connectivity matrix is a kind of node information and it is carried in a new top Node TLV. 

For the link information, there is not too much information(Port Label Restrictions, Available Labels, Shared Backup Labels), so a single Link LSA should be OK. Why we wanted to use multiple LSAs to advertise the same link information? The original reason is that we want to separate the dynamic and static link information to reduce the routing scalability issue.

However, I think the dynamic of label availability is similar to the bandwidth of TDM or PSC and there are no protocol procedures so far to define how to separate the dynamic and static link information.

So, to make things simple, I think we can just use one single LSA to include all the information of one Link.

What do you think about this?

=====================================================================================================================================

Thanks
 
Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zhangfatai
Sent: 2011年10月27日 9:19
To: Lou Berger
Cc: Jonathan Harrison; [email-masked]
Subject: Re: [CCAMP] Comment regarding draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02

Hi Lou,

I got your points.

Thanks
 
Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: 2011年10月26日 20:21
To: Zhangfatai
Cc: Acee Lindem; Jonathan Harrison; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Comment regarding draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02

Fatai,

Lou

---

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

Hi Fatai,

> So, to make things simple, I think we can just use one single LSA to include all the information of one Link.

Yes - the only advantage I could see to the separate top-level TLV and, hence, the possibility of separate LSAs is that you could separate the constraints from the other link information.

Thanks,
Acee