Subject: [CCAMP] R: R: A couple of comments on draft-ietf-ccamp-gmpls-signaling-g709v3-02

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 3 May 2012 10:07:39 +0200

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 ?

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

>>
>> 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 . 
This information is needed both for intra-ODU mapping case and inter-mapping case, since this info is not present in any of the actual GMPLS field TLV.

value 54       Ethernet MAC (framed GFP)        G.709 ODUk 

but we have more that one "mapping" e.g. of the same payload 10GbE into ODU2  

G.7041 and G.709, defines respectively:

10GbE --> GFP-F (G.7041, Table 6-3: UPI=0x13  [ Frame-mapped 64B/66B encoded Ethernet, including the Ethernet frame preamble ])

10GbE--> extended OPU2/ODU2 (G.709, Table 15-8: PT=0x09 [ GFP mapping 
10GbE--> into Extended
OPU2 payload, see clause 17.4.1 ])

Please not that this is not the mapping using UPI=0x01 and PT=0x05

To solve this issue there are three possibilities:

a) Adding new G-PID values to be able to distinguish different mapping --> clearly overloading the G-PID meaning 

b) Update the LSP encoding type supporting for example these PID's.

Actually, LSP Encoding Type per RFC 4328 include the following values:

        Value           Type
        -----           ----
        12             G.709 ODUk (Digital Path)
        13             G.709 Optical Channel

you may thus need a new value for the Type G.709 ODUke (Digital Path) as mapping for 10 GbE extended ODD mode.

54       Ethernet MAC (framed GFP)        G.709 ODUk, ODUke (and SDH)
55       Ethernet PHY (transparent GFP)   G.709 ODUk, ODUke (and SDH)

c) Introduce a new TLV specifically for ADAPTATION information.

As said during past months, our preference was for a new object, maintaining compatibility with the meaning of already defined TLV fields and providing a more cleaner solution.

Last, to answer your question , in case of your example of Ethernet over ODU we would have a G-PID (=54 - Ethernet) and a Hierarchy TLV saying: Ethernet over ODU with mapping = GFP-F.

Hope this clarify the issue.

Thanks,
Lou

> [rest deleted]

---

From: Lou Berger <[email-masked]>
Date: Sun, 06 May 2012 12:31:37 -0400

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

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

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

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)

[The following was inserted from the old thread]
>     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]
> 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?

IMO representation of the N (where N>1) layers above LSP being signaled
is something new, i.e., can't be represented supported in current
semantics, so a new mechanism is warranted.  If the purpose of the
object is to represent information at the layer of the LSP being
signaled, existing mechanisms must be reused/leveraged if at all possible.

> This information is needed both for intra-ODU mapping case
> and inter-mapping case, since this info is not present in any of the
> actual GMPLS field TLV.
> 

> Please not that this is not the mapping using UPI=0x01 and PT=0x05

I'm really confused.  This text implies (to me) that the Hierarchy TLV
may represent information at the ODU layer of the LSP, but this seems to
contradict the draft which says:
   A Hierarchy TLV for each branch of the client signal multiplexing
   supported by the server LSP MUST be used. ...

Which way is it?

> a) Adding new G-PID values to be able to distinguish different mapping --> clearly overloading the G-PID meaning 

G-PID is an indicator of the the client payload type, carried by an LSP.
 Encoding says how the payload type is encoded "on the wire (LSP)". If
we can use these, then we should.

If the Hierarchy TLV really just relates to the N (where N>1) layers
above LSP being signaled, then this the TLV makes sense.

> Actually, LSP Encoding Type per RFC 4328 include the following values:

If new encoding are needed to represent a non-ODU client signal, then we
should define them and not invent a new place to carry them.

> As said during past months, our preference was for a new object,
> maintaining compatibility with the meaning of already defined TLV 
> fields and providing a more cleaner solution.
> 

I agree that a new mechanism makes sense for the representation of the N
(where N>1) layers above LSP being signaled as there is no current
alternative in GMPLS.

> Last, to answer your question , in case of your example of Ethernet
> over ODU we would have a G-PID (=54 - Ethernet) and a Hierarchy TLV
> saying: Ethernet over ODU with mapping = GFP-F.
> 

So, again you're saying that ADAPTATION Object applies to the layer of
the LSP being signaled. Right?

Lou