Subject: [CCAMP] G.709 signaling - encoding Type

From: Rajan Rao <[email-masked]>
Date: Wed, 13 Mar 2013 13:40:18 +0000

Daniele,

The presentation slide#3 says:  "encoding type indicates AMP or GMP".   I don't think this is the case.  We use  G.709 ODUk as encoding type.  There is no explicit indication of AMP or GMP there.  Are you proposing to change this?

Note that AMP/GMP can be inferred from Signal Type in traffic param & Length field ( = 8) in the label.

Thanks
Rajan

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 13 Mar 2013 13:52:50 +0000

Rao,

it is a proposal: so you should read:  "encoding type can indicate...

Regards
Sergio

Belotti Sergio-  System Architect
ALCATE-LUCENT  Optics Division
via Trento 30 Vimercate (MB) - Italy
phone +39 (039) 6863033
________________________________
Da: [email-masked] [mailto:[email-masked]] Per conto di Rajan Rao
Inviato: mercoledì 13 marzo 2013 14.40
A: CCAMP ([email-masked])
Oggetto: [CCAMP] G.709 signaling - encoding Type

Daniele,

Thanks
Rajan

---

From: John E Drake <[email-masked]>
Date: Wed, 13 Mar 2013 22:16:46 +0000

Hi,

I don't think this is a good idea and I don't see any reason for it.

Irrespectively Yours,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Wednesday, March 13, 2013 6:53 AM
To: Rajan Rao
Cc: CCAMP ([email-masked])
Subject: [CCAMP] R: G.709 signaling - encoding Type

Rao,

Regards
Sergio

Belotti Sergio-  System Architect
ALCATE-LUCENT  Optics Division
via Trento 30 Vimercate (MB) - Italy
phone +39 (039) 6863033
________________________________
Da: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Per conto di Rajan Rao
Inviato: mercoledì 13 marzo 2013 14.40
A: CCAMP ([email-masked]<mailto:[email-masked]>)
Oggetto: [CCAMP] G.709 signaling - encoding Type

Daniele,

Thanks
Rajan

---

From: Lou Berger <[email-masked]>
Date: Wed, 13 Mar 2013 18:26:55 -0400

John,

Do you have an alternate proposal on how to address the issue, or do 
you just see an issue?

