Subject: [CCAMP] Thought on where to carry G.709-v3 TSG

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 4 Oct 2011 15:33:47 +0200

Lou,

See in line

Pietro and Sergio

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

Pietro, Sergio,

It looks like we may be converging.  We agree that encoding isn't optimal, and you only have a slight preference for G-PID.  For me the tipping point is on intermediate node use of TSG*.  At this point you have said that this is never needed.  It's my understanding that this isn't correct, and there are cases where it is needed.  Consider the case where there is a 1.25G TSG LSP (e.g., ODU0 or ODUflex) that is being signaled across a topology composed of ODU2 H-LSPs, some of which can support 1.25G TSG and others that only support 2.5G TSG.  Don't the intermediate nodes need to understand the TSG of the LSP in order to select the proper outgoing H-LSPs?

[[ALU]] No. The point is that the intermediate nodes have only to consider the LSP signal type (ODU1, ODU2 etc..), and not the TSG that the LSP exports to its clients at the endpoints. So it happens that an ODU0 can only be carried on H-LSPs that export 1.25 TSG to their clients (by G.709 definition). An ODU2 instead can be carried on H-LSPs that export either 1.25 or 2.5. Where you have to consider both the LSP type and the TSG exported to LSP clients is the penultimate node. On that node the interface choice has to be made in such a way that the endpoint can:

1) support the signal type indicated by the LSP
2) structure the LSP with the required adaptation
3) support all the required hierarchies

(*) In a private mail (which the author may resend to the list) the point was also made that by using G-PID for TSG we loose the ability to identify the client adaptation supported by the LSP, e.g., Ethernet.

[[ALU]]
In OTN an ODUj LSP either carries an ODUj client or a client of different technology. When we set up a ODU3 H-LSP that will carry an ODUj client, the G-PID of the ODU3 H-LSP simply indicates that the client is an ODUj.
In OTN when you structure a payload you are not defining which will be the signal types of the carried ODU.
Once that the ODU3 H-LSP is structured, in order to carry Ethernet you should set up a client ODUj that in turn will carry Ethernet. The G-PID of this ODUj will contain Ethernet.

Instead related to this point what we can add is that in case of not-ODU clients the TSG is a useless parameter. This would imply to have up to three signal types for every ODU , For example you would need an ODU2-1.25, an ODU2-2.5 and an ODU2-neutral (e.g for Ethernet client).

Please see below for detailed responses.

On 10/4/2011 4:31 AM, GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) wrote:
> 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.
>

It looks like we may be converging.

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

Well I don't mind us reaching the same conclusion, even if our rational isn't the same.

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

Huh?  RFC4328 says:

   The G-PID (16 bits field), as defined in [RFC3471], identifies the
   payload carried by an LSP, i.e., an identifier of the client layer of
   that LSP.  This identifier is used by the endpoints of the G.709 LSP.

   The G-PID can take one of the following values when the client
   payload is transported over the Digital Path layer, in addition to
   the payload identifiers defined in [RFC3471]:

Clearly the rfc envisions use of multiple G-PIDs based on the use of the
G.709 LSP.

[ALU] The only value related to ODUjk is 47. The other (linked to G.709 v3) can not be present ...since G.709v3 was not present at that time.

> The extension of G-PID would be one to one consistent with G.709.

This is where our perspective diverges.

[ALU] Why?

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

I addressed this point in my original mail:
>> Hereto, the 1.25 types would imply support for both 1.25 and 2.5
>> types in routing.

Also note that the routing draft currently says:
   A single ISCD MAY be used for the advertisement of unbundled or
   bundled links supporting homogeneous multiplexing hierarchies and the
   same Tributary Slot Granularity (TSG).  A different ISCD MUST be used
   for each different muxing hierarchy (muxing tree in the following
   examples) and different TSG supported within the TE Link, if it
   includes component links with differing characteristics.

[ALU] We addressed the point also in a previous mail in which you seem to converge in the opportunity to have at least two different signal types values.
1.25 does not imply the support also for both 1.25/2.5 as reported in this snip of a previous mail.
Snip>
> To
> complicate things, it is not always true that an interface supporting
> 1.25 tributary slots can also support 2.5 tributary slots, because
> this specific functionality (known as fallback support setting
> auto-payload flag to ON) can be either not present in HW or disabled
> by NMS.
>

Well this is something I didn't have in my original mail.  It was my understanding from previous discussions, that fallback support was a required in G.709-v3.  If it is optional (either in implementation or in
operation) we need to ensure that both cases (1.25 + 2.5 support, or just 1.25 support) are fully covered.

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

Wouldn't you agree that client layer adaptation is only within the scope of the endpoints?  The sole exception that I can think of is PHP.
Perhaps I'm missing something.

[ALU] We have in mind a different case: supposing to have an ODU2 LSP carrying an Ethernet client and suppose you have an OTU2 interface able to terminate ODU2 and extract Ethernet. At penultimate this interface may be selected for the ODU2 LSP and selection criteria is the G-PID value indicating Ethernet payload and not for example FiberChanne/ATM.

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

