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

From: Lou Berger <[email-masked]>
Date: Mon, 16 Apr 2012 10:55:42 -0400

Authors,

This message is a follow on to the discussion that we started to have in
Paris on the ADAPTATION Object.  I have two comments, the second of
which I didn't have time (during the presentation time period) to make:

1) Can you explain/justify why you are proposing carrying a subset of
the Payload type code points defined in G.709 (see Table 15-8) in the
ADAPTATION Object, but not others?

I'm not questioning the need for an end-to-end adaptation check, but
rather an apparent incomplete method for supporting this check.

2) Given the very limited number of remaining RSVP c-type values, I'm
struggling with justifying the definition of the new, perhaps not very
generic, ADAPTATION Object rather than carrying this information in an
existing (and more generic) object.  Have you considered carrying this
information elsewhere, e.g., LSP attributes, and if so what's your
thinking for not using such?

Lou (As WG participant)

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 17 Apr 2012 09:34:43 +0000

Hi Lou,

Great points.

For point 1, the Adaption object in this draft is used to carry only OTN specific information that is needed to create an ODU FA-LSP to carry one specific ODU signal, but the other payload types (ie. other information in the table 15-8) should be still carried in G-PID as defined in RFC3471.

For point 2, good suggestion. I just checked RFC4420, I agree with you that it is better to put this information in LSP attributes, which is used to signal attributes required in   support of an LSP, or to indicate the nature or use of an LSP where that information is not required to be acted on by all transit LSRs.

Thanks
 
Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2012年4月16日 22:56
To: [email-masked]
Cc: CCAMP
Subject: [CCAMP] A couple of comments on draft-ietf-ccamp-gmpls-signaling-g709v3-02

Authors,

Lou (As WG participant)
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Tue, 17 Apr 2012 07:48:27 -0400

Fatai,
	See below.

On 4/17/2012 5:34 AM, Fatai Zhang wrote:
> Hi Lou,
> 
> Great points.
> 
> For point 1, the Adaption object in this draft is used to carry only
> OTN specific information that is needed to create an ODU FA-LSP to
> carry one specific ODU signal,

Well I can see this for Type 2 (Hierarchy signaling), but for FA/H-LSP +
Type 1 (Server TSG signaling) it seems that the same could be done with
G-PID.  If you disagree, what do you expect to carry in G-PID in the ODU
H-LSP case?

> but the other payload types (ie. other
> information in the table 15-8) should be still carried in G-PID as
> defined in RFC3471.

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?

Lou

> 
> For point 2, good suggestion. I just checked RFC4420, I agree with
> you that it is better to put this information in LSP attributes,
> which is used to signal attributes required in   support of an LSP,
> or to indicate the nature or use of an LSP where that information is
> not required to be acted on by all transit LSRs.
> 
> 
> 
> 
> Thanks
>  
> Fatai
> 
>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 19 Apr 2012 17:03:12 +0200

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.

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.

Best Regards

Sergio and Daniele 

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Lou Berger
Inviato: martedì 17 aprile 2012 13.48
A: Fatai Zhang
Cc: CCAMP; [email-masked]
Oggetto: Re: [CCAMP] A couple of comments on draft-ietf-ccamp-gmpls-signaling-g709v3-02

Fatai,
	See below.

Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 23 Apr 2012 12:51:42 -0400

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.

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

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 27 Apr 2012 06:36:27 +0000

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.

either.)

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.

> b)    As said before, it wouldn’t be exhaustive with respect real

> mapping beyond the same payload.

>> H-LSPs, am I wrong?

[Fatai] What did you mean by saying “non OTN signal types”? Did you mean removing “Switching Type” & “Encoding Type”? 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.

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 27 Apr 2012 08:18:49 -0400

Fatai, Authors, see below.

On 4/27/2012 2:36 AM, Fatai Zhang wrote:
> Subject: Re: R: [CCAMP] A couple of comments on
> draft-ietf-ccamp-gmpls-signaling-g709v3-02
> 
> Sergio,
> 
>          See below.
> 
> [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?

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

Thanks,
Lou

> [rest deleted]