Subject: [CCAMP] (no subject)

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 10 May 2012 16:04:33 +0200

Lou,

see our comments in line, we hope to have reached a common understanding

AUTHORS

-----Messaggio originale-----
Da: Lou Berger [mailto:[email-masked]]
Inviato: domenica 6 maggio 2012 18.32
A: BELOTTI, SERGIO (SERGIO)
Cc: Daniele Ceccarelli; CCAMP; [email-masked]; Fatai Zhang
Oggetto: Re: R: R: [CCAMP] A couple of comments on draft-ietf-ccamp-gmpls-signaling-g709v3-02

Sergio, Authors,
            See below for in-line response.

On 5/3/2012 4:07 AM, BELOTTI, SERGIO (SERGIO) wrote:
> Lou,
>
> See in line marked AUTHORS and attached mail from which we extracted for your convenience a part on your thoughts regarding G-PID.
>
> Best Regards
>
> AUTHORS
>
>
> -----Messaggio originale-----
> Da: Lou Berger [mailto:[email-masked]]
> Inviato: venerdì 27 aprile 2012 14.19
> A: Fatai Zhang
> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; [email-masked]
> Oggetto: Re: R: [CCAMP] A couple of comments on draft-ietf-ccamp-gmpls-signaling-g709v3-02
>
> Fatai, Authors, see below.
>
>
> On 4/27/2012 2:36 AM, Fatai Zhang wrote:
>> Hi Lou,
>>
>> Please see in-line below.
>>
>> Thanks
>>
>> Fatai
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:[email-masked]]
>> Sent: 2012年4月24日 0:52
>> To: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
>> Cc: CCAMP; [email-masked]; Fatai
>> Zhang
>> Subject: Re: R: [CCAMP] A couple of comments on
>> draft-ietf-ccamp-gmpls-signaling-g709v3-02
>>
>> Sergio,
>>
>>          See below.
>>
>> On 4/19/2012 11:03 AM, BELOTTI, SERGIO (SERGIO) wrote:
>>
>>> Hi Lou,
>>> For question 1)
>>> TSG is an adaptation information that has meaning only in the context
>>> of OTN multiplexing. Nothing to do with G-PID that obviously has to
>>> carry information regarding client so, ODUj. Moreover TSG information
>>> could not be done with G-PID, because this TSG information only makes
>>> sense to the penultimate hop and G-PID cannot specify 1.25 or 2.5G so
>>> far. In this case,47 (ODUj) will be carried in G-PID.
>>
>> This could equally be accomplished using 2 G-PID values, e.g.,
>> 47=ODUj-2.5G TSG, 48-ODUj-1.25G ( or 3 if you also want one to indicate
>> either.)
>> BTW you might want to reread the definition of G-PID with respect to
>> penultimate hop.
>>
>> [Fatai] Your suggestion makes sense. I think either way is OK. We could
>> use 2 G-PID values if WG prefer to this way.
>>
>
>> If you're okay either way, why are you even leaving the door open for
>> defining a new mechanism to do what can already be done with an existing
>> mechanisms?  IMO, do so when there is no strong technical motivation is
>> simply wrong.
>
>> Do you (or anyone else) see any reason to justify not using the existing
> mechanism?
>
> AUTHORS> Lou, we attached a mail sent by you in September , during the long discussion, in which we proposed the usage of G-PID to carry TSG information and you had different opinion.
> During this long mails exchange , you suggested to use Encoding Type to carry TSG information. At the end, we , as authors, suggested to use a new object to be more open also to possible extension (like adaptation info).
>
> This is the story of this issue and this is why we did not fall again into G-PID option. What is changed ?
>

            Good question/catch.  As I recall the quoted discussion, it was focused
on the non-hierarchical LSP case and my comments were made in that
context.  My understanding from this current discussion is that the new
G-PID values would *only* be used in the hierarchy-case.

AUTHORS> Where to put information regarding TSG is valid both for non-hierarchical as well as for hierarchical.
So, discussion we had are valid now as before.

You may have also missed my comment on the list that was sent *after*
the mail that you attached:

AUTHORS> No ,we remember very well your preference for Encoding option.