(If the former, the onus will fall on you to provide one.  If the 
latter, it'll fall to Sergio And Danielle to recap the presented issue.)

Lou

On March 13, 2013 6:16:46 PM John E Drake <[email-masked]> wrote:
> Da: [email-masked]<mailto:[email-masked]> 
> [mailto:[email-masked]] Per conto di Rajan Rao
> The presentation slide#3 says:  "encoding type indicates AMP or GMP".   
> I don't think this is the case.  We use  G.709 ODUk as encoding type.  
> There is no explicit indication of AMP or GMP there.  Are you proposing 
> to change this?
>

---

From: John E Drake <[email-masked]>
Date: Wed, 13 Mar 2013 22:40:08 +0000

Lou,

I must have been asleep but I don’t remember hearing of an issue.  It was my understanding that AMP and GMP both use G.709 encoding in the data plane, so why would we want to make what appears to be an artificial distinction?

Irrespectively Yours,

John

From: Lou Berger [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 3:27 PM
To: John E Drake; BELOTTI, SERGIO (SERGIO); Rajan Rao
Cc: CCAMP ([email-masked]); Daniele Ceccarelli
Subject: Re: [CCAMP] G.709 signaling - encoding Type

John,

Do you have an alternate proposal on how to address the issue, or do you just see an issue?

(If the former, the onus will fall on you to provide one. If the latter, it'll fall to Sergio And Danielle to recap the presented issue.)

Lou

On March 13, 2013 6:16:46 PM John E Drake wrote:
Hi,

I don’t think this is a good idea and I don’t see any reason for it.

Irrespectively Yours,

John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Wednesday, March 13, 2013 6:53 AM
To: Rajan Rao
Cc: CCAMP ([email-masked]<mailto:[email-masked]>)
Subject: [CCAMP] R: G.709 signaling - encoding Type

Rao,

it is a proposal: so you should read:  “encoding type can indicate…

Regards
Sergio

Daniele,

The presentation slide#3 says:  “encoding type indicates AMP or GMP”.   I don’t think this is the case.  We use  G.709 ODUk as encoding type.  There is no explicit indication of AMP or GMP there.  Are you proposing to change this?

Thanks
Rajan

---

From: Lou Berger <[email-masked]>
Date: Wed, 13 Mar 2013 18:54:29 -0400

John,

See below.

On 3/13/2013 6:40 PM, John E Drake wrote:
> Lou,
> 
>  
> 
> I must have been asleep but I don’t remember hearing of an issue.

No problem, looked like a few others had some trouble getting moving
this AM too.

>  It
> was my understanding that AMP and GMP both use G.709 encoding in the
> data plane, so why would we want to make what appears to be an
> artificial distinction?  

This was covered on slide 3 of Danielle's presentation.  He/They can
provide additional details/justification.

Lou

> 
>  
> 
> Irrespectively Yours,
> 
>  
> 
> John
> 
>  
> 
> *From:*Lou Berger [mailto:[email-masked]]
> *Sent:* Wednesday, March 13, 2013 3:27 PM
> *To:* John E Drake; BELOTTI, SERGIO (SERGIO); Rajan Rao
> *Cc:* CCAMP ([email-masked]); Daniele Ceccarelli
> *Subject:* Re: [CCAMP] G.709 signaling - encoding Type
> 
>  
> 
> John,
> 
> (If the former, the onus will fall on you to provide one. If the latter,
> it'll fall to Sergio And Danielle to recap the presented issue.)
> 
> Lou
> 
>  
> 
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] *On Behalf Of *BELOTTI, SERGIO (SERGIO)
>     *Sent:* Wednesday, March 13, 2013 6:53 AM
>     *To:* Rajan Rao
>     *Cc:* CCAMP ([email-masked] <mailto:[email-masked]>)
>     *Subject:* [CCAMP] R: G.709 signaling - encoding Type
> 
>      
> 
>     Rao,
> 
>      
> 
>     *Belotti Sergio-  System Architect*
> 
>     *ALCATE-LUCENT  Optics Division*
> 
>     ------------------------------------------------------------------------
> 
>     *Da:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] *Per conto di *Rajan Rao
>     *Inviato:* mercoledì 13 marzo 2013 14.40
>     *A:* CCAMP ([email-masked] <mailto:[email-masked]>)
>     *Oggetto:* [CCAMP] G.709 signaling - encoding Type
> 
>      
> 
>     Daniele,
> 
>      
> 
>     The presentation slide#3 says:  “encoding type indicates AMP or
>     GMP”.   I don’t think this is the case.  We use  G.709 ODUk as
>     encoding type.  There is no explicit indication of AMP or GMP
>     there.  Are you proposing to change this?
> 
>      
>

---

From: Rajan Rao <[email-masked]>
Date: Wed, 13 Mar 2013 23:50:34 +0000

Lou,

The new encoding has implications in routing(new ISCDs).  I think we can minimize the impact using the two fields mentioned in my email below.   To be specific,

For the case highlighted in the slide,  the Encoding is AMP when
Signal Type = ODU1  in traffic spec
Length Field  = 8 in  Label 

Thanks
Rajan
-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, March 13, 2013 6:54 PM
To: John E Drake
Cc: BELOTTI, SERGIO (SERGIO); Rajan Rao; CCAMP ([email-masked]); Daniele Ceccarelli
Subject: Re: [CCAMP] G.709 signaling - encoding Type

John,

See below.

> I must have been asleep but I don’t remember hearing of an issue.

No problem, looked like a few others had some trouble getting moving this AM too.

> data plane, so why would we want to make what appears to be an 

This was covered on slide 3 of Danielle's presentation.  He/They can provide additional details/justification.

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 14 Mar 2013 18:41:30 +0000

Using the encoding was one of the possible suggestions.

Indeed it has impacts on the routing and it might be worth avoiding it, but another solution is preferrable wrt relying on the Label Length (which might change for several reasons). I would prefer not to put a requirement on the Label lenght only because it is needed to retrieve the adaptation type.

Other proposals are welcome. I had a chat with John this morning and he was proposing the utilization of a new field (even a single bit). That could be a viale option for me. Since we're removing the Tolerance from the traffic parameters we're going to have room for a new field.

BR
Daniele

>From: Rajan Rao [mailto:[email-masked]] 
>Sent: mercoledì 13 marzo 2013 19.51
>To: Lou Berger; John E Drake
>Cc: BELOTTI, SERGIO (SERGIO); CCAMP ([email-masked]); Daniele 
>Ceccarelli
>Subject: RE: [CCAMP] G.709 signaling - encoding Type
>
>Lou,
>
>The new encoding has implications in routing(new ISCDs).  I 
>think we can minimize the impact using the two fields 
>mentioned in my email below.   To be specific,
>
>For the case highlighted in the slide,  the Encoding is AMP 
>when Signal Type = ODU1  in traffic spec Length Field  = 8 in  Label 
>
>Thanks
>Rajan
>> I must have been asleep but I don't remember hearing of an issue.
>
>This was covered on slide 3 of Danielle's presentation.  
>He/They can provide additional details/justification.
>
>Lou
>
>> 
>>  
>> 
>> Irrespectively Yours,
>> 
>>  
>> 
>> John
>> 
>>  
>> 
>>     it is a proposal: so you should read:  "encoding type can 
>> indicate.
>> 
>>      
>> 
>>     Regards
>> 
>>     Sergio
>> 
>>      
>> 
>>     The presentation slide#3 says:  "encoding type indicates AMP or
>>     GMP".   I don't think this is the case.  We use  G.709 ODUk as
>>     Note that AMP/GMP can be inferred from Signal Type in 
>traffic param
>>     & Length field ( = 8) in the label.
>> 
>>      
>> 
>>     Thanks
>>     Rajan
>> 
>

---

From: Rajan Rao <[email-masked]>
Date: Thu, 14 Mar 2013 18:47:03 +0000

G-PID perhaps?

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Thursday, March 14, 2013 2:42 PM
To: Rajan Rao; Lou Berger; John E Drake
Cc: BELOTTI, SERGIO (SERGIO); CCAMP ([email-masked])
Subject: RE: [CCAMP] G.709 signaling - encoding Type

BR
Daniele

>The new encoding has implications in routing(new ISCDs).  I think we 
>can minimize the impact using the two fields
>For the case highlighted in the slide,  the Encoding is AMP when Signal 
>Type = ODU1  in traffic spec Length Field  = 8 in  Label
>
>Thanks
>Rajan

---

From: Lou Berger <[email-masked]>
Date: Thu, 14 Mar 2013 14:57:54 -0400

Daniele, (Sergio?)

Can you summarize the data plane behavior/requirement that is the basis
for the change?  i.e., provide the reason why *any* change is required.

Once we all understand the data plane requirements/constraints, we can
better decide which (hopefully existing) GMPLS mechanism is best suited
to support the requirement.

Thank you,
Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 14 Mar 2013 18:58:28 +0000

Not enough, in case of ODUk/ODUj mapping it is needed not only at the end point but also at the intermediate ones. 

>Sent: giovedì 14 marzo 2013 14.47
>To: Daniele Ceccarelli; Lou Berger; John E Drake
>Indeed it has impacts on the routing and it might be worth 
>avoiding it, but another solution is preferrable wrt relying 
>on the Label Length (which might change for several reasons). 
>I would prefer not to put a requirement on the Label lenght 
>only because it is needed to retrieve the adaptation type.
>
>Other proposals are welcome. I had a chat with John this 
>morning and he was proposing the utilization of a new field 
>(even a single bit). That could be a viale option for me. 
>Since we're removing the Tolerance from the traffic parameters 
>we're going to have room for a new field.
>
>BR
>Daniele
>
>when Signal

---

From: Rajan Rao <[email-masked]>
Date: Thu, 14 Mar 2013 19:55:11 +0000

Agree, the mapping can change at every hop & we should allow it. 
We will wait for use case clarification from Sergio.

Thanks
Rajan

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Thursday, March 14, 2013 2:58 PM
To: Rajan Rao; Lou Berger; John E Drake
Cc: BELOTTI, SERGIO (SERGIO); CCAMP ([email-masked])
Subject: RE: [CCAMP] G.709 signaling - encoding Type

>Indeed it has impacts on the routing and it might be worth avoiding it, 
>but another solution is preferrable wrt relying on the Label Length 
>(which might change for several reasons).
>I would prefer not to put a requirement on the Label lenght only 
>because it is needed to retrieve the adaptation type.
>
>Other proposals are welcome. I had a chat with John this morning and he 
>was proposing the utilization of a new field (even a single bit). That 
>could be a viale option for me.
>Since we're removing the Tolerance from the traffic parameters we're 
>going to have room for a new field.
>
>BR
>Daniele
>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 15 Mar 2013 10:05:54 +0000

The requirement comes form discussion had last week related to tolerance .
We discovered from ITU experts, there is an attribute related to the adaptation function in case of multiplexing of ODUj into ODUk, 

 oduTypeAndRate that configures the mapping method (AMP, GMP).

Now , since obviously equipment cannot know whether configuration is provided via management or control plane , conclusion was that control plane should have an equivalent of this attribute in order to be able to configure the right adaptation.

On the other hand this discussion is not new , since many time we discussed the opportunity to have dedicated object/fields to explicit adaptation information , at the moment not present in GMPLS.

This is a summery of requirement.

Thanks
Sergio

-----Messaggio originale-----
Da: Lou Berger [mailto:[email-masked]] 
Inviato: giovedì 14 marzo 2013 19.58
A: Daniele Ceccarelli
Cc: Rajan Rao; John E Drake; BELOTTI, SERGIO (SERGIO); CCAMP ([email-masked])
Oggetto: Re: [CCAMP] G.709 signaling - encoding Type

Daniele, (Sergio?)

Thank you,
Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 15 Mar 2013 07:01:50 -0400

Sergio,
	Thank you for clarifying the requirement. I believe you are describing
an issue that is a little different than what I understood from some
earlier discussions.  Perhaps others were also in the same situation.

As I now understand it, the issue that is being raised is one related to
ODUj LSPs that use an ODUk H-LSP as a hop, there is a need at all hops,
including at *transit nodes*, to configure the mapping method (AMP, GMP)
used from the ODUj onto the ODUk H-LSP.  This of course means that the
mapping function needs to be set on a hop by hop basis for the ODUj LSP.
 (I though an issue on and ODUk H-LSP was being raised.)

Or in other words there is an issue of per-hop resource
allocation/management.

Per the presented slide and Table 7-10 of G.709, the mapping method/type
is unique per combination of {ODUj, ODUk, TSG}.  Obviously any hop
signaling an ODUj LSP will know and unambiguously be able to identify
(in signaling) the ODUj and ODUk.  This just leaves the TSG.

Section 6.1 of the signalling draft already has text covering TSG as
part of the per-hop label. So TSG is also already being signaled
unambiguously.

It looks to me that all that is needed is a sentence or two stating that
the mapping type is unambiguously based on the above.

Please let me know if I missed something.

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 20 Mar 2013 09:27:42 +0000

Hi Lou,

I agree on your conclusion, which I have pointed out one or two years ago when we discussed if it needs mapping information.

I think some people may forgot this. 
=========================================================================================
Per the presented slide and Table 7-10 of G.709, the mapping method/type is unique per combination of {ODUj, ODUk, TSG}.

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Friday, March 15, 2013 7:02 PM
To: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP ([email-masked])
Subject: Re: [CCAMP] R: G.709 signaling - encoding Type

Sergio,

Lou

>>>>     & Length field ( = 8) in the label.
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Wed, 20 Mar 2013 09:52:31 -0400

Great.  Will you propose/add some related text so we don't need to
revisit this again?

Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 20 Mar 2013 14:04:24 +0000

Hi Lou,Fatai

In my summary you are reffering to I said:

">> On the other hand this discussion is not new , since many time we discussed the opportunity to have dedicated object/fields to explicit adaptation information , at the moment not present in GMPLS."

It is recognized by everybody that we can retrieve information regarding mapping by the triple you indicated.
The discussion is if it is the case to consider the opportunity to make explicit (in the label? ) the adaptation information . 
The fact that now with TSG we are able to understand the present mapping adopted in OTN, cannot assure in the future that for any possible extension regarding adaptation this triple can not be sufficient.

Since I'm one of the author but I'm not alone ..I cannot decide for everybody but just warn about. 

Best Regards

Sergio 

-----Messaggio originale-----
Da: Lou Berger [mailto:[email-masked]] 
Inviato: mercoledì 20 marzo 2013 14.53
A: Fatai Zhang
Cc: BELOTTI, SERGIO (SERGIO); CCAMP ([email-masked])
Oggetto: Re: [CCAMP] R: G.709 signaling - encoding Type

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 20 Mar 2013 12:47:04 -0400

Sergio,
	Thank you for clarifying why you/Daniele raised this topic.  My
preference/recommendation would be to not make any change.  I have
multiple reasons for this, primarily:

1) TSG is already unambiguous, although it is true that it must be
   derived.  Adding a second field that carries it explicit allows for
   inconsistencies and therefore adds error cases that must be detected
   and handled.

2) I'm not a big fan of guessing what the future holds.  I do agree
   that we can't preclude what might happen, and need to be supported,
   but I don't see a lot of value in defining mechanisms today that
   aren't needed today and might just be useful in the future.  In this
   particular example, if this ever really becomes an issue, we can
   just define a new label format.