Sure.  Per IETF process, a WG document represents WG consensus.

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

I'm not sure which text you are referring to, but if you think it's covered in the routing draft, then we're in sync.

[ALU] The text is in the G.709-info draft , and is related to a dedicated optional object to insert in signalling , not in routing, where the supported hierarchies are already present.

Much thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 05 Oct 2011 13:15:39 -0400

Guys,
	I think we're going in circles.  Let me try a different question that
hopefully can help us resolve this.

Are there *any* cases where an LSP's supported TSG impacts label
allocation/selection?

If the answer is yes, then TSG belongs in the traffic parameters.

Thanks,
Lou

PS your reference to some text in the info document, rather than
keeping us guessing, can you point to a section and paragraph number or
just copy and paste the text?

On 10/4/2011 9:33 AM, BELOTTI, SERGIO (SERGIO) wrote:
> Lou,
>  
> See in line
>  
> Pietro and Sergio
>  
> ---------------------
>  
> Pietro, Sergio,
>  
> It looks like we may be converging.  We agree that encoding isn't
> optimal, and you only have a slight preference for G-PID.  For me the
> tipping point is on intermediate node use of TSG*.  At this point you
> have said that this is never needed.  It's my understanding that this
> isn't correct, and there are cases where it is needed.  Consider the
> case where there is a 1.25G TSG LSP (e.g., ODU0 or ODUflex) that is
> being signaled across a topology composed of ODU2 H-LSPs, some of which
> can support 1.25G TSG and others that only support 2.5G TSG.  Don't the
> intermediate nodes need to understand the TSG of the LSP in order to
> select the proper outgoing H-LSPs?
>  
> [[ALU]] No. The point is that the intermediate nodes have only to
> consider the LSP signal type (ODU1, ODU2 etc..), and not the TSG that
> the LSP exports to its clients at the endpoints. So it happens that an
> ODU0 can only be carried on H-LSPs that export 1.25 TSG to their clients
> (by G.709 definition). An ODU2 instead can be carried on H-LSPs that
> export either 1.25 or 2.5. Where you have to consider both the LSP type
> and the TSG exported to LSP clients is the penultimate node. On that
> node the interface choice has to be made in such a way that the endpoint
> can:
>  
> (*) In a private mail (which the author may resend to the list) the
> point was also made that by using G-PID for TSG we loose the ability to
> identify the client adaptation supported by the LSP, e.g., Ethernet.
>  
> [[ALU]]
> In OTN an ODUj LSP either carries an ODUj client or a client of
> different technology. When we set up a ODU3 H-LSP that will carry an
> ODUj client, the G-PID of the ODU3 H-LSP simply indicates that the
> client is an ODUj.
> Once that the ODU3 H-LSP is structured, in order to carry Ethernet you
> should set up a client ODUj that in turn will carry Ethernet. The G-PID
> of this ODUj will contain Ethernet.
>  
> Instead related to this point what we can add is that in case of not-ODU
> clients the TSG is a useless parameter. This would imply to have up to
> three signal types for every ODU , For example you would need an
> ODU2-1.25, an ODU2-2.5 and an ODU2-neutral (e.g for Ethernet client).
>  
>  
>  
>  
> [ALU] The only value related to ODUjk is 47. The other (linked to G.709
> v3) can not be present …since G.709v3 was not present at that time.
>  
> [ALU] We addressed the point also in a previous mail in which you seem
> to converge in the opportunity to have at least two different signal
> types values.
> Well this is something I didn't have in my original mail.  It was my
> understanding from previous discussions, that fallback support was a
> required in G.709-v3.  If it is optional (either in implementation or in
> Wouldn't you agree that client layer adaptation is only within the scope
> of the endpoints?  The sole exception that I can think of is PHP.
> [ALU] We have in mind a different case: supposing to have an ODU2 LSP
> carrying an Ethernet client and suppose you have an OTU2 interface able
> to terminate ODU2 and extract Ethernet. At penultimate this interface
> may be selected for the ODU2 LSP and selection criteria is the G-PID
> value indicating Ethernet payload and not for example FiberChanne/ATM.
>  
>>
> I'm not sure which text you are referring to, but if you think it's
> covered in the routing draft, then we're in sync.
>  
> [ALU] The text is in the G.709-info draft , and is related to a
> dedicated optional object to insert in signalling , not in routing,
> where the supported hierarchies are already present.
>  
> Much thanks,
> Lou
>  
>  
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 10 Oct 2011 15:06:33 +0200

Hi Lou,

Let's try with an example showing that in a muxing hierarchy not every layer must use the same TSG. Please consider the following path.

                     IF1     IF2
A ------ B -------- C ----------D
|--ODU2--|          |---ODU2----|
         |---ODU3---|

Suppose an ODU2 from A to D is set up in order to carry an ODU0, so D needs to be able to perform ODU0->ODU2 demuxing. The ODU2 is carried over an ODU3 FA from B to C.
B is not able to support ODU2 and can only carry it through an ODU3@2,5Gbps TSG. It does not care about the fact that the ODU2 is carrying and ODU0 and a 1,25 TSG is needed to extract it, since the extraction is performed by D.

D advertises both hierarchy information and TSG capability on IF2: muxing hierarchy ODU0->ODU2 and TSG field = 01 (i.e. Both 1,25 and 2,5 supported).

The ODU0 is terminated only on D, so B can forward the ODU2 over the ODU3 FA using a TSG = 2,5 Gbps *but* if multiple interfaces are present from C to D, C must choose an OTU2 inferface supporting an 1,25 TSG adaptation towards the client.
 
In conclusion, when setting up an ODU2 LSP, that has to be able to extract an ODU0 in the termination node, TSG information carried in the ODU2 LSP signaling (so referred to ODU0 carried over it) has NO impact on the label allocation for the ODU2 LSP (in fact label allocation for link BC is @2,5 Gbps). Label allocation for the ODU2 LSP is impacted by the TSG capability offered by the underlying ODU3 link/FA.

So the answer to you question is: The LSP's supported TSG does not impact the label allocation/selection. The label allocaction/selection is only impacted by the server link/FA TSG.

As a further clarification, the reason why in our opinion the TSG is not relevant to the traffic parameters is that the type of LSP being set up does not influence the TSG of the server layer (which has already been fixed) but only the choice of the right server.

Thanks
Daniele, Sergio, Pietro

PS. The piece of text in the info model referring to the optional object is in page 9, section 4.1:
"The G-PID information is not enough to have a complete choice since
 the penultimate hop node has to distinguish between interfaces with
 the same TSG (e.g. 1.25Gbps) whether the interface is able to support
 the right hierarchy, i.e. it is possible to have two interfaces both
 at 1.25 TSG but only one is supporting ODU0.

 A dedicated optional object should to be defined in order to carry
 the multiplexing hierarchy and have a more precise choice capability.
 In this way, when the penultimate node receives the GENERALIZED LABEL
 REQUEST Object, the G-PID value together with the ODU bandwdith
 included into the Traffic Parameters Object allow desuming the
 correct TSG value."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: mercoledì 5 ottobre 2011 19.16
To: BELOTTI, SERGIO (SERGIO); GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG

Guys,
	I think we're going in circles.  Let me try a different question that hopefully can help us resolve this.

Are there *any* cases where an LSP's supported TSG impacts label allocation/selection?

Thanks,
Lou

PS your reference to some text in the info document, rather than keeping us guessing, can you point to a section and paragraph number or just copy and paste the text?

On 10/4/2011 9:33 AM, BELOTTI, SERGIO (SERGIO) wrote:
> being signaled across a topology composed of ODU2 H-LSPs, some of 
> which can support 1.25G TSG and others that only support 2.5G TSG.
> Don't the intermediate nodes need to understand the TSG of the LSP in 
> order to select the proper outgoing H-LSPs?
>  
> ODU0 can only be carried on H-LSPs that export 1.25 TSG to their 
> clients (by G.709 definition). An ODU2 instead can be carried on 
> H-LSPs that export either 1.25 or 2.5. Where you have to consider both 
> the LSP type and the TSG exported to LSP clients is the penultimate 
> node. On that node the interface choice has to be made in such a way 
> that the endpoint
> can:
>  
> point was also made that by using G-PID for TSG we loose the ability 
> to identify the client adaptation supported by the LSP, e.g., Ethernet.
>  
> [[ALU]]
> should set up a client ODUj that in turn will carry Ethernet. The 
> G-PID of this ODUj will contain Ethernet.
>  
> Instead related to this point what we can add is that in case of 
> not-ODU clients the TSG is a useless parameter. This would imply to 
> have up to three signal types for every ODU , For example you would 
> need an ODU2-1.25, an ODU2-2.5 and an ODU2-neutral (e.g for Ethernet client).
>  
>  
>  
>  
> v3) can not be present .since G.709v3 was not present at that time.
>  
> Wouldn't you agree that client layer adaptation is only within the 
> scope of the endpoints?  The sole exception that I can think of is PHP.
> carrying an Ethernet client and suppose you have an OTU2 interface 
> able to terminate ODU2 and extract Ethernet. At penultimate this 
> interface may be selected for the ODU2 LSP and selection criteria is 
> the G-PID value indicating Ethernet payload and not for example FiberChanne/ATM.
>  
>>
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Mon, 10 Oct 2011 09:41:22 -0400