On 10/25/2011 6:37 PM, Lou Berger wrote:
> 5) Note that the Encoding field may be impacted by the still unresolved
> discussion related to TSG/PT that took place a couple of weeks ago on
> the list.  (I'm personally leaning towards representing PT in encoding
> as this better matches what happens in the data plane and is more
> closely aligned to the general definition of the encoding field.)

Your question also triggered me to remember a key difference in how
this problem is often discussed and how G.709 represents it.  IMO GMPLS
modeling/support should match G.709 to the maximum extent possible, so
my example should have been in terms of Payload Type.  That is:
> 2 G-PID values, e.g., 47=ODUj-2.5G TSG, 48-ODUj-1.25G
should have been
2 G-PID values, e.g.,47=ODUj-AMP (G.709 PT=0x20), 48-ODUj-GMP (G.709
PT=0x20)

AUTHORS> Lou, obviously, as discussed time ago, G-PID can be used for this purpose even if , we concluded together it is not the best choice.

Our proposal to use a new object was also to avoid changing (or overloading) meaning of G-PID.
Said that nothing prevent to come back to G-PID.
You example above is anyway wrong : there is no ODUj GMP mapping with PT=20.
So you should have e.g.:

new  G-PID value = ODUj-AMP (PT=20 TSG=2.5)
new G-PID value  = ODUj-AMP (PT=20 TSG=1.25) (ODU0-->OPU1)
new G-PID value = ODUj-AMP (PT=21 TSG=1.25)
new G-PID value  = ODUj-GMP (PT=21 TSG=1.25)

Is it this solution preferable than a new object ?

[The following was inserted from the old thread]
> -----Original Message-----
>> From: Lou Berger [mailto:[email-masked]]
>> Sent: mercoledì 28 settembre 2011 17.37
>> To: BELOTTI, SERGIO (SERGIO)
>> Cc: CCAMP; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
>> Subject: Re: R: [CCAMP] Thought on where to carry G.709-v3 TSG
>>
>>
>> Sergio and Pietro,
>>
>> It sounds like we should get in-sync on where TSG information is
>> needed first then talk about how to carry it.  So, I said:
>>
>>> As I understand it, TSG is needed at:
>>>   (a) the endpoints that terminate the signal/LSP to ensure proper
>>>       adaptation.
>>>   (b) the 2nd and penultimate hops to ensure the proper
>>>       interface/H-LSP selection.
>>>   (c) Intermediate nodes for proper TS allocation.
>>>
>>
>> >From your mail, I infer that you agree on (a) and (b).  Is this correct?
>> [[ALU]] We agree on (a) and (b).
>
> Good.  To me, as I mentioned in my first mail on this thread, this means that G-PID isn't the right place to carry this information.
>
> On 9/27/2011 9:20 AM, Lou Berger wrote:
>     Option 1, G-PID, is really designed to support end-point client
>     adaptation, so as an end-point only field it really only supports
>     need (a), so I don't think G-PID is the right place to indicate TSG
>