3) We've had this discussion at least once before and agreed to the
   current approach.  Revising past decisions is fine if there's good
   cause, such as new information or issues identified/discovered, but
   this doesn't seem to apply in this case.

This said, I think we all would prefer to not prematurely limit
discussion on this, but also don't want to drag this on too long.

So it's really important that if there is anyone who supports making a
change, that they should speak up and state their justification for the
change (and soon)...

Thanks,
Lou

On 3/20/2013 10:04 AM, BELOTTI, SERGIO (SERGIO) wrote:
> It is recognized by everybody that we can retrieve information
> regarding mapping by the triple you indicated. The discussion is if
> it is the case to consider the opportunity to make explicit (in the
> label? ) the adaptation information . The fact that now with TSG we
> are able to understand the present mapping adopted in OTN, cannot
> assure in the future that for any possible extension regarding
> adaptation this triple can not be sufficient.
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 21 Mar 2013 02:25:13 +0000

Hi:

Yes, I agree with John/ Rajan; overloading encoding type is not a good idea.

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 13, 2013 6:16 PM
To: "BELOTTI, SERGIO (SERGIO)" <[email-masked]<mailto:[email-masked]>>, Rajan Rao <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] G.709 signaling - encoding Type

Hi,

Irrespectively Yours,

John

Rao,

Regards
Sergio

Da:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Per conto di Rajan Rao

Daniele,

Thanks
Rajan

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 21 Mar 2013 13:34:40 +0000

Lou,

OK. No changes to signaling re explicit indication of mapping and/or TSG in the label.

Trying to summarize, please correct me if i'm missing something.

- Framework: no changes
- Info: no changes
- Signaling: i) GPID list check and ii) add a note on G.709 HEX values vs GPID DEC values
- Routing: new version needed to address the latest last call comments but no other change needed

BR
Daniele

>Sent: mercoledì 20 marzo 2013 17.47
>Cc: Fatai Zhang; CCAMP ([email-masked]); Daniele Ceccarelli
>Subject: Re: R: [CCAMP] R: G.709 signaling - encoding Type
>
>Sergio,
>	Thank you for clarifying why you/Daniele raised this 
>topic.  My preference/recommendation would be to not make any 
>change.  I have multiple reasons for this, primarily:
>
>This said, I think we all would prefer to not prematurely 
>limit discussion on this, but also don't want to drag this on too long.
>
>So it's really important that if there is anyone who supports 
>making a change, that they should speak up and state their 
>justification for the change (and soon)...
>
>Thanks,
>Lou
>
>> ">> On the other hand this discussion is not new , since 
>many time we discussed the opportunity to have dedicated 
>object/fields to explicit adaptation information , at the 
>moment not present in GMPLS."
>> 
>> regarding mapping by the triple you indicated. The 
>discussion is if it 
>> is the case to consider the opportunity to make explicit (in the 
>>> I agree on your conclusion, which I have pointed out one or 
>two years ago when we discussed if it needs mapping information.
>>>
>=====================================================================
>>> ==================== Per the presented slide and Table 7-10 
>of G.709, 
>>> the mapping method/type is unique per combination of {ODUj, 
>ODUk, TSG}.
>>>
>>>
>>>
>>>
>>> Best Regards
>>>
>>> Fatai
>>>
>>>
>>> 	Thank you for clarifying the requirement. I believe you are 
>>> describing an issue that is a little different than what I 
>understood 
>>> from some earlier discussions.  Perhaps others were also in 
>the same situation.
>>>
>>> As I now understand it, the issue that is being raised is 
>one related 
>>> to ODUj LSPs that use an ODUk H-LSP as a hop, there is a 
>need at all 
>>> hops, including at *transit nodes*, to configure the mapping method 
>>> (AMP, GMP) used from the ODUj onto the ODUk H-LSP.  This of course 
>>> means that the mapping function needs to be set on a hop by 
>hop basis for the ODUj LSP.
>>> Per the presented slide and Table 7-10 of G.709, the mapping 
>>> method/type is unique per combination of {ODUj, ODUk, TSG}.  
>>> Obviously any hop signaling an ODUj LSP will know and unambiguously 
>>> be able to identify (in signaling) the ODUj and ODUk.  This 
>just leaves the TSG.
>>>
>>> It looks to me that all that is needed is a sentence or two stating 
>>> that the mapping type is unambiguously based on the above.
>>>
>>>> We discovered from ITU experts, there is an attribute 
>related to the 
>>>> adaptation function in case of multiplexing of ODUj into ODUk,
>>>>
>>>> Now , since obviously equipment cannot know whether 
>configuration is provided via management or control plane , 
>conclusion was that control plane should have an equivalent of 
>this attribute in order to be able to configure the right adaptation.
>>>>
>>>> On the other hand this discussion is not new , since many 
>time we discussed the opportunity to have dedicated 
>object/fields to explicit adaptation information , at the 
>moment not present in GMPLS.
>>>>
>>>> via Trento 30 Vimercate (MB) - Italy phone +39 (039) 6863033 
>>>> Can you summarize the data plane behavior/requirement that is the 
>>>> basis for the change?  i.e., provide the reason why *any* 
>change is required.
>>>>
>>>> Once we all understand the data plane requirements/constraints, we 
>>>> can better decide which (hopefully existing) GMPLS 
>mechanism is best 
>>>> suited to support the requirement.
>>>>
>>>> Thank you,
>>>> Lou
>>>>
>>>>> Indeed it has impacts on the routing and it might be 
>worth avoiding it, but another solution is preferrable wrt 
>relying on the Label Length (which might change for several 
>reasons). I would prefer not to put a requirement on the Label 
>lenght only because it is needed to retrieve the adaptation type.
>>>>>
>>>>>> The new encoding has implications in routing(new ISCDs). 
> I think 
>>>>>> we can minimize the impact using the two fields
>>>>>> Signal Type = ODU1  in traffic spec Length Field  = 8 in  Label
>>>>>>
>>>>>> Thanks
>>>>>> Rajan
>>>>>>> was my understanding that AMP and GMP both use G.709 
>encoding in 
>>>>>>> the data plane, so why would we want to make what appears to be 
>>>>>>> an artificial distinction?
>>>>>>
>>>>>>> Do you have an alternate proposal on how to address the 
>issue, or 
>>>>>>> do you just see an issue?
>>>>>>>
>------------------------------------------------------------------
>>>>>> ----
>>>>>>> --
>>>>>>>

---

From: Lou Berger <[email-masked]>
Date: Thu, 21 Mar 2013 09:51:40 -0400

Daniele,

	See below for one addition:
> OK. No changes to signaling re explicit indication of mapping and/or TSG in the label.

I think it would be a good idea to add a comment on this in the
signaling document so that we don't have to revisit it yet again...

Lou

---

From: "Gruman, Fred" <[email-masked]>
Date: Fri, 22 Mar 2013 19:10:04 +0000

Hi Daniele,

I'm looking through the examples in Section 5.2 and have the following comments regarding the setting of TSG:

1) Example Fig 8.  This example has ODU1 -> ODU2 -> ODU3

I do not think the ODU1 TSG should be 1 (1.25/2.5G) since this ODU1 is not being advertised to support ODU0.  In this case, I think TSG=0 (Ignored).

2) Section 5.2.1, Fig 9. This example has ODU1 -> ODU2 -> ODU3.

This example doesn't show the advertisement of all ODU rates. Because of this, I would recommend changing the Sig Type = ODU2 instead of ODU1 in both SCSIs in Fig 9.  The reason is that it is the ODU2 (and perhaps the ODU3)  that would support the different TSG values depending on [RFC 4328] vs G.709-2012 with fallback disabled.

3) Section 5.5, Figure 13.

I believe the first Sig type=ODU2 (where #stages=1, stages=ODU4) should have the TSG = either 1 or 3.

Note that this example is not consistent in populating the TSG fields for all ODU rates. I would recommend explicitly showing the TSG values for all ODU rates as this provides useful information.

Best Regards,
Fred