On 10/10/2011 9:06 AM, Daniele Ceccarelli wrote:
> Hi Lou,
> 
> Let's try with an example showing that in a muxing hierarchy not
> every layer must use the same TSG. 

Sure, while helpful, I believe this is understood by all and not the
issue I'm trying to get at.

> Please consider the following
> path.
> 
>                      IF1     IF2
> Suppose an ODU2 from A to D is set up in order to carry an ODU0, so D
> needs to be able to perform ODU0->ODU2 demuxing. The ODU2 is carried
> over an ODU3 FA from B to C. B is not able to support ODU2 and can
> only carry it through an ODU3@2,5Gbps TSG. It does not care about the
> fact that the ODU2 is carrying and ODU0 and a 1,25 TSG is needed to
> extract it, since the extraction is performed by D.
> 
> D advertises both hierarchy information and TSG capability on IF2:
> muxing hierarchy ODU0->ODU2 and TSG field = 01 (i.e. Both 1,25 and
> 2,5 supported).
> 
> The ODU0 is terminated only on D, so B can forward the ODU2 over the
> ODU3 FA using a TSG = 2,5 Gbps *but* if multiple interfaces are
> present from C to D, C must choose an OTU2 inferface supporting an
> 1,25 TSG adaptation towards the client.
> 
> In conclusion, when setting up an ODU2 LSP, that has to be able to
> extract an ODU0 in the termination node, TSG information carried in
> the ODU2 LSP signaling (so referred to ODU0 carried over it) has NO
> impact on the label allocation for the ODU2 LSP (in fact label
> allocation for link BC is @2,5 Gbps). Label allocation for the ODU2
> LSP is impacted by the TSG capability offered by the underlying ODU3
> link/FA.
> 
> So the answer to you question is: The LSP's supported TSG does not
> impact the label allocation/selection. The label
> allocaction/selection is only impacted by the server link/FA TSG.
> 
> As a further clarification, the reason why in our opinion the TSG is
> not relevant to the traffic parameters is that the type of LSP being
> set up does not influence the TSG of the server layer (which has
> already been fixed) but only the choice of the right server.