[The above was inserted from the old thread, now back to the current thread]
>>>
>>> For question 2)
>>>
>>>
>>> Hierarchy information has been introduced to help penultimate hop
>>> (always in case ERO information are not exhaustive) choosing the
>>> right interface e.g. two interfaces supporting both the correct TSG
>>> but not the same client hierarchy. This added information is used to
>>> guarantee the possibility about the correct
>>> multiplexing/demultiplexing process.
>>>
>>> G-PID at the moment consider a number of codes that does not cover
>>> all the different “mapping” used for the same carried payload e.g.
>>> typical example is 10Gb Eth. So we added Swtiching Cap and Encoding
>>> information like the OTN layers + adaptation field , in order to
>>> better distinguish also the client OTN layer. Exploiting on the
>>> G-PID, can bring two problems:
>>>
>>>
>>> a)    We would need to add G-PID information inside the new Type new
>>> object , having a not-homogeneous  format with respect the other
>>> layers.
>>>
>>> b)    As said before, it wouldn’t be exhaustive with respect real
>>> mapping beyond the same payload.
>>
>> I'm sorry, I don't understand how this answers the following:
>>
>>>> So what does it mean in a type 2 TLV to have a "non OTN signal types"
>>>> and GFP mappings?  It seems that these both cover cases beyond ODU
>>>> H-LSPs, am I wrong?
>>
>> [Fatai] What did you mean by saying “non OTN signal types”?
>
> Values mapping to anything but PT=20 or PT=21.
>
>> Did you mean
>> removing “Switching Type” & “Encoding Type”?
>
> No. What I'm really trying to understand is why the mapping field just
> doesn't carry Payload Type as defined in G.709.
>
> An earlier response, as I understood it, said that G-PID will carry
> client payload types and that mapping is used to indicate intra-ODU
> information.  This led to me asking about the GFP (-F and -T) mapping
> values.
>
>> For mapping, there are
>> different encapsulation protocols when ODUj multiplexes into ODUk, it
>> may need to specify this information when an FA-LSP is to be created.
>>
>
> So clearly there is some misunderstanding here.  Probably mine.  So the
> field in question is the mapping field of the Hierarchy TLV which has
> the following definition:
>
>       Mapping: This field indicates the mapping function used in each
>       client-server relationship of the hierarchy. The values of this
>       field are listed below:
>
>            Value          Type
>           -----         ------
>             0            Reserved
>              1            AMP
>              2            BMP
>              3            GMP
>              4            GFP-F
>              5            GFP-T
>            6-255          Reserved
>
> So my first point (why not just carry PT values) comes from the
> narrative.  If this field is just for intra-ODU mappings, then "each
> client-server relationship" should be replaced with "each ODU mapping
> relationship".
>
> In looking at G.709 is see that *only* AMP and GMP are used to support
> ODUj -> ODUk multiplexing.  So this lead me to the question about GFP.
>
> Your mail has triggered my taking yet another look at G.709, I see that
> BMP is used in supporting CBR clients, GFP-T is only mentioned as
> supporting 1000BASE-X, and GFP-F can support multiple (packet) client
> types.
>
> I don't see where BMP or GFP (-F and -T) are used when "ODUj multiplexes
> into ODUk".  What am I missing something?  Please be specific in your
> references to the appropriate ITU-T documents so that we can close on this.
>
> It seems to me that mapping needs to carry all possible payload type
> values so that the g-pid of the outermost ODU LSP can indicate the type
> of traffic being carried (e.g., MPLS, IP, ethernet, STM-64, etc.), but
> your position leads me to believe that I'm missing something here too.
> To clarify, for the example of an ODU LSP that carries Ethernet over
> GFP-F (over some ODUk), what would be the G-PID and Hierarchy TLV?
>
> AUTHORS> Lou, where from the narrative above describing the "mapping"
> field is said that we refer to "intra-ODU mappings" ? The meaning of
> this field is to give information about not what is "the carried
> payload" already contained in the G-PID but "how" this payload is
> carried .

How which payload is carried?  so G-PID, encoding and the other
parameters of an LSP relate to the layer of the hierarchy represented by
the LSP.

It was my understanding that the purpose of the ADAPTATION Object (at
least for the type 2 TLV) was to represent the N (where N>1) layers of
the hierarchy *above* the LSP being signaled.

Is this correct or am I mistaken?

AUTHORS> Yes, your understanding is correct, information regarding hierarchy "supported" by the signaled LSP
<deleted the rest>

---

From: Lou Berger <[email-masked]>
Date: Tue, 15 May 2012 07:34:23 -0400

Sergio/Fatai/Authors,

interesting formatting....

> see our comments in line, we hope to have reached a common understanding
Perhaps.  Let me try to take one step back:

Do I understand correctly from you mail that you hold the following
positions:

1) the ADAPTATION Object only represents the N (where N>1) layers of the
hierarchy *above* the LSP being signaled.

and

2) It is acceptable to use standard GMPLS fields to represent/signal an
ODU LSP as well as the payload type it carries (i.e., which may be +1 in
an ODU hierarchy or a client signal).

If this correct, than I agree we're closer to a common understanding.

Thanks,
Lou

