Lou Berger | 1 Oct 13:54 2011
Picon

Re: FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt

> Lou and Deborah, do you have any suggestion on this issue?

Young,
	32 bit identifiers are fairly common on routers/IP-based control
systems, and lots of implementations understand how to generate such
identifiers in a dynamic and platform-relevant fashion.  My *personal*
opinion is that unless there's a good reason to not use the norm, i.e.,
32-bit identifiers, they should be used.  Keep in mind that the
identifiers in question are in the control plane (where bits are less
precious).

BTW I see this issue as much less important than ensuring that the
solution can work across graceful restarts.

Lou

On 9/28/2011 5:47 PM, Leeyoung wrote:
> Hi Cyril,
> 
> Thanks for your review and suggestions. It looks like there are two issues pending: Point #2 and #3. 
> We can close the rest of the points you raised with the action specified in-line. Please let me know
otherwise. 
> 
> Thanks.
> 
> Young
> 
> 
> -----Original Message-----
> From: Margaria, Cyril (NSN - DE/Munich) [mailto:cyril.margaria <at> nsn.com] 
(Continue reading)

Lou Berger | 1 Oct 14:34 2011
Picon

Re: R: Thought on where to carry G.709-v3 TSG

Pietro and Sergio,
	See below for responses in-line.

On 9/29/2011 4:48 AM, GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) wrote:
> Hello Lou,
> 
> we try to make further clarification, with a long explanation in line ( sorry for this :-))
> 
> Pietro and Sergio
> 
> ============================================
> Pietro Vittorio Grandi
> Terrestrial Optics Portfolio Evolution
> Alcatel-Lucent Vimercate (Italy)
> Tel: +39 039 686 4930
> Mail: pietro_vittorio.grandi <at> alcatel-lucent.com
> ============================================
> Put your hand on a hot stove for a minute, and it seems like an hour.
> Sit with a pretty girl for an hour, and it seems like a  minute. That's relativity.
> (A. Einstein)
> 
> 
> -----Original Message-----
> From: Lou Berger [mailto:lberger <at> labn.net] 
> Sent: mercoledì 28 settembre 2011 17.37
> To: BELOTTI, SERGIO (SERGIO)
> Cc: CCAMP; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
> Subject: Re: R: [CCAMP] Thought on where to carry G.709-v3 TSG
> 
> 
(Continue reading)

Re: Poll on making G.709 Routing and Signaling draftsWGdocuments


Support both

> -----Original Message-----
> From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf
> Of ext Lou Berger
> Sent: Wednesday, September 28, 2011 6:32 PM
> To: CCAMP
> Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts
> WGdocuments
> 
> This message starts a two week poll on making the documents listed
> below ccamp working group documents.  Please send a mail to the
mailing
> list indicating "yes/support to both" or "no/do not support either".
> Of course, you may also support one but not the other.  (We will
assume
> that you support/object to both if you don't specify.)
> 
> If indicating no, please state your technical reservations with the
> document.
> 
> The documents being polled are:
> http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
> http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09
> 
> The poll ends Wednesday October 12.
> 
> Please also bear in mind that WG adoption does not signify that work
is
(Continue reading)

BELOTTI, SERGIO (SERGIO | 3 Oct 15:10 2011

R: R: Thought on where to carry G.709-v3 TSG


Lou,

We captured essential parts of your mail to avoid proliferation of nesting.

We think that we are converging:
1) we have proposed a solution for routing as all agreed TSG information is needed
2) there are two possible alternatives for signaling as detailed below.

See response details in correspondence of the snip.

BR

Sergio and Pietro

[SNIP]
>>From your mail, I infer that you agree on (a) and (b).  Is this correct?
> [[ALU]] We agree on (a) and (b).

Good.  To me, as I mentioned in my first mail on this thread, this means that G-PID isn't the right place to
carry this information.

On 9/27/2011 9:20 AM, Lou Berger wrote:
    Option 1, G-PID, is really designed to support end-point client
    adaptation, so as an end-point only field it really only supports
    need (a), so I don't think G-PID is the right place to indicate TSG.

Of course this doesn't answer where is the right/best place.

[ALU] It seems that from the first mail, the only survived options for signaling are:
(Continue reading)

Andrea Zanardi | 3 Oct 16:14 2011

Re: 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:
(Continue reading)

Lou Berger | 3 Oct 16:21 2011
Picon

Re: R: R: Thought on where to carry G.709-v3 TSG (point 1)

Sergio,
	In interest in keeping the conversation focused, I've narrowed this
mail to just the first point in your prior mail.

On 10/3/2011 9:10 AM, BELOTTI, SERGIO (SERGIO) wrote:
> 
> Lou,
> 
> We captured essential parts of your mail to avoid proliferation of nesting.
> 
> We think that we are converging:
> 1) we have proposed a solution for routing as all agreed TSG information is needed
> 2) there are two possible alternatives for signaling as detailed below.
> 
> See response details in correspondence of the snip.
> 
> BR
> 
> Sergio and Pietro
> 
> [SNIP]
>> >From your mail, I infer that you agree on (a) and (b).  Is this correct?
>> [[ALU]] We agree on (a) and (b).
> 
> Good.  To me, as I mentioned in my first mail on this thread, this
> means that G-PID isn't the right place to carry this information.
> 
> On 9/27/2011 9:20 AM, Lou Berger wrote:
>     Option 1, G-PID, is really designed to support end-point client
>     adaptation, so as an end-point only field it really only supports
(Continue reading)

Leeyoung | 3 Oct 21:34 2011

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

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: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf Of Andrea Zanardi
Sent: Monday, October 03, 2011 9:14 AM
To: Leeyoung
Cc: ccamp <at> ietf.org
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).

(Continue reading)

Giovanni Martinelli | 3 Oct 23:28 2011
Picon

Re: FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Young,

sorry for late reply

On 9/22/11 9:43 PM, Leeyoung wrote:
<!-- /* Font Definitions */ <at> font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} <at> font-face {font-family:"MS Gothic"; panose-1:2 11 6 9 7 2 5 8 2 4;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} <at> font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} <at> font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} <at> font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} <at> font-face {font-family:"\ <at> MS Gothic"; panose-1:2 11 6 9 7 2 5 8 2 4;} <at> font-face {font-family:"MS PGothic"; panose-1:2 11 6 0 7 2 5 8 2 4;} <at> font-face {font-family:"\ <at> MS PGothic"; panose-1:2 11 6 0 7 2 5 8 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"MS PGothic","sans-serif"; color:black;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"MS Gothic"; color:black;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"MS PGothic","sans-serif"; color:black;} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas; color:black;} span.EmailStyle20 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle21 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} <at> page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ <at> list l0 {mso-list-id:584849078; mso-list-type:hybrid; mso-list-template-ids:1652482728 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;} <at> list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:.25in; text-indent:-.25in; font-family:Symbol;} <at> list l1 {mso-list-id:623804311; mso-list-type:hybrid; mso-list-template-ids:1086496644 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l1:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l2 {mso-list-id:1165123517; mso-list-type:hybrid; mso-list-template-ids:-1442675118 -1995153626 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;} <at> list l2:level1 {mso-level-start-at:300; mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:"Calibri","sans-serif"; mso-fareast-font-family:Calibri;} <at> list l2:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} <at> list l2:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} <at> list l2:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} <at> list l2:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} <at> list l2:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} <at> list l2:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} <at> list l2:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} <at> list l2:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} -->

Hi Giovanni,

 

We have updated the generic OSPF draft (thanks to Fatai).

 

·         Point #1: Regarding your concern on how to build a connectivity matrix in case we need to decompose into several sub-TLV’s, we have added the following subsection in the revision:

 

5.2. Decomposing a Connectivity Matrix into Multiple Matrices

 

   In the highly unlikely event that a Connectivity matrix sub-TLV by

   itself would result in an LSA exceeding the MTU, a single large

   matrix can be decomposed into sub-matrices. Per [GEN-Encode] a

   connectivity matrix just consists of pairs of input and output ports

   that can reach each other and hence such this decomposition would be

   straightforward. Each of these sub-matrices would get a unique matrix

   identifier per [GEN-Encode].

 

Please let us know if you still have a question after reviewing the text.

 

I would guess this text apply to draft-ietf-ccamp-general-constraint-encode since the issue is not specific to OSPF. Is the text here above you use "port" while should be "link set".


 

·         Point  #2: In addition, the revision proposed a new solution that allows multiple sub-TLV’s defined in a top-level TLV. Please see Section 2 in which we added the following text:

 

   This document defines a new top TLV named the Generic Node Attribute

   TLV which carries attributes related to a general network element.

   This Generic Node Attribute TLV contains one or more sub-TLVs

 

And in Section 7.1, we added

 

   This document introduces a new Top Level Node TLV (Generic Node

   Attribute TLV) under the OSPF TE LSA defined in [RFC3630].

 

      Value    TLV Type

 

      TBA      Generic Node Attribute

 

Please let us know if this seems to be a viable solution. If not, please suggest an alternative solution.

 

Btw, I did not comment here although I lean toward this ...  since adding a new top level tlv sounds familiar.

 

·         Point #3: Finally, concerning your question/comment: Since it has to be "generic" we don't know in principle. Does not look a problem for *unconstrained* wson nodes. Don't know if others has different options for wson technology or may be possible other technologies (otn?).

I am not clear what you are asking for here. But if I guess, you are concerned about “generic” technology connectivity matrix. Please note that the reason why we needed the connectivity matrix in WSON was due to the nature of asymmetric nature of ROADM switching technology.

 

although WSON technology in evolving in removing constrains I was trying to figure out numbers for a pretty unconstrained node (and still the result is not negligible).

Again, by comment was not in proposing a new encoding in connectivity matrix but just figure out what sizes we could expect.  Hence my request to get some realistic examples in Appendix A (but I could provide text for that).

Cheers
G


If switches are symmetric, we don’t need to advertise the connectivity matrix. This means any port can be switched to any other ports. Please see the last paragraph of Section 2:

 

   In some specific technologies, e.g., WSON networks, Connectivity

   Matrix sub-TLV may be optional, which depends on the control plane

   implementations. Usually, for example, in WSON networks, Connectivity

   Matrix sub-TLV may appear in the LSAs because WSON switches are

   asymmetric at present. It is assumed that the switches are symmetric

   switching, if there is no Connectivity Matrix sub-TLV in the LSAs. 

 

Please let us know if you still have a question after reviewing the text.

 

Best Regards,

Young

 

From: Giovanni Martinelli [mailto:giomarti <at> cisco.com]
Sent: Tuesday, September 20, 2011 2:36 AM
To: Leeyoung
Cc: Acee Lindem; CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

 

Hi,

On 9/19/11 10:29 PM, Leeyoung wrote:

Hi Giovanni,

 

Your worst case analysis for 16 degree node connectivity matrix is subject to verification,

but even if this is a right number, 300 bytes is well under 1500 byte MTU limit, so we can package it without sub-dividing the TLV.  

 

yes , I was not concerned about mtu but how to build a correct connectivity matrix beyond a simple 2 degree node. If you provide few more numbers there's probably a better feeling of "how many" bytes are (well beyond the mtu but well above the 75 bytes in the example).


We can easily partition the connectivity matrix even if it goes beyond the MTU limit.

Agree that's a good solution  but my comment here is related to how do we partition. Would it worth to add some text about it? We could probably guess (e.g. linkset couple) but just to make sure all readers will have same interpretation.


The last email to the CCAMP was concerning how to do it.

-          We can lift off RFC 5786 restriction to be able to send multiple TLVs under the current Node Attribute TLV.

-          Define a new top level TLV to do that.

 

I know and I was not replaying on last email but trying to providing numbers for the connectivity matrix. 


I don’t think the scale of the connectivity matrix is a big issue.

 

Since it has to be "generic" we don't know in principle. Does not look a problem for *unconstrained* wson nodes. Don't know if others has different options for wson technology or may be possible other technologies (otn?).

Cheers
G

Regards,

Young

 

 

From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf Of Giovanni Martinelli
Sent: Monday, September 19, 2011 3:09 PM
To: Acee Lindem
Cc: CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

 

Hi,

On 9/13/11 11:04 PM, Acee Lindem wrote:

Hi Fatai,

I only have two comments on this document:

 

  1. Reference RFC 5250 rather than RFC 2370 as the former obsoleted the latter.

  2. Possibly this draft should remove the RFC 5786 restriction that only a single OSPF TE LSA containing a top-level TLV is allowed.

      Couldn't the connectivity matrix become quite large?

as far as I've see there is a couple of  examples here http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-05 within appendix A3 and A4.  So asking authors, any other numbers around?

My comment here is that those numbers refers essentially to 2 degree node. I would ask if draft can report some information (formula in the optimal case) that allow to figure out how the connectivity matrix scale.

E.g. Thinking about a 16 degree node my guess reading the appendix A4: the last part of the TLV (from "note : line to line" on) we need to add one more 32 bits to identify the out-range, and we need to replicate this link-set tuple 15 times.  So in total the "line to line" become 5*15*4 = 300 bytes

Is my guess correct?

Cheers
G






 

Thanks,

Acee

 

 

On Sep 12, 2011, at 11:40 PM, Zhangfatai wrote:

 

Hi Acee,

 

Sorry for a mistake, :-)

 

I should say "when I update draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00.txt" instead of "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".

 

 

 

 

 

 

Thanks

Fatai

 

 

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

From: Zhangfatai

Sent: 2011913 11:38

To: 'Acee Lindem'; Greg Bernstein; Leeyoung

Cc: CCAMP

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

 

Hi Acee,

 

I personally agree with your comments on "multi-instance LSA".

 

I will take your suggestions into account when I update "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".

 

 

 

 

Thanks

Fatai

 

 

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

From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf Of Acee Lindem

Sent: 2011913 6:58

To: Greg Bernstein; Leeyoung

Cc: CCAMP

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

 

Hi Young, Greg,

I have the following comments:

 

  1. Specify that the Optical Node Property TLV cardinality and order rules per LSA.

      For example (from RFC 3630):

 

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

 

     However, use the term "advertised" rather than "carried". After all, these are

     Link State Advertisements.

 

  2. The same comment for all the Sub-TLVs. Here is another example from

       RFC 3630:

 

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

 

      The new Sub-TLVs you are defining need this level of specification.

 

  3. I know I told you not to use the term "multi-instance LSA". I still don't like

      the usage of "LSA instance" in the draft. In the base OSPF specification, RFC 2328,

      the term LSA instance is used to denote a particular version of the same LSA - NOT

      an opaque identifier for multiple LSAs of the same type. Refer to section 12.1 in

      RFC 2328.

 

     The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) correctly

      identify the last 24 bits of the LSA ID as the Opaque ID. While RFC 3630 refers

      to this field as the "Instance", I believe this term should be avoided given the

      semantics in the OSPF base specification. Hence, I'd suggest the

      following changes:

 

225,226c225,226

<    the rest and make use of multiple TE LSA instances per source, per

<    [RFC3630] multiple instance capability.

---

  the rest and be advertised with multiple TE LSAs per OSPF router, as

  described in [RFC3630] and [RFC5250].

342,344c342,344

<    the dynamic information sub-TLVs into separate LSAs within an Optical

<    Node Property TLV using multiple TE LSA instances per source, per the

<    reference [RFC3630] multiple instance capability.

---

  the dynamic information sub-TLVs from the static information sub-TLVs

  and advertise them in OSPF TE LSAs, each with the Optical Node

  Property TLV at the top level ([RFC3630 and RFC5250]).

392c392

<    into smaller sub-TLVs that can be sent in separate LSA instances.

---

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

399c399

<    sub-TLVs that can be sent in multiple LSA instances. The

---

  sub-TLVs that can be sent in multiple OSPF TE LSAs. The

473c473

<    into multiple LSA instances each containing a disjoint assembly of

---

  into multiple OSPF TE LSAs each containing a disjoint assembly of

 

    Additionally, I'd add RFC 5250 as at least a informative reference.

 

 

 

  4. Finally, I'd suggest changing the title from "OSPF Enhancement..." to

      "GMPLS OSPF Enhancement..." since you are not really enhancing base

      OSPF itself.  Of course, there are other CCAMP RFCs that do not make

      this distinction.

 

 

Thanks,

Acee

 

 

 

On Sep 9, 2011, at 3:51 PM, Leeyoung wrote:

 

Hi,

 

This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to avoid fragmentation.

 

Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list.

 

Regards,

Young

 

 

 

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

From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf

Of internet-drafts <at> ietf.org

Sent: Thursday, September 08, 2011 5:16 PM

To: i-d-announce <at> ietf.org

Cc: ccamp <at> ietf.org

Subject: [CCAMP] I-D Action:

draft-ietf-ccamp-wson-signal-compatibility-ospf-05.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           : 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-05.txt

   Pages           : 14

   Date            : 2011-09-08

 

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

tibility-ospf-05.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-compat

ibility-ospf-05.txt _______________________________________________

CCAMP mailing list

CCAMP <at> ietf.org

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

_______________________________________________

CCAMP mailing list

CCAMP <at> ietf.org

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

 

 





_______________________________________________

CCAMP mailing list

CCAMP <at> ietf.org

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

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
Autumn Liu | 4 Oct 03:51 2011
Picon

Re: 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib

Hi Masanori et al,

I have a question regarding the TedTable. Should MT-id be added in the entry?

Thanks,
Autumn

> -----Original Message-----
> From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf 
> Of labn - Lou Berger
> Sent: 18 April 2011 20:19
> To: CCAMP
> Subject: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib
> 
> This mail begins a 2nd WG last call on:
> 
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ted-mib-08
> 
> The draft has been updated after the earlier working group primarily 
> based on MIB Dr. review and discussion on the ccamp list.
> 
> This working group last call ends on May 2nd. This LC will be 
> announced on the MPLS, OSPF, and ISIS WG lists.  Please send comments 
> to the CCAMP mailing list.
> 
> Lou (and Deborah)
> _______________________________________________
> CCAMP mailing list
> CCAMP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

Re: R: R: Thought on where to carry G.709-v3 TSG (point 1)

Hello Lou,

we think we have understood your motivations and we think that
we could narrow the choice to just G-PID and Signal type.

We would not consider encoding because in case of TDM it usually
contains the nature of the path  (in this case G.709 ODUk (Digital Path)=12 ) and not the container type and attributes.

We have yet a slight preference for G-PID that is motivated by the fact
the G.709, in case of structuring, explicitly foresees two different payloads named ODTUjk (for G.709v2)
and ODTUk.ts (for G.709v3).
The current GPID value defined in RFC 4328 is currently associated to the ODTUjk only. 
The extension of G-PID would be one to one consistent with G.709.

We have also to notice that we are using the same signal type value both
in routing and in signaling. Surely we would avoid a duplication of data
in the ISCD just to differentiate the TSGs. (for example ODU2-2.5 and ODU2-1.25). This could happen on
interfaces that have auto-payload type on.  

On the other hand the usage of signal type could avoid the need to perform consistency checks between G-PID
value and signal type value. (e.g ODU4 with 2.5 TSG) 

About G-PID we have one question. The definition you wrote in RFC3471 for G-PID is : "An identifier of the
payload carried by an LSP, i.e., an identifier of the client layer of that LSP.  This is used by the nodes at
the endpoints of the LSP, and in some cases by the penultimate hop."

This definition standing, could you elaborate how can be derived from what described that G-PID is "an
end-point only field " ?
Did we miss something in the definition ?

Anyway, apart the slight preference motivated above we do not have a strong position on this issue. As
co-authors of the draft we would like to collect WG opinion included at first our co-authors' opinion and
report the WG decision in the drafts.   

Last but not least, we would like to remind that info draft reports the need for a optional dedicated object
containing the hierarchies that should
be supported by the endpoints. Independently from the solution for TSG, this
object is anyway required. 

BR 
Pietro & Sergio

============================================
Pietro Vittorio Grandi
Terrestrial Optics Portfolio Evolution
Alcatel-Lucent Vimercate (Italy)
Tel: +39 039 686 4930
Mail: pietro_vittorio.grandi <at> alcatel-lucent.com
============================================
Put your hand on a hot stove for a minute, and it seems like an hour.
Sit with a pretty girl for an hour, and it seems like a  minute. That's relativity.
(A. Einstein)

-----Original Message-----
From: Lou Berger [mailto:lberger <at> labn.net] 
Sent: lunedì 3 ottobre 2011 16.22
To: BELOTTI, SERGIO (SERGIO); GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP
Subject: Re: R: R: [CCAMP] Thought on where to carry G.709-v3 TSG (point 1)

Sergio,
	In interest in keeping the conversation focused, I've narrowed this
mail to just the first point in your prior mail.

On 10/3/2011 9:10 AM, BELOTTI, SERGIO (SERGIO) wrote:
> 
> Lou,
> 
> We captured essential parts of your mail to avoid proliferation of nesting.
> 
> We think that we are converging:
> 1) we have proposed a solution for routing as all agreed TSG information is needed
> 2) there are two possible alternatives for signaling as detailed below.
> 
> See response details in correspondence of the snip.
> 
> BR
> 
> Sergio and Pietro
> 
> [SNIP]
>> >From your mail, I infer that you agree on (a) and (b).  Is this correct?
>> [[ALU]] We agree on (a) and (b).
> 
> Good.  To me, as I mentioned in my first mail on this thread, this
> means that G-PID isn't the right place to carry this information.
> 
> On 9/27/2011 9:20 AM, Lou Berger wrote:
>     Option 1, G-PID, is really designed to support end-point client
>     adaptation, so as an end-point only field it really only supports
>     need (a), so I don't think G-PID is the right place to indicate TSG.
> 
> Of course this doesn't answer where is the right/best place.
> 
> [ALU] It seems that from the first mail, the only survived options for signaling are:
> 
> 1: GPID
> 2: Signal type
> 3: Encoding
> 
> Signal type and encoding should be discarded because both imply that
> the current LSPs uses exclusively intermediate links/FAs exporting
> the TSG granularity embedded in the Encoding or in the signal type.
> This is not required.

huh?  WRT encoding, RFC 3471 says:

      LSP Encoding Type: 8 bits

         Indicates the encoding of the LSP being requested.
and
     Switching Type: 8 bits

         Indicates the type of switching that should be performed on a
         particular link.

In other words encoding is an end-to-end attribute that relates to the
LSP.  Switching Type relates to what is happening link by link.  While
not typically done, Switching Type could change hop-by-hop, but encoding
is persistent across an LSP.

So I see personally see no issue or conflict if encoding indicates 1.25G
TSG but the label indicates 2.5G TSG.  Or for that matter mapping a
1.25G TSG signal on an H-LSP that uses 2.5G TSGs.

WRT to signal type, RFC 4328 says:

3.2.1.  Signal Type (ST)

   This field (8 bits) indicates the type of G.709 Elementary Signal
   that comprises the requested LSP.

So, as with Encoding, this relates to the end-to-end LSP and doesn't
indicate the TSG on a particular link.  Again, TSG is covered in the
label.  So again I see no issue or conflict if signal type indicates
1.25G TSG but the label indicates 2.5G TSG.

> 
> The G-PID might be used on the penultimate hop to select the right
> interface, but you say that it cannot be considered because by design
> it should be used only on endpoints. About this fact RFC 3471 says
> instead that exceptions are possible.

Sure.  I wrote that sentence :-)  It's also why I said:
>> On 9/27/2011 9:20 AM, Lou Berger wrote:
>>     Option 1, G-PID, is really designed to support end-point client
>>     adaptation, so as an end-point only field it really only supports
>>     need (a), so I don't think G-PID is the right place to indicate
>>     TSG.

> 
> If our interpretation is correct, the only real possibilities for
> signaling are either allowing an exception on G-PID usage or
> introduce a dedicated object.

Yes, I think we have a disagreement on interpretation (as well as a
really good discussion!)  IMO encoding and signal type are both better
suited to the requirements than G-PID given the above.  Furthermore, per
my previous mail, I think Signal type is better then Encoding.

Has your opinion changed/been impacted by the above interpretation of
signal type and encoding?  If not, can you elaborate?

[major snip]

Much thanks,
Lou
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp


Gmane