Let's consider the slightly more complicated case:
In this case an ODU0 LSP is being switched at a transit node
interconnected via the FAs/H-LSPs described above.

 ---- A ---- B ---- C ----(D -XC- D)---- F ---- G -----H ----
Links/switching
 ODU0-|                    |-ODU0-|                    |-ODU0
      |-ODU2-|      |-ODU2-|      |-ODU2-|      |-ODU2-|
             |-ODU3-|                    |-ODU3-|
LSPs
 |------------------------ ODU0 LSP -------------------------|
      |---- ODU2 H-LSP ----|      |---- ODU2 H-LSP ----|
 ODU3 H-LSPs |------|                    |------|  (could be a link)

So I think the key question to answer are:

1) What information is used to allocate the label used on the ODU0 LSP
for the A <-> D hop (provided by the left ODU2 H-LSP)?

2) What information is used on D to provision its ODU0 cross-connect
(switch) and select the proper out-going interface (H-LSP)?

3) What information is used to allocate the label used on the ODU0 LSP
for the D <-> H hop (provided by the right ODU2 H-LSP)?

4) Do any the answers change if A and H are themselves intermediate
nodes on the ODU0 LSP?

It seems to me that TSG is part of the information needed at the ODU0
transit nodes for proper resource allocation, output link (H-LSP)
selection, and label allocation.  Am I missing something?

Much thanks,
Lou

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Mon, 10 Oct 2011 16:54:54 +0200

Hello Lou,

Please see in line.

Pietro and Sergio

> for the A <-> D hop (provided by the left ODU2 H-LSP)?

[[ALU]] The information used for the ODU 0 label is:

- The FA is an ODU2 FA and declares to support the ODU0.
( before setting the ODU0 LSP the FA has been set in such a way to export 1.25 TSG to the ODU0 client, otherwise the ODU0 would not have been declared). 

Please note that the usage of ODU0 is slightly misleading (even if more easy to explain) because the ODU 0 has only one choice for the TSG: 1.25.

A more suitable example would be an ODU1 in place of ODU0. 
In this specific case the label would be dependent from the TSG exported by the ODU2 FA LSP to its client. 

> (switch) and select the proper out-going interface (H-LSP)?

[[ALU]] The cross connection is provisioned knowing the incoming and outgoing interfaces. It is the ODU0 signal that is cross connected and not the tributary slots, that have only link local meaning.

Selection of the outgoing interface: Any interface/FA connected to node H
and supporting ODU0 is selectable. Which interface is decided with a local policy. (note this is valid for each ODU LSP independently from its type)  

> for the D <-> H hop (provided by the right ODU2 H-LSP)?

[[ALU]] the same as point 1

> 4) Do any the answers change if A and H are themselves intermediate

[[ALU]] Nothing changes. The problem is not the ODU0 LSP that cannot be structured.

> selection, and label allocation.  Am I missing something?

[[ALU]] Yes. Let us try to make an analogy with SDH and ATM.

If you have to transport ATM over a SDH VC4 what happens is that
a VC4 LSP is set up, and the LSP declares GPID = ATM.

The structure at 1.25/2.5 in OTH has the same role of ATM in the example above. The structures at 1.25 and 2.5 for the data plane are two
different payloads that in G.709 are characterized by two different Payload types (PT): PT20 for 2.5 and PT 21 for 1.25.

The payload has to be considered only when selecting the last interface/FA. 
The last interface/FA must be selected in such a way to be
able to support the signal type of the LSP being set up and, in addition, to grant that the LSP termination supports a 2.5/1.25 payload structure depending from the client payload requested by signaling. (Note that it is the same if the payload is Ethernet or something else instead of 2.5/1.25 payload structure).
In your example this is expected to be applied when setting up the ODU2 FA LSPs.

Hope this clarifies.  

Much thanks,
Lou

---

From: John E Drake <[email-masked]>
Date: Mon, 10 Oct 2011 08:22:50 -0700

Snipped, comments inline.

> [[ALU]] The cross connection is provisioned knowing the incoming and
> outgoing interfaces. It is the ODU0 signal that is cross connected and
> not the tributary slots, that have only link local meaning.
> 
> and supporting ODU0 is selectable. Which interface is decided with a
> local policy. (note this is valid for each ODU LSP independently from
> its type)
[JD] 

Just to be clear, the ERO can specify a specific interface to node H.

> The structure at 1.25/2.5 in OTH has the same role of ATM in the
> example above. The structures at 1.25 and 2.5 for the data plane are
> two
> different payloads that in G.709 are characterized by two different
> Payload types (PT): PT20 for 2.5 and PT 21 for 1.25.
> 
> able to support the signal type of the LSP being set up and, in
> addition, to grant that the LSP termination supports a 2.5/1.25 payload
> structure depending from the client payload requested by signaling.
> (Note that it is the same if the payload is Ethernet or something else
> instead of 2.5/1.25 payload structure).
[JD] 

I have been having trouble with this for some time.  Why is the penultimate interface any different?  Using your example of an ODU1, it seems to me that any node on the path of that ODU1 that switches the ODU1 would need to understand its TSG.  In your ATM example above, the E2E ATM LSP can transit multiple VC4 LSPs and the nodes at either end of each would need to be able to switch ATM.

---

From: Rajan Rao <[email-masked]>
Date: Mon, 10 Oct 2011 17:08:54 +0000

Lou,

When you say H-LSP, I think you are referring to the fact that it is not advertised as a Te-Link (i.e. FA) right?  If so, we will need the TSG information as you have mentioned. Especially if you are creating nested H-LSP to carry ODU0 service.

I think you are referring to case-3 below.  

Case 1) ODU2 H-LSPs are pre-created:
 
The assumption is that BW is advertised for A-D & D-H  H-LSPs. So, ODU0 advertisement exists for this link. No need for additional TSG info.

Case 2) ODU2 H-LSPs are induced: 
  
The assumption is that BW is advertised for A-D & D-H  H-LSPs. So, ODU0 advertisement exists for this link. No need for additional TSG info.
 
Case 3) ODU2 H-LSPs are induced or pre-created but BW not advertised.
We will need TSG info here. 

Thanks
Rajan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Monday, October 10, 2011 6:41 AM
To: Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG

Much thanks,
Lou

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Tue, 11 Oct 2011 09:39:57 +0200

Hello John,

[SNIP]

[ALU] We just wanted to say that the TSG is a payload for the ODU
exactly as ATM is a payload for VC4. Different TSGs are associated to 2  different payloads: ODTUk.ts and ODTUjk.
As ATM as payload of VC4 is signaled using GPID, we think that TSG has to be signaled in GPID as payload of an ODU.
We remember that you were fine with this line of reasoning in July.

Maybe we are wrong, but it seems to us that the origin of the misunderstanding is in the confusion between the TSG used to map the ODU 1 over the FA with the TSG that the ODU 1 exports to its client.

The TSG that is in discussion is the second.

Pietro & Sergio

---

From: John E Drake <[email-masked]>
Date: Tue, 11 Oct 2011 05:45:33 -0700

Comments inline

> From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
> [mailto:[email-masked]]
> Sent: Tuesday, October 11, 2011 3:40 AM
> To: John E Drake
> Cc: CCAMP; Lou Berger; BELOTTI, SERGIO (SERGIO); GRANDI, PIETRO
> VITTORIO (PIETRO VITTORIO)
> Subject: RE: [CCAMP] Thought on where to carry G.709-v3 TSG
> 
> Hello John,
> 
> [SNIP]
> I have been having trouble with this for some time.  Why is the
> penultimate interface any different?  Using your example of an ODU1, it
> seems to me that any node on the path of that ODU1 that switches the
> ODU1 would need to understand its TSG.  In your ATM example above, the
> E2E ATM LSP can transit multiple VC4 LSPs and the nodes at either end
> of each would need to be able to switch ATM.
> 
> As ATM as payload of VC4 is signaled using GPID, we think that TSG has
> to be signaled in GPID as payload of an ODU.
[JD] 

That's actually where my trouble with this started;  everyone I spoke with gave me a different answer 8-<.

In any event, I think I'm comfortable with the ATM/VC4 analogy, so I will continue with it.

When we establish each of the VC4s that will carry ATM, the GPID will indicate ATM and the Signal Type will indicate VC4.  When we signal an E2E ATM LSP, that will carry packets, on a path containing these VC4s, I think the GPID would indicate AAL5 and the signal type will indicate ATM.

By this reasoning, it seems to me that we actually need the TSG in both the GPID and in the Signal Type, and they may be different.  I.e.,  the TSG in the GPID indicates, per your statement below, the TSG that the endpoints of an ODUk link or hierarchical LSP export to their clients, and the TSG in the Signal Type indicates, per your statement below, the TSG used to map an E2E ODUj onto the ODUk links or hierarchical LSPs on its path.

When such an E2E ODUj is established, it then has a given TSG.  If it becomes a hierarchical LSP, then when its endpoints receive a signaling request, they would check the TSG in the Signaling Type against its TSG to decide whether to grant the signaling request.

> 
> Maybe we are wrong, but it seems to us that the origin of the
> misunderstanding is in the confusion between the TSG used to map the
> ODU 1 over the FA with the TSG that the ODU 1 exports to its client.
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 11 Oct 2011 09:12:09 -0400

Pietro/Sergio/Daniele,
	I think I'm beginning to understand your point/perspective.  I think we
have a different model on how to ensure that the right adaptation
capability is provided end-to-end on a G.709 LSP.  As I understand it,
your model uses special penultimate hop processing to ensure that the
final link/H-LSP has the adaptation capability *on output* to match the
adaptation capability of the ingress.  (And the traffic parameters alone
to ensure the proper TS allocation on other transit nodes.) Is this correct?

The model I was considering ensured that the adaptation check was made
at every transit hop and, consequently, there was no special penultimate
hop case.  While this model works, I agree it is overly restrictive.

In ether model, and as you on page 9, section 4.1, G-PID isn't
sufficient to represent the support for multiple adaptations / PTs that
G.709 allows at a single endpoint.

I'm not sure what the "right/best" answer is to address this, but I want
to think a little bit on this before advocating for a particular solution.

If you agree with my first paragraph, I think we have agreement/common
understanding on the requirement in this discussion.  Also, clearly the
topic of adaptation and payload types needs to be expanded in the info
document.

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 11 Oct 2011 09:18:47 -0400

Rajan,
	In short, that particular point was/is that signaling must somehow
represent the capabilities of the LSP.  Without such information the
egress won't be able to ensure it can provided the expected
(hardware/resource/adaptation) capabilities or advertise the proper
information into routing.

Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 12 Oct 2011 10:36:08 +0200

Lou,

We are pleased to see we are converging.
Please see in line for detail.

Thanks

Sergio, Daniele, Pietro

-----Messaggio originale-----
Da: Lou Berger [mailto:[email-masked]] 
Inviato: martedì 11 ottobre 2011 15.12
A: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: CCAMP
Oggetto: Re: [CCAMP] Thought on where to carry G.709-v3 TSG

Pietro/Sergio/Daniele,

[SDP] Yes, your understanding is correct.

[SDP] In fact, G-PID would permit the selection of the right interface but would not assure the support of correct clients at the end points. This is why we proposed the optional object reporting the supported client hierarchy.

[SDP] We agree with you, take you time. The most important point is to have agreement on the model.

If you agree with my first paragraph, I think we have agreement/common
understanding on the requirement in this discussion.

[SDP] Yes , we have agreement on the requirement.

  Also, clearly the

[SDP] We will try to enhance the explanation already contained in the Info draft to clarify the concept. We will send to you in advance a draft text to check whether there is a good level of clearness.

Thanks,
Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 12 Oct 2011 11:20:40 +0200

John,

Please see inline

Thanks

Sergio, Daniele, Pietro

-----Messaggio originale-----
Da: John E Drake [mailto:[email-masked]] 
Inviato: martedì 11 ottobre 2011 14.46
A: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP; Lou Berger; BELOTTI, SERGIO (SERGIO)
Oggetto: RE: [CCAMP] Thought on where to carry G.709-v3 TSG

Comments inline

[JD] 

[SDP] This is strange since we have just reported as OTN works. 

[SDP] John, it seems as though , Lou has found the right description of the requirement in the mail of October 10th (15.12 CEST time). Anyway the TSG used to map an E2E ODUj onto a server LSP or links , it is not a matter of the ODUj LSP. You need to setup an ODUj with a certain rate, the fact this is carried along a path composed by links/FA structured with TS size of 2.5 or 1.25 is completely transparent to ODUj E2E. The only thing that ODUj E2E has to guarantee is the match between adaptation "on output" towards clients at the end points. But this is related to the TSG we have suggested to be contained in G-PID. Moreover the information of TS mapping on the server , can be obtained, by Signal Type in the Traffic Parameters, ODUk/FA interface from IF_ID RSVP_HOP object, and the field "length" in the label , indicating the number of TS used by client in the server . No need for further indication. 

[SDP]The answer is contained in the concept explained above. Anyway , we tried to have a common understanding on the model and needed information, before jumping in the solution (signaling object impacted).

---

From: John E Drake <[email-masked]>
Date: Wed, 12 Oct 2011 12:59:19 -0700

Snipped, comments inline

> 
> By this reasoning, it seems to me that we actually need the TSG in both
> the GPID and in the Signal Type, and they may be different.  I.e.,  the
> TSG in the GPID indicates, per your statement below, the TSG that the
> endpoints of an ODUk link or hierarchical LSP export to their clients,
> and the TSG in the Signal Type indicates, per your statement below, the
> TSG used to map an E2E ODUj onto the ODUk links or hierarchical LSPs on
> its path.
> 
> [SDP] John, it seems as though , Lou has found the right description of
> the requirement in the mail of October 10th (15.12 CEST time). Anyway
> the TSG used to map an E2E ODUj onto a server LSP or links , it is not
> a matter of the ODUj LSP. You need to setup an ODUj with a certain
> rate, the fact this is carried along a path composed by links/FA
> structured with TS size of 2.5 or 1.25 is completely transparent to
> ODUj E2E. The only thing that ODUj E2E has to guarantee is the match
> between adaptation "on output" towards clients at the end points. But
> this is related to the TSG we have suggested to be contained in G-PID.
> Moreover the information of TS mapping on the server , can be obtained,
> by Signal Type in the Traffic Parameters, ODUk/FA interface from IF_ID
> RSVP_HOP object, and the field "length" in the label , indicating the
> number of TS used by client in the server . No need for further
> indication.
> 
[JD] 

The above is quite clear and understandable.  However, it seems inconsistent with the text that caused my initial question, viz, if PT is really just something that needs to be presented consistently by a hierarchical LSP's endpoints to its clients, then why is a PT check being made on the links adjacent to that hierarchical LSP's endpoints?  

Btw, don't you think it would be better if we used PT rather than TSG and defined three values, 20, 21, and 20|21?

---

From: Zhangfatai <[email-masked]>
Date: Thu, 13 Oct 2011 09:24:16 +0000

Hi John,

I think your idea is worth investigating. 

In this way, we can make the TSG issue (Client to Server adaptation capability) generic, i.e. it is GPID stuff (as any other technologies, not only for OTN) . Furthermore, it will not make people confused by the TSG information.

Thanks
 
Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: 2011年10月13日 3:59
To: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG

Snipped, comments inline

[JD]

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 13 Oct 2011 12:25:52 +0200

Hi John,

 From your answer below:
[JD] 

[SBPG] Sorry John we're not sure what text you're referring to. Could you clarify a little your question . we would pleased to answer.
[JD]
Btw, don't you think it would be better if we used PT rather than TSG and defined three values, 20, 21, and 20|21?

[SBPG] John, your conclusion would be correct, this was exactly our original thought.
The problem here was that unfortunately G.709 present an "unlucky" case related to the multiplexing of an ODU0 into ODU1 in which PT=20 , but TSG=1.25 !!!
So, our reasoning was, since GPID defined in RFC 4328 has been defined not for G.709v3,to associate GPID=47 to the TSG=2.5 (before G.709V3 only this TSG was present), and to add a new GPID value for G.709v3 for TSG=1.25. In this way e.g. an H-LSP ODU1 , can signal GPID=new value , even if the PT carried in the MSI of OPU1 OH is 20.
Obviously this problem could also be solved associating to the GPID check the famous , already discussed with you, new "optional" object defining the client hierarchy supported by the server LSP. In this case there is no ambiguity for ODU1 , as soon as in the tree supported there is ODU0. TSG has to be 1.25 even if PT=20.

BR

Sergio, Pietro

-----Messaggio originale-----
Da: John E Drake [mailto:[email-masked]] 
Inviato: mercoledì 12 ottobre 2011 21.59
A: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; Lou Berger; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Daniele Ceccarelli
Oggetto: RE: [CCAMP] Thought on where to carry G.709-v3 TSG

Snipped, comments inline

[JD]

---

From: John E Drake <[email-masked]>
Date: Thu, 13 Oct 2011 06:44:20 -0700

Snipped, comments inline

> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-
> lucent.com]
> Sent: Thursday, October 13, 2011 6:26 AM
> To: John E Drake
> Subject: R: [CCAMP] Thought on where to carry G.709-v3 TSG
> 
> Hi John,
> 
>  From your answer below:
> [JD]
> 
> The above is quite clear and understandable.  However, it seems
> inconsistent with the text that caused my initial question, viz, if PT
> is really just something that needs to be presented consistently by a
> hierarchical LSP's endpoints to its clients, then why is a PT check
> being made on the links adjacent to that hierarchical LSP's endpoints?
> 
> [SBPG] Sorry John we're not sure what text you're referring to. Could
> you clarify a little your question . we would pleased to answer.
[JD] 

Here's the text that I found inconsistent:

"The payload has to be considered only when selecting the last interface/FA.  The last interface/FA must be selected in such a way to be able to support the signal type of the LSP being set up and, in addition, to grant that the LSP termination supports a 2.5/1.25 payload structure depending from the client payload requested by signaling."

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 13 Oct 2011 16:54:11 +0200

John,

Sincerely we do not catch inconsistency.
We need to match input ingress adaptation with adaptation on output. Not all the interfaces are able to support all the adaptations type (and then both the TSG), then is on the links adiacent to the end points that we need to select the proper interface to guarantee the match.

Hope this clarify 

Sergio and Pietro

SERGIO BELOTTI

ALCATEL-LUCENT
Terrestrial System Architect
Optics Portfolio Evolution

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

-----Messaggio originale-----
Da: John E Drake [mailto:[email-masked]] 
Inviato: giovedì 13 ottobre 2011 15.44
A: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; Lou Berger; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Daniele Ceccarelli
Oggetto: RE: [CCAMP] Thought on where to carry G.709-v3 TSG

Snipped, comments inline

[JD]

---

From: Lou Berger <[email-masked]>
Date: Thu, 13 Oct 2011 11:02:46 -0400

On 10/13/2011 10:54 AM, BELOTTI, SERGIO (SERGIO) wrote:
> We need to match input ingress adaptation with adaptation on output.
> Not all the interfaces are able to support all the adaptations type
> (and then both the TSG), then is on the links adiacent to the end
> points that we need to select the proper interface to guarantee the
> match.
> 

This is exactly one of things that LSP encoding was intended to support.

Lou

---

From: John E Drake <[email-masked]>
Date: Thu, 13 Oct 2011 10:28:06 -0700

Sergio and Pietro,

I'm sorry for being dense but you make a leap from discussing interfaces to links that I don't follow.  Why is it not sufficient to verify that the TSG of the two interfaces on which a hierarchical LSP terminates are the same?

Also, strictly speaking, links don't have attributes; only interfaces have attributes.

If the egress interface is associated with an unbundled link, the penultimate node doesn't have any choice in selecting the outgoing interface from itself.  If the egress interface is associated with a bundled link, it doesn't matter which component link the penultimate node chooses because bundled links are homogeneous wrt TSG.  

Thanks,

John

> Sent: Thursday, October 13, 2011 10:54 AM
> To: John E Drake
> Cc: CCAMP; Lou Berger; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO);
> Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO)
> "The payload has to be considered only when selecting the last
> interface/FA.  The last interface/FA must be selected in such a way to
> be able to support the signal type of the LSP being set up and, in
> structure depending from the client payload requested by signaling."

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 14 Oct 2011 12:07:40 +0200

Lou,

We tried just to explain why there is no inconsistency, without mention where to carry the needed information. Did you catch inconsistency in our explanation? 
see in line for further comments.

Thanks

Sergio and Pietro

-----Messaggio originale-----
Da: Lou Berger [mailto:[email-masked]] 
Inviato: giovedì 13 ottobre 2011 17.03
A: BELOTTI, SERGIO (SERGIO)
Cc: John E Drake; CCAMP; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Daniele Ceccarelli
Oggetto: Re: R: [CCAMP] Thought on where to carry G.709-v3 TSG

[ALU] Let us try to summarize what is needed against our understanding of the different options .

Is the LSP encoding "the nature of LSP" ? If yes, we expect that the LSP encoding carried in Generalized Label Request object, qualifies the LSP as an ODU G.709 LSP ( encoding value = 12 ).

Now, suppose to have two H-LSP ODU2 , carried over links OTU3.
For simplicity, let's assume that both of them are setup between the same end points, but one is characterized by adaptation towards client in the ingress with 1.25 TSG while the other is characterized by adaptation towards client in the ingress with 2.5 TSG.

In our view when these LSP have to be signaled, both of them have the same LSP nature: both are H-LSP ODU2, and the generalized Label Request carries the value 12 in the encoding field.

The difference between the two LSPs is not in their nature but is in something that is related to the support of different clients, so related to payload carried.

Let us know whether we missed something in the description.

Lou

>> Daniele Ceccarelli

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Mon, 17 Oct 2011 12:17:40 +0200

John,

Independently for the words used (links vs interfaces) it seems as though there is some fundamental misunderstanding.
As suggested by Lou, we are trying to write some text in the Info draft to clarify the point. We can send the text in preview to parse it before officially circulate in the mailing list. 

Thanks

Sergio, Daniele, Pietro

-----Messaggio originale-----
Da: John E Drake [mailto:[email-masked]] 
Inviato: giovedì 13 ottobre 2011 19.28
A: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; Lou Berger; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Daniele Ceccarelli
Oggetto: RE: [CCAMP] Thought on where to carry G.709-v3 TSG

Sergio and Pietro,

Thanks,

John