> Cc: Daniele Ceccarelli; CCAMP;
> [email-masked]; Fatai Zhang
> 
> Oggetto: Re: R: R: [CCAMP] A couple of comments on
>> See in line marked AUTHORS and attached mail from which we extracted
> for your convenience a part on your thoughts regarding G-PID.
> 
>>
> 
>> Best Regards
> 
>>
> 
>> AUTHORS
> 
>>
> 
>> 
> 
>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;
> [email-masked]
> 
>> Oggetto: Re: R: [CCAMP] A couple of comments on
>> AUTHORS> Lou, we attached a mail sent by you in September , during the
> long discussion, in which we proposed the usage of G-PID to carry TSG
> information and you had different opinion.
> 
>> During this long mails exchange , you suggested to use Encoding Type to
> carry TSG information. At the end, we , as authors, suggested to use a
> new object to be more open also to possible extension (like adaptation
> info).
> 
>>
> 
> AUTHORS> Where to put information regarding TSG is valid both for
> non-hierarchical as well as for hierarchical.
> 
> AUTHORS> Lou, obviously, as discussed time ago, G-PID can be used for
> this purpose even if , we concluded together it is not the best choice.
> 
>  
> 
>> Good.  To me, as I mentioned in my first mail on this thread, this
> means that G-PID isn't the right place to carry this information.
> 
>>
> 
> AUTHORS> Yes, your understanding is correct, information regarding
> hierarchy "supported" by the signaled LSP
> 
> <deleted the rest>
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 24 May 2012 15:25:41 +0200

Hi Lou,

Just to change Author at each reply :-)

Please find answers inline with respect to adaptation object type 2 (hierarchy), while could you please answer the following question wrt adaptation object type 1?

>> Is it this solution preferable than a new object ?

BR
Authors

>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Lou Berger
>Sent: martedì 15 maggio 2012 13.34
>Cc: CCAMP; [email-masked]
>Subject: Re: [CCAMP] comment on
>draft-ietf-ccamp-gmpls-g709-framework-06
>
>
>Sergio/Fatai/Authors,
>
>1) the ADAPTATION Object only represents the N (where N>1)
>layers of the hierarchy *above* the LSP being signaled.
>

AUTHORS> Quoting the draft:
   A row for the server stage MUST NOT be included as it is already
   signaled via the Traffic Parameters.
So bullet 1) is correct if you say "...N (where N>0) layers of the herarchy *above*..." because in the case of e.g. dual stage muxing, the N layers above the LSP being signaled (server layer) are equal to 1 (N>1 is not correct).

>and
>
>2) It is acceptable to use standard GMPLS fields to
>represent/signal an ODU LSP as well as the payload type it
>carries (i.e., which may be +1 in an ODU hierarchy or a client signal).
>

AUTHORS>
Let's take this hierarchy as example: Eth->ODU2->ODU3->ODU4

-Eth is already managed via G-PID
-ODU4 is already managed via traffic parametes
-ODU2 and ODU3 is what we want to deal with via the ADAPTATION Object.

From your summary we understand that it is actually possible to manage the Eth, ODU3 and ODU4 layers while there is only need to add something (e.g. ADAPTATION obeject) for the ODU2. Is this correct? If yes, how?

>>>>> sense to the penultimate hop and G-PID cannot specify
>1.25 or 2.5G
>>>>> so
>>
>>>> mechanisms?  IMO, do so when there is no strong technical
>motivation
>>>> is
>>
>>>> simply wrong.
>>
>>>
>>
>>> AUTHORS> Lou, we attached a mail sent by you in September , during
>>> AUTHORS> the
>>> During this long mails exchange , you suggested to use
>Encoding Type
>>> to
>>> This is the story of this issue and this is why we did not
>fall again
>> into G-PID option. What is changed ?
>>
>>>
>>
>>
>>
>> parameters of an LSP relate to the layer of the hierarchy
>represented
>> by
>>
>> the LSP.
>>
>>
>>

---

From: Lou Berger <[email-masked]>
Date: Thu, 24 May 2012 10:06:44 -0400

Daniele,
	Given the number of authors involved in the thread and us clearly not
quickly converging, perhaps it's time for a higher bandwidth exchange.
I propose that we setup a conference call to discuss and report back our
conclusion to the list.  I'll contact the authors off-list to coordinate
(if anyone else wants to join the phone call, just drop me or the
authors mail.)

Lou