Subject: [CCAMP] the merged OTN signaling draft uploaded

From: Fatai Zhang <[email-masked]>
Date: Fri, 08 Jul 2011 11:23:11 +0800

Hi all,

The merged OTN signaling draft has been submitted after quite long hard
time.

We would like to request all of you to have a careful review on this merged
draft and then share your comments or suggestions freely, so I am not going
to summarize what we have achieved, J.

Thanks to all the people including the authors, contributors and active
experts.

http://www.ietf.org/id/draft-zhang-ccamp-gmpls-evolving-g709-08.txt

Thanks
 
Fatai

---

From: Steve Balls <[email-masked]>
Date: Mon, 18 Jul 2011 14:40:06 +0000

Hi Fatai,

We have one question on the contents of the Bit_Rate field within the traffic parameters.  The draft is not explicit whether this value should be in bits per second or bytes per second.  From the name of the field we assume the intention is for the value to be in bits per second.  However, the Max LSP Bandwidth value flooded in routing (against which a routing calculation would compare) is flooded in bytes per second.

We would like to see the two values aligned and suggest the Bit_Rate field is explicitly defined to be in bytes per second.  Do you agree?

Thanks,

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: 08 July 2011 04:23
To: 'CCAMP'
Subject: [CCAMP] the merged OTN signaling draft uploaded

Hi all,

The merged OTN signaling draft has been submitted after quite long hard time.

We would like to request all of you to have a careful review on this merged draft and then share your comments or suggestions freely, so I am not going to summarize what we have achieved, :).

Thanks to all the people including the authors, contributors and active experts.

Thanks

Fatai

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 19 Jul 2011 13:50:18 +0800

Hi Steve,

Thanks for your suggestion.

Agree with you and we will add some text to refine it in the next version.

Thanks
 
Fatai

From: Steve Balls [mailto:[email-masked]] 
Sent: 2011年7月18日 22:40
To: Fatai Zhang; 'CCAMP'
Subject: RE: [CCAMP] the merged OTN signaling draft uploaded

Hi Fatai,

We have one question on the contents of the Bit_Rate field within the
traffic parameters.  The draft is not explicit whether this value should be
in bits per second or bytes per second.  From the name of the field we
assume the intention is for the value to be in bits per second.  However,
the Max LSP Bandwidth value flooded in routing (against which a routing
calculation would compare) is flooded in bytes per second.

We would like to see the two values aligned and suggest the Bit_Rate field
is explicitly defined to be in bytes per second.  Do you agree?

Thanks,

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fatai Zhang
Sent: 08 July 2011 04:23
To: 'CCAMP'
Subject: [CCAMP] the merged OTN signaling draft uploaded

Hi all,

 

Thanks
 
Fatai

---

From: John E Drake <[email-masked]>
Date: Thu, 21 Jul 2011 10:58:47 -0700

Fatai,

I have some question on this draft, some of which I have asked you before:

1)      Why isn't Signal Type, defined in the OTN routing draft, used instead of the four bit ODUj field?

2)      Why is tributary slot size included?  Will it not change hop-by-hop, as the tributary slot size of each hop's underlying UDUk/OTUk link can take on one of two different values?  I.e., I don't think having an single end-to-end tributary slot size makes sense.

3)      Why is the OD(T)Uk  field needed?  As with 2), above, the value of k for the underlying ODUk/OTUk link (or hierarchical LSP) will change hop-by-hop.

Thanks,

John

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Thursday, July 07, 2011 8:23 PM
To: 'CCAMP'
Subject: [CCAMP] the merged OTN signaling draft uploaded

Hi all,

Thanks

Fatai

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 22 Jul 2011 12:50:21 +0800

Hi John,

Thanks for your comments. Please see in-line below.

 

Thanks
 
Fatai

From: John E Drake [mailto:[email-masked]] 
Sent: 2011年7月22日 1:59
To: Fatai Zhang; 'CCAMP'
Subject: RE: [CCAMP] the merged OTN signaling draft uploaded

Fatai,

1)      Why isn’t Signal Type, defined in the OTN routing draft, used
instead of the four bit ODUj field?

[Fatai] Agree. The label format is quite flexible to extend this field to 8
bits.

2)      Why is tributary slot size included?  Will it not change hop-by-hop,
as the tributary slot size of each hop’s underlying UDUk/OTUk link can take
on one of two different values?  I.e., I don’t think having an single
end-to-end tributary slot size makes sense. 

[Fatai] Do you mean label information should be end-to-end? Actually, label
information is link/span scope, it can be changed hop by hop, so, tributary
slot type (1.25G or 2.5G) can be changed hop by hop, there is no problem.
In addition, label allocation depends on the tributary slot size (1.25G or
2.5G).

3)      Why is the OD(T)Uk  field needed?  As with 2), above, the value of k
for the underlying ODUk/OTUk link (or hierarchical LSP) will change
hop-by-hop.

[Fatai] As explained above, label information is link/span scope, so there
is no problem when ODU/OTUk link (or H-LSP) changes hop by hop. 

Thanks,

John

Sent from my iPhone

Hi all,

 

Thanks
 
Fatai

---

From: John E Drake <[email-masked]>
Date: Fri, 22 Jul 2011 04:59:30 -0700

Fatai,

Usually fields that change hop-by-hop are explicitly identified.

If it is the case that tributary slot size and ODUk/OTUk link capacity are intended to change hop-by-hop, then these fields are completely redundant and should be removed.

The underlying TE link is explicitly identified in the signaling message and hence its tributary slot size and its link capacity are known.  Further, including these fields introduces additional error cases caused by a mismatch between the values in these fields and the known values of the underlying TE link.

Thanks,

John

Sent from my iPhone

From: Fatai Zhang [mailto:[email-masked]]
Sent: Thursday, July 21, 2011 9:50 PM
To: John E Drake; 'CCAMP'
Subject: RE: [CCAMP] the merged OTN signaling draft uploaded

Hi John,

Thanks

Fatai

Fatai,

1)      Why isn’t Signal Type, defined in the OTN routing draft, used instead of the four bit ODUj field?
[Fatai] Agree. The label format is quite flexible to extend this field to 8 bits.

2)      Why is tributary slot size included?  Will it not change hop-by-hop, as the tributary slot size of each hop’s underlying UDUk/OTUk link can take on one of two different values?  I.e., I don’t think having an single end-to-end tributary slot size makes sense.
[Fatai] Do you mean label information should be end-to-end? Actually, label information is link/span scope, it can be changed hop by hop, so, tributary slot type (1.25G or 2.5G) can be changed hop by hop, there is no problem.  In addition, label allocation depends on the tributary slot size (1.25G or 2.5G).

3)      Why is the OD(T)Uk  field needed?  As with 2), above, the value of k for the underlying ODUk/OTUk link (or hierarchical LSP) will change hop-by-hop.
[Fatai] As explained above, label information is link/span scope, so there is no problem when ODU/OTUk link (or H-LSP) changes hop by hop.

Thanks,

John

Sent from my iPhone

Hi all,

Thanks

Fatai

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 22 Jul 2011 14:18:30 +0200

John,

TS granularity is a paramenter discussed a lot when we wrote reaquireemtns and needed information for signalling and routing. This is why is explicitly present as needed information in the info draft .
Encoding draft is the mirror of what discussed before .  Anyway TS granularity is an essential parameter to be configured in the physical interfaces and permit  end nodes of an FA to understand which TS  to be used. Moreover , there is the auto-negotiation and his CP relationship that is one of the open point that again could require as mandatory to have TS gran. As signalling parameter (and in certain cases also for routing) .

Thanks

sergio

________________________________
Da: [email-masked] [mailto:[email-masked]] Per conto di John E Drake
Inviato: venerdì 22 luglio 2011 14.00
A: Fatai Zhang; 'CCAMP'
Oggetto: Re: [CCAMP] the merged OTN signaling draft uploaded

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi all,

Thanks

Fatai

---

From: John E Drake <[email-masked]>
Date: Fri, 22 Jul 2011 05:44:48 -0700

Comments inline.

Sent from my iPhone

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, July 22, 2011 5:19 AM
To: John E Drake
Cc: Fatai Zhang; 'CCAMP'
Subject: R: [CCAMP] the merged OTN signaling draft uploaded

John,

JD:   Just because at one time  it was thought to be needed does not mean that upon reflection it is still needed, and for the record, ever since January 2010 I have been asking why it is needed in signaling

Encoding draft is the mirror of what discussed before .  Anyway TS granularity is an essential parameter to be configured in the physical interfaces and permit  end nodes of an FA to understand which TS  to be used.

JD:  How is it possible to specify tributary slot size for a hierarchical LSP?  A hierarchical LSP inherits the tributary slot size(s) of the underlying ODUk/OTUk links over which it is routed, and as Fatai indicates  the tributary slot size can change hop-by-hop

Moreover , there is the auto-negotiation and his CP relationship that is one of the open point that again could require as mandatory to have TS gran. As signalling parameter (and in certain cases also for routing) .

JD:  I am sorry, but I am having trouble understanding this sentence

Thanks

sergio

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi all,

Thanks

Fatai

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 22 Jul 2011 14:51:09 +0200

In line

SERGIO BELOTTI

ALCATEL-LUCENT
Terrestrial System Architect
Optics Portfolio Evolution

via Trento 30 , Vimercate(MI)  Italy
T: +39 0396863033
[email-masked]

________________________________
Da: John E Drake [mailto:[email-masked]]
Inviato: venerdì 22 luglio 2011 14.45
A: BELOTTI, SERGIO (SERGIO)
Cc: Fatai Zhang; 'CCAMP'
Oggetto: RE: [CCAMP] the merged OTN signaling draft uploaded

Comments inline.

Sent from my iPhone

John,

SB> This why you probably did not understand the content above

Thanks

sergio

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi all,

Thanks

Fatai

---

From: John E Drake <[email-masked]>
Date: Fri, 22 Jul 2011 06:01:01 -0700

Sergio,

You did not actually address any of my three points;  your one comment is an example of the usage of the word ‘smug’.

Thanks,

John

Sent from my iPhone

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, July 22, 2011 5:51 AM
To: John E Drake
Cc: Fatai Zhang; 'CCAMP'
Subject: R: [CCAMP] the merged OTN signaling draft uploaded

In line

SERGIO BELOTTI

ALCATEL-LUCENT

Comments inline.

Sent from my iPhone

John,

Thanks

sergio

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi all,

Thanks

Fatai

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 22 Jul 2011 15:52:18 +0200

John,

For point 1)
My sentence was not a justification of correctness but why TS is present in the encoding , since encoding , as framework and info draft has been created, lead requirements and information needed .
Moreover, the fact you did not understand the explanations about the needs for this information since Juanuary 2010 does not automatically means that the information is useless .

For point 2 )
In case you are in the condition to setup a service LSP over an infrastructure LSP at HO, you can deduce TS granularity form auto-negotiation happened in the termination points of LSP. In case no HO-LSP exist , TS can be deduce or by NMS configuration or by LMP providing PT/TS exchanging or it has to be advertised by routing even is a link information.
But TS granularity has to be signalled to allow automatic FA setup in the case FA has to be setup in a mixed TS granularity scenarios , and if for example I’m signalling ODU0 , with mandatory TS=1.25.

For point 3 ) this is an extract of G.798 , explaining auto-negotiation process happened in any ODUkP/ODUj_X  adapatation function, exchanging PT from which it can be deduced TS granularity.

PT: The function shall insert code "0010 0001" (ODU multiplex structure supporting ODTUk.ts or
ODTUk.ts and ODTUjk) into the PT byte position of the PSI overhead as defined in clause 15.9.2.1
of [ITU-T G.709] for k=4.
For k=2,3 the inserted PT code shall default to code “0010 0001”. This code may be replaced by
code “0010 0000” under control of the PT=21-to-PT=20 interworking process described hereafter.
When MI AUTOpayloadtype is activated the function shall adapt a PT21 supporting port to a PT20
structure.
If the corresponding adaptation Sink provides the information of a PT=20 at the RI_ AcPT the
function shall fall back to PT=20 under the following conditions: The MI_AUTOpayloadtype is
Rec. ITU-T G.798 (10/2010) – Prepublished version 262
true and the HO ODU source is either not provisioned for any traffic signal structure, or the HO
ODU2 source configured for one or more ODU1 signals to be mapped into TS1/TS5 and/or
TS2/TS6 and/or TS3/TS7 and/or TS4/TS8, or the HO ODU3 source is configured to support one or
more ODU1 signals mapped into TS1/TS17, TS2/TS18, TSi/TS16+I and/or one or more ODU2
signals mapped into TSa/TS16+a/TSb/TS16+b/TSc/TS16+c/TSd/TS16+16 and no other ODU type
signals. In this case the function shall insert PT20 into the PSI positions.
In the case the ODU2 or ODU3 adaptation source is configured for either ODU0, or an ODUflex, or
an ODU2e, or for an ODU1 in TSi/TSj with j<>4+i (for ODU2) or j<>16+I (for ODU3) then PT21
is to be inserted. The inserted PT shall be reported at the ODUkP/ODUj-21_A_So_RI_TrPT to the
corresponding adaptation sink function and the ODUkP/ODUj-21_A_So_MI_TrPT.

Thanks

Sergio

sent from my PC
Inviato: venerdì 22 luglio 2011 15.01

Sergio,

Thanks,

John

Sent from my iPhone

In line

SERGIO BELOTTI

ALCATEL-LUCENT

Comments inline.

Sent from my iPhone

John,

Thanks

sergio

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi all,

Thanks

Fatai

---

From: John E Drake <[email-masked]>
Date: Fri, 22 Jul 2011 07:23:32 -0700

Sergio,

Let me try again.

I think we have all agreed to the following:

For an LSP established  over a set of ODUk/OTUK links, the tributary slot size changes hop-by-hop and the proposed tributary slot size carried in signaling changes hop-by-hop, thus there is no meaning to the concept of an end-to-end tributary slot size for an LSP.

This has several ramifications which apparently were not clear from my  previous emails:

1)      The proposed tributary slot size carried in signaling is redundant, because the tributary slot size of each underlying ODUk/OTUk link along the LSP’s path is already known to the endpoints of each hop

2)      Carrying redundant information is bad because one has to deal with the error cases in which the redundant information is contradictory

3)      Because there is no meaning to the concept of an end-to-end tributary slot size for an LSP, there is no meaning to the concept of signaling a tributary slot size for an LSP to be established within a hierarchical LSP

So, please explain to me in twenty five words or less the positive marginal utility of carrying tributary slot size in signaling.

*All of the above* applies to carrying ODUk/OTUk link capacity in signaling.   Please provide the same twenty word or less explanation of the positive marginal utility of carrying ODUk/OTUk  capacity in signaling.

Thanks,

John

Sent from my iPhone

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, July 22, 2011 6:52 AM
To: John E Drake
Cc: Fatai Zhang; 'CCAMP'
Subject: R: [CCAMP] the merged OTN signaling draft uploaded

John,

For point 1)

For point 2 )

Thanks

Sergio

sent from my PC

Sergio,

Thanks,

John

Sent from my iPhone

In line

SERGIO BELOTTI

ALCATEL-LUCENT

Comments inline.

Sent from my iPhone

John,

Thanks

sergio

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi all,

Thanks

Fatai

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 22 Jul 2011 15:45:59 +0000

John,

I completely agree with you. The function of signaling is to provide minimal sufficient hop-by-hop *connection specific* information, so that NEs along the path could be provisioned in a satisfactory and coherent way. What is the point of signaling link specific information, such as TS granularity? It would only make sense if a link can support more than one TS type, and it is possible to choose one on per-service basis. If this is not the case,   then every NE knows its own links better than anyone else on the network and the signaling will provide no additional information at best, and can bring confusion at worst. In fact, the path for the connection was selected based on the information advertised by NEs. As you correctly pointed out, signaling TS granularity could be only used for a sanity check and therefore IMO redundant.

Igor

From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Friday, July 22, 2011 9:01 AM
To: BELOTTI, SERGIO (SERGIO)
Cc: 'CCAMP'
Subject: Re: [CCAMP] the merged OTN signaling draft uploaded

Sergio,

Thanks,

John

Sent from my iPhone

In line

SERGIO BELOTTI

ALCATEL-LUCENT

Comments inline.

Sent from my iPhone

John,

Thanks

sergio

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi all,

Thanks

Fatai

---

From: John E Drake <[email-masked]>
Date: Fri, 22 Jul 2011 08:54:31 -0700

Igor,

Thanks.  I think the same reasoning applies to the ODUk/OTUk link capacity field.

Thanks,

John

Sent from my iPhone

From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, July 22, 2011 8:46 AM
To: John E Drake; BELOTTI, SERGIO (SERGIO)
Cc: 'CCAMP'
Subject: RE: [CCAMP] the merged OTN signaling draft uploaded

John,

Igor

Sergio,

Thanks,

John

Sent from my iPhone

In line

SERGIO BELOTTI

ALCATEL-LUCENT

Comments inline.

Sent from my iPhone

John,

Thanks

sergio

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi all,

Thanks

Fatai

---

From: Fatai Zhang <[email-masked]>
Date: Sat, 23 Jul 2011 13:14:55 +0800

Hi guys,

I really like technical discussion, but please don't make the air tense, :-), we are all working for the industry (std), not for oneself. 

I am trying to make some clarifications as below:

(1) An interface of one link end could support different TS size (1.25G, 2.5G) (G.709V3), but another end interface may only support 2.5G TS size (or it may support either 1.25G or 2.5G or both), this is the reality. In this case, the both ends should understand which TS size will be used.

(2) It seems that TS and ODU(T)K fileds are "redundant“ because of local knowledge, but if you look at the label format, you will see that the length of label bitmap is variable. The number of the needed labels depends on the TS size and ODU(T)k (ie., the length of bitmap can be deduced from these two fields). When the downstream allocates the labels, it should tell how many TS and which TS will be used, and then the upstream node can use these information for checking integrity because of the variable length of bitmap.

(3) To John, Sergio's H-LSP is multi-hop H-LSP(which will pass through multiple links with different TS size), not one-hop H-LSP.

(4) If you like to remove these fields, please investigate whether there are some problems to make your advocated "multi-stage label" approach can not work, :-)

(5)In addition, it is usually preferable to have the explicit information carried in the signaling for checking integrity for both ends. I would like to give another example (I am sure if it is appropriate here). for example, there is always "length" field in the fixed length of object, but we don't suspect that it is redundant.

(6) This issue is quite minor, if it it really redundant , we can just remove them, but I hope you all investigate more. 

Fatai

Thanks
  ----- Original Message ----- 
  From: Igor Bryskin 
  To: John E Drake ; BELOTTI, SERGIO (SERGIO) 
  Cc: 'CCAMP' 
  Sent: Friday, July 22, 2011 11:45 PM
  Subject: Re: [CCAMP] the merged OTN signaling draft uploaded

  John,

  Igor

  Sergio,

  Thanks,

  John    

  Sent from my iPhone

  In line

  SERGIO BELOTTI 

  ALCATEL-LUCENT 

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

  Comments inline.

  Sent from my iPhone

  John,

  Thanks

  sergio

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

  Fatai,

  Thanks,

  John    

  Sent from my iPhone

  Hi John,

   

   

  Thanks
   
  Fatai

  Fatai,

   

  Thanks,

  John

  Sent from my iPhone

  Hi all,

  We would like to request all of you to have a careful review on this merged draft and then share your comments or suggestions freely, so I am not going to summarize what we have achieved, J.

   

  Thanks
   
  Fatai

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

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

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Mon, 25 Jul 2011 15:10:58 +0200

Igor,

“It would only make sense if a link can support more than one TS type, and it is possible to choose one on per-service basis”

And this is exactly what can happen.  For signaling  to set up HO ODUk, the end node must know if 1.25G TS capability is needed . The ODUk termination and HO/LO adaptation are frequently implemented on a port card, and a 1.25G TS capable node may have old and new port cards, not all of which are 1.25G TS capable. The node needs to know if it is necessary to choose a 1.25G TS capable interface .
I suggest to examine as said by Fatai, very careful the different scenarios before going directly suggesting  to delete information.

Sergio

________________________________
Da: Igor Bryskin [mailto:[email-masked]]
Inviato: venerdì 22 luglio 2011 17.46
A: John E Drake; BELOTTI, SERGIO (SERGIO)
Cc: 'CCAMP'
Oggetto: RE: [CCAMP] the merged OTN signaling draft uploaded

John,

Igor

Sergio,

Thanks,

John

Sent from my iPhone

In line

SERGIO BELOTTI

ALCATEL-LUCENT

Comments inline.

Sent from my iPhone

John,

Thanks

sergio

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi all,

Thanks

Fatai

---

From: John E Drake <[email-masked]>
Date: Mon, 25 Jul 2011 07:21:16 -0700

Sergio,

I think Igor meant that a given interface could support multiple TS granularities, which is different from what you are saying.

The signaling request specifies the TE link to be used to for the LSP and hence the link's characteristics, including TS granularity.  So, as I have said before, this is not needed in signaling.

John

Sent from my iPhone

On Jul 25, 2011, at 9:11 AM, "BELOTTI, SERGIO (SERGIO)" <[email-masked]<mailto:[email-masked]>> wrote:

Igor,

Sergio

John,

Igor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Friday, July 22, 2011 9:01 AM
To: BELOTTI, SERGIO (SERGIO)
Cc: 'CCAMP'
Subject: Re: [CCAMP] the merged OTN signaling draft uploaded

Sergio,

Thanks,

John

Sent from my iPhone

In line

SERGIO BELOTTI

ALCATEL-LUCENT

via Trento 30 , Vimercate(MI)  Italy
T: +39 0396863033
[email-masked]<mailto:[email-masked]>

Comments inline.

Sent from my iPhone

John,

Thanks

sergio

________________________________
Da: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Per conto di John E Drake
Inviato: venerdì 22 luglio 2011 14.00
A: Fatai Zhang; 'CCAMP'
Oggetto: Re: [CCAMP] the merged OTN signaling draft uploaded

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Thursday, July 07, 2011 8:23 PM
To: 'CCAMP'
Subject: [CCAMP] the merged OTN signaling draft uploaded

Hi all,

We would like to request all of you to have a careful review on this merged draft and then share your comments or suggestions freely, so I am not going to summarize what we have achieved, ☺.

<http://www.ietf.org/id/draft-zhang-ccamp-gmpls-evolving-g709-08.txt>http://www.ietf.org/id/draft-zhang-ccamp-gmpls-evolving-g709-08.txt

Thanks

Fatai

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Mon, 25 Jul 2011 16:36:04 +0200

John,

What is the difference form Igor meant, I'm talking about different TS granularities in fact, or 1.25 is not a TS granularity in OTN ???

Sergio

SERGIO BELOTTI

ALCATEL-LUCENT

-----Messaggio originale-----
Da: John E Drake [mailto:[email-masked]] 
Inviato: lunedì 25 luglio 2011 16.21
A: BELOTTI, SERGIO (SERGIO)
Cc: Igor Bryskin; CCAMP; Fatai
Oggetto: Re: R: [CCAMP] the merged OTN signaling draft uploaded

Sergio,

John

Sent from my iPhone

Igor,

Sergio

John,

Igor

Sergio,

Thanks,

John

Sent from my iPhone

In line

SERGIO BELOTTI

ALCATEL-LUCENT

Comments inline.

Sent from my iPhone

John,

Thanks

sergio

Fatai,

Thanks,

John

Sent from my iPhone

Hi John,

Thanks

Fatai

Fatai,

Thanks,

John

Sent from my iPhone

Hi all,

Thanks

Fatai

---

From: John E Drake <[email-masked]>
Date: Mon, 25 Jul 2011 07:40:50 -0700

Can a given interface simultaneously support more than one TS  
granularity?

Sent from my iPhone

On Jul 25, 2011, at 10:37 AM, "BELOTTI, SERGIO (SERGIO)" <[email-masked] 
 > wrote:

> John,
>
> What is the difference form Igor meant, I'm talking about different  
> TS granularities in fact, or 1.25 is not a TS granularity in OTN ???
>
>
> Sergio
>
> SERGIO BELOTTI
>
> ALCATEL-LUCENT
> I think Igor meant that a given interface could support multiple TS  
> granularities, which is different from what you are saying.
>
> The signaling request specifies the TE link to be used to for the  
> LSP and hence the link's characteristics, including TS granularity.   
> So, as I have said before, this is not needed in signaling.
>
> John
>
> Sent from my iPhone
>
> On Jul 25, 2011, at 9:11 AM, "BELOTTI, SERGIO (SERGIO)" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Igor,
>
> “It would only make sense if a link can support more than one TS typ 
> e, and it is possible to choose one on per-service basis”
>
> And this is exactly what can happen.  For signaling  to set up HO  
> ODUk, the end node must know if 1.25G TS capability is needed . The  
> ODUk termination and HO/LO adaptation are frequently implemented on  
> a port card, and a 1.25G TS capable node may have old and new port  
> cards, not all of which are 1.25G TS capable. The node needs to know  
> if it is necessary to choose a 1.25G TS capable interface .
> I suggest to examine as said by Fatai, very careful the different  
> scenarios before going directly suggesting  to delete information.
>
> Sergio
>
>
> I completely agree with you. The function of signaling is to provide  
> minimal sufficient hop-by-hop *connection specific* information, so  
> that NEs along the path could be provisioned in a satisfactory and  
> coherent way. What is the point of signaling link specific  
> information, such as TS granularity? It would only make sense if a  
> link can support more than one TS type, and it is possible to choose  
> one on per-service basis. If this is not the case,   then every NE  
> knows its own links better than anyone else on the network and the  
> signaling will provide no additional information at best, and can  
> bring confusion at worst. In fact, the path for the connection was  
> selected based on the information advertised by NEs. As you  
> correctly pointed out, signaling TS granularity could be only used  
> for a sanity check and therefore IMO redundant.
>
> Igor
>
> From: [email-masked]<mailto:[email-masked]>  
> [mailto:[email-masked]] On Behalf Of John E Drake
> You did not actually address any of my three points;  your one  
> comment is an example of the usage of the word ‘smug’.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
> [email-masked]<mailto:[email-masked] 
> >
>
> TS granularity is a paramenter discussed a lot when we wrote  
> reaquireemtns and needed information for signalling and routing.  
> This is why is explicitly present as needed information in the info  
> draft .
>
> JD:   Just because at one time  it was thought to be needed does not  
> mean that upon reflection it is still needed, and for the record,  
> ever since January 2010 I have been asking why it is needed in  
> signaling
>
> Encoding draft is the mirror of what discussed before .  Anyway TS  
> granularity is an essential parameter to be configured in the  
> physical interfaces and permit  end nodes of an FA to understand  
> which TS  to be used.
>
> JD:  How is it possible to specify tributary slot size for a  
> hierarchical LSP?  A hierarchical LSP inherits the tributary slot  
> size(s) of the underlying ODUk/OTUk links over which it is routed,  
> and as Fatai indicates  the tributary slot size can change hop-by-hop
>
> Moreover , there is the auto-negotiation and his CP relationship  
> that is one of the open point that again could require as mandatory  
> to have TS gran. As signalling parameter (and in certain cases also  
> for routing) .
>
> Da: [email-masked]<mailto:[email-masked]>  
> [mailto:[email-masked]] Per conto di John E Drake
> If it is the case that tributary slot size and ODUk/OTUk link  
> capacity are intended to change hop-by-hop, then these fields are  
> completely redundant and should be removed.
>
> The underlying TE link is explicitly identified in the signaling  
> message and hence its tributary slot size and its link capacity are  
> known.  Further, including these fields introduces additional error  
> cases caused by a mismatch between the values in these fields and  
> the known values of the underlying TE link.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
> 2)      Why is tributary slot size included?  Will it not change hop- 
> by-hop, as the tributary slot size of each hop’s underlying UDUk/OTU 
> k link can take on one of two different values?  I.e., I don’t think 
>  having an single end-to-end tributary slot size makes sense.
> [Fatai] Do you mean label information should be end-to-end?  
> Actually, label information is link/span scope, it can be changed  
> hop by hop, so, tributary slot type (1.25G or 2.5G) can be changed  
> hop by hop, there is no problem.  In addition, label allocation  
> depends on the tributary slot size (1.25G or 2.5G).
>
>
> 3)      Why is the OD(T)Uk  field needed?  As with 2), above, the  
> value of k for the underlying ODUk/OTUk link (or hierarchical LSP)  
> will change hop-by-hop.
> [Fatai] As explained above, label information is link/span scope, so  
> there is no problem when ODU/OTUk link (or H-LSP) changes hop by hop.
>
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
> From: [email-masked]<mailto:[email-masked]>  
> [mailto:[email-masked]] On Behalf Of Fatai Zhang
> We would like to request all of you to have a careful review on this  
> merged draft and then share your comments or suggestions freely, so  
> I am not going to summarize what we have achieved, ☺.
>

---

From: Rajan Rao <[email-masked]>
Date: Mon, 25 Jul 2011 18:01:59 +0000

Yes, at different hierarchy levels. 

Thanks
Rajan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Monday, July 25, 2011 7:41 AM
To: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP
Subject: Re: [CCAMP] R: R: the merged OTN signaling draft uploaded

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Mon, 25 Jul 2011 11:42:06 -0700

Section 4.1 of Information model for G.709 Optical Transport Networks (OTN) (http://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-g709-info-model/?include_text=1) states:

"ITU-T recommendations define two types of TS but each link can only support a single type at a given time.  The rules to be followed when selecting the TS to be used are:

      - If both ends of a link can support both 2.5Gbps TS and 1.25Gbps
      TS, then the link will work with 1.25Gbps TS.

      - If one end can support the 1.25Gbps TS, and another end the
      2.5Gbps TS, the link will work with 2.5Gbps TS."

Sent from my iPhone

> From: Rajan Rao [mailto:[email-masked]]
> Sent: Monday, July 25, 2011 11:02 AM
> Subject: RE: [CCAMP] R: R: the merged OTN signaling draft uploaded
> 
> > <http://www.ietf.org/id/draft-zhang-ccamp-gmpls-evolving-g709-
> 08.txt>http://www.ietf.org/id/draft-zhang-ccamp-gmpls-evolving-g709-
> 08.txt
> >
> >
> > Thanks
> >
> > Fatai
> >

---

From: Rajan Rao <[email-masked]>
Date: Mon, 25 Jul 2011 19:11:50 +0000

John,

At any given time we can use only one type of TSG for a given hierarchy level even though both TSGs are supported. You can pick the TSG to use at the time of LSP setup. 

The Dataplane allows PT negotiation, however PT negotiation can happen upon adaptation function creation, i.e. it is tied to LO-ODU service. 

What I meant by multiple layers is the following.  Here is an example:

Suppose, the hierarchy on a OTU4 link is: ODU4-ODU3-ODU2-ODU0

The OPU4 may operate with TSG=1.25G
The OPU3 may operate with TSG=2.5G
The OPU2 may operate with TSG=1.25G

The sig can decide what TSG to use for each of the layer above.

Thanks
Rajan

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Monday, July 25, 2011 2:42 PM
To: Rajan Rao; BELOTTI, SERGIO (SERGIO)
Cc: CCAMP
Subject: RE: [CCAMP] R: R: the merged OTN signaling draft uploaded

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Mon, 25 Jul 2011 12:16:40 -0700

Why don't you and the authors of the draft I referenced get together
and give the list a definitive statement of reality as it pertains to
OTN?

Sent from my iPhone

On Jul 25, 2011, at 3:11 PM, "Rajan Rao" <[email-masked]> wrote:

> John,
>
> At any given time we can use only one type of TSG for a given
> hierarchy level even though both TSGs are supported. You can pick
> the TSG to use at the time of LSP setup.
>
> The Dataplane allows PT negotiation, however PT negotiation can
> happen upon adaptation function creation, i.e. it is tied to LO-ODU
> service.
>
>
> Section 4.1 of Information model for G.709 Optical Transport
> Networks (OTN) (http://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-g709-info-model/?include_text=1
> ) states:
>
> "ITU-T recommendations define two types of TS but each link can only
> support a single type at a given time.  The rules to be followed
> when selecting the TS to be used are:
>
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf
>> Of John E Drake
>>> 1)      Why isn’t Signal Type, defined in the OTN routing draft,
>>>  use
>>> d instead of the four bit ODUj field?