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

From: Lou Berger <[email-masked]>
Date: Sat, 01 Oct 2011 08:34:15 -0400

Pietro and Sergio,
	See below for responses in-line.

On 9/29/2011 4:48 AM, GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) wrote:
> Hello Lou,
> 
> we try to make further clarification, with a long explanation in line ( sorry for this :-))
> 
> Pietro and Sergio
> 
> ============================================
> Pietro Vittorio Grandi
> Terrestrial Optics Portfolio Evolution
> Alcatel-Lucent Vimercate (Italy)
> Tel: +39 039 686 4930
> Mail: [email-masked]
> ============================================
> Put your hand on a hot stove for a minute, and it seems like an hour.
> Sit with a pretty girl for an hour, and it seems like a  minute. That's relativity.
> (A. Einstein)
> 
> 
> -----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.

Of course this doesn't answer where is the right/best place.

> 
> WRT to (c) you said:
>> [ALU] Item (c) is not correct. Intermediate nodes do not need to
> demultiplex client, you can have ODU0 LSPs , that surely need to have
> 1,25 interfaces in the end points but using 2.5 TSG in the middle of the
> network since they have tunneled on 2.5 structured containers.
>>
>>
> 
> I'm having a hard time parsing your statement.  Are you saying (i) you
> client ODU0 carried over an ODUn (n>0) H-LSP or (ii) and ODU0 which is
> carried over links OTUn links and 2.5G slots in the intermediate links,
> or (iii) something completely different.
>  
> [[ALU]] We think that the better way to understand the problem is
> having in mind a reference model composed by:
> 
> A) The current LSP that we are drawing. 
> 
> B) The server resources used by the current LSP. These resources can
> be different link by link. The server resources can be represented in
> control plane either by TE-link or FA-LSP. When the server capacity
> is higher then the capacity of the current LSP (we mean not at the
> same rate of the client) , the server is structured and the current
> LSP is adapted in the server using 1.25 or 2.5 tributary slots
> depending from the capability of both the endpoints of the server.

So, unless I'm misunderstanding you, the "link by link server resources"
is the same as "[need] (c) Intermediate nodes", which we've agreed
depends on the capabilities of the nodes at the end of the links/FA-LSPs.

I believe your additional point, is that the TSG of the "current LSP" is
immaterial at intermediate nodes.  correct?

> 
> C) A resource that is a client of the current LSP. This client can either be
> an ODU or use a different technology. 
> 
> If the client in point c) is an ODU (or better a set of ODUs at
> different rates) then the current LSP will have (in future) to be
> structured in such a way that the ODU client(s) will be carried. In
> order to ensure that a client can be set two things must happen at
> the endpoint of the current LSP. 
>
> The first one is that both endpoints
> declare the same set of clients, and the second is that both endpoint
> can support the same tributary slot granularity. Note that it is not
> possible to infer the tributary slot granularity from the
> client-server hierarchies declared by a TE-link. Just to make an
> example, take a TE-link that declares to support ODU2 over ODU3, ODU2
> can be mapped over ODU3 either using 2.5 or 1.25 tributary slots. 

This was need (a) in my original mail, correct?

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

> In conclusion to this reasoning, when we signal the current LSP (of
> point A) we need to transfer two information: The desired tributary
> slot granularity that the current LSP will export to future clients
> and the set of clients (point C) that has to be supported (if
> known). The desired tributary slot granularity to be exported to
> future clients directly affects the adaptation that will be
> instantiated when drawing a client. The desired tributary slot
> granularity is the entity that we are debating. 

Agreed, this was "need (a)" in my original mail.

> Note that the desired
> tributary slot granularity for client does not affect the label
> signaled for the current LSP. These labels are only affected by the
> tributary slot granularity exported by the server that is carrying
> the current LSP.
>
> Last but not least, note that the tributary slot granularity is not 
> part of current LSP in the sense that does not exist an ODU2 at 1.25
> TS and does not exist an ODU2 at 2.5 TS. It only exist an ODU2 at a
> nominal rate mapped over a higher rate server using 2.5 or 1.25 TS.
> 

Humm, while this is the case for ODU2, what about ODUflex and ODU0?

> 
> 
>> Either way, isn't the case that it would be optimal to use 1.25 TSs for
>> certain ODUs (e.g., OD0, ODUFlex) on transit links when both ends of the
>> link support 1.25?
> 
> [[ALU]] Tributary Slots were originally introduced in order to avoid
> link defragmentation. They started at 2.5 that was correct for all
> ODUs (at that time) and following it was introduced 1.25 in order to
> better accommodate GbEthernet client (into ODU0 at 1,25) and also
> ODU-flex (CBR) .
> 
> ODU0 and ODU flex MUST be mapped over their server at 1.25. Just to
> make an example let's take an ODU0 LSP that has to be carried over an
> ODU2 LSP that in turn is mapped over several ODU3 LSPs.
> 
> When signaling the ODU2 LSP we must ensure that at the endpoints the
> ODU2 LSP supports at the endpoints the 1.25 TS granularity. There is
> no need (and it is not an optimization) to force the ODU2 LSP to use
> ODU3 LSPs that export 1.25 TS.
> 

Right.  Unless I misunderstand you, you're saying and I agree that at
the mapping point between the ODU0 LSP and the ODU2 LSP, the ODU2 LSP
must be able to support the proper, 1.25, TSG.  Assuming this is correct
this may be at an intermediate node in the network, which was my
original "need (c)".   So we're back to a seeming agreement on all three
needs.

> 
> You also said:
>> [ALU] In the INFO we have explained the need also for TSG in routing
>> (following conclusion of mailing list discussion) and the routing
>> draft simply proposes a possible encoding of the information.
>>
>> This solution, for the sake of truth, can be getting better, taking
>> into account the AutoPayloadtype flag information. This information
>> is a typical MI information , described in in G.798, and it simply
>> tells us whether Fallback procedure is enabled or not.
>>
>> Since this information is typically configured by the manager we do
>> not think it has to be considered directly in the control plane
>> (neither signaled or advertised ). However we have to take into
>> account the fact that auto-payload type set to off generates
>> interfaces that can support 1.25 TSG only.
>>
> 
>> Okay, now I'm really confused.  This seems to imply that you are saying
>> the (c) above is needed.  What am I missing?
> 
> [[ALU]] the advertising of TS information in routing is coming from
> the requirement found in ITU-T's G.7715.1 stating the need for links
> to advertise the adaptations supported by a link end (i.e. TE-Link
> end). As said before TS size is an adaptation attribute. When the
> TE-Link advertisement (whether a TE-Link created by an FA or a
> TE-Link that uses a physical link) includes details related to TSG,
> it is possible for routing to validate the compatibility of the
> endpoints with the service requested. 

100% agreed. Note that G-PID really isn't typically used as part of
route/path computation today.

> This has nothing to do with
> point c of your statement that would imply always along the path to
> have only one type of TS size.

I don't think I ever made this statement or intended this implication.
Perhaps you can suggest a rewording of "need (c)".

So, it seems we all agree that TSG information is needed in both
signaling and routing.  Can we also agree that G-PID isn't the right
place for this information?

Lou

> 
> Much thanks,
> Lou
> 
> 
> On 9/28/2011 8:02 AM, BELOTTI, SERGIO (SERGIO) wrote:
>> Hi Lou,
>>
>> Please see in line .
>>
>> BR
>>
>> Sergio and Pietro
>>
>>
>> -----Messaggio originale-----
>> Da: [email-masked] [mailto:[email-masked]] Per conto di Lou Berger
>> Inviato: martedì 27 settembre 2011 15.20
>> A: CCAMP
>> Oggetto: [CCAMP] Thought on where to carry G.709-v3 TSG
>>
>> All / G.709 draft authors,
>>
>> 	We have a few slightly unaligned proposals on where to indicate the
>> [G.709-v3] Tributary Slot Granularity:
>>
>>
>>
>> 1: G-PID
>>     draft-ietf-ccamp-otn-g709-info-model-01 says:
>>     One possible solution is the G-PID field of the GENERALIZED LABEL
>>     REQUEST Object.
>>
>> [ALU]What inserted in the INFO draft , is the result of the discussion made in July on the subject, in the mailing , taking into account suggestion and comments coming from John, Jonathan and others participating at the discussion.
>> Our opinion is that the ending draft for signaling should be aligned to the info model draft incorporating the required changes to GPID. The motivations behind our opinion can be better understood reading the other comments.
>>
>> 2: A new field:
>>    draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
>>       - TSG: Tributary Slot Granularity (2bit): Used for the
>>       advertisement of the supported Tributary Slot granularity
>> [ALU] In the INFO we have explained the need also for TSG in routing (following conclusion of mailing list discussion) and the routing draft simply proposes a possible encoding of the information.
>> This solution, for the sake of truth, can be getting better, taking into account the AutoPayloadtype flag information. This information is a typical MI information , described in in G.798, and it simply tells us whether Fallback procedure is enabled or not. 
>> Since this information is typically configured by the manager we do not think it has to be considered directly in the control plane (neither signaled or advertised ). However we have to take into account the fact that
>> auto-payload type set to off generates interfaces that can support 1.25 TSG only. 
>>
>> This fact can be incorporated in routing by adding a new meaning in the two bits encodings:
>>
>>          - 00 - 1.25 Gbps (AutoPayloadtype off)
>>
>>          - 01 - 1.25 Gbps (AutoPayloadType on)
>>
>>          - 10 - 2.5 Gbps 
>>
>>          - 11 - Reserved
>>
>>
>> 3: Implicitly:
>>    draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
>>    signal TSG, but rather has it implied in the new ODU label.
>>
>> [ALU] There is nothing implicitly. The reality is that at the moment signaling draft does not address the problem . What you consider as "implicitly deduced" is in fact the TSG granularity with which the client is mapped in the server ODUk/OTUK or FA/H-LSP. What has to be clarified is that what we need to signal is an adaptation information regarding what the server can expose to the client regarding TS granularity capability. 
>> TS size is an attribute of the adaptation used to put an ODUj into an ODUk.
>> What you consider as implicit is just how ODUj is mapped into ODUk, but the problem is to signal ODUk with the correct adaptation attribute.
>>
>> Some other alternatives include:
>>
>> 4: GMPLS Encoding
>>    Currently used to indicate G.709 (which is also what the Switch
>>    cap essentially indicates) An alternative would use:
>>       12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
>>       TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)
>>
>>    In routing, 15 would imply support for both 1.25 and 2.5G, as
>>    support for both by 1.25 capable interfaces is required by
>>    [G.709-v3]. (At least as I understand it.)
>>
>> [ALU] Encoding field should define the nature of the LSP : RFC 4328 defined two OTN new values G.709 ODUk (Digital Path) and G.709 Optical Channel. We do not see any reason to link encoding with information that would need to choose interfaces (as TSG) since the "nature " of LSP does not change dependently of the usage of 1.25 or 2.5 ODUk tributary slot.
>>
>> 5: Signal Type
>>    Carried in routing ISCD/SCSI and signaling traffic parameters.
>>    Could enumerate all ODUx types to indicate either 1.25G or 2.5G.
>>    Existing types indicate 2.5G, new types would need to be enumerated
>>    for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would imply
>>    support for both 1.25 and 2.5 types in routing.
>>
>> [ALU] During the discussion in July the usage of Signal Type was one of the first possibilities analyzed. We definitely leave out signal type for the reason above regarding adaptation information.
>> TS granularity is an information that server LSP has to expose to client LSP. What is related to the client is conveyed in the G-PID not in the Signal Type . 
>> There are no different Signal Type for the same ODU in OTN: e.g. ODU2 it is the same , what can change is the adaptation attribute towards client (e.g. 1.25 or 2.5 TSG for ODU1 client). 
>>
>> 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.
>>
>> [ALU] Item (c) is not correct. Intermediate nodes do not need to demultiplex client, you can have ODU0 LSPs , that surely need to have 1,25 interfaces in the end points but using 2.5 TSG in the middle of the network since they have tunneled on 2.5 structured containers. 
>>
>>
>>
>> It seems to me that we have enough existing fields in GMPLS (for G.709)
>> that we should consider these before introducing new ones.  Of the
>> existing fields, we have 1, 4 and 5.:
>>
>>    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.
>>
>> [ALU] G-PID is the correct place :
>>  1) It contains information related to client of an LSP that is exactly what we need.
>> 2) As reported in RFC 3471 " This is used by the nodes at the endpoints of the LSP, and in some cases by the penultimate hop." We are exactly in these "some cases"
>>
>>    Option 4, Encoding, is used to support (a) and (b)-type checks in
>>    GMPLS, but not (c).  So, while this field is definitely a better
>>    place than G-PID to indicate TSG, it doesn't satisfy all the needs.
>>
>>    Option 5, Signal Type, is used to support all needs.
>>
>> [ALU] Already commented why not the right places.
>>
>> Given all this, I'd like to propose that we use Option 5, Signal Type,
>> to indicate TSG, and that this be reflected in the relevant WG drafts.
>> (Authors, let me know if you'd like specific text proposals.)
>>
>> Comments?
>>
>> Much thanks,
>> Lou (as WG contributor)
>>
>> _______________________________________________
>> CCAMP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> 
> 
> 
>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Mon, 3 Oct 2011 15:10:20 +0200

Lou,

We captured essential parts of your mail to avoid proliferation of nesting.

We think that we are converging:
1) we have proposed a solution for routing as all agreed TSG information is needed
2) there are two possible alternatives for signaling as detailed below.

See response details in correspondence of the snip.

BR

Sergio and Pietro

[SNIP]
> [[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.

[ALU] It seems that from the first mail, the only survived options for signaling are:

1: GPID
2: Signal type
3: Encoding

Signal type and encoding should be discarded because both imply that the current LSPs uses exclusively intermediate links/FAs exporting the TSG granularity embedded in the Encoding or in the signal type. This is not required.

The G-PID might be used on the penultimate hop to select the right interface, but you say that it cannot be considered because by design it should be used only on endpoints. About this fact RFC 3471 says instead that exceptions are possible.

If our interpretation is correct, the only real possibilities for signaling are either allowing an exception on G-PID usage or introduce a dedicated object.

In the info model draft we have already stated the need for a dedicated optional object in signaling that should carry the set of potential client. The TSG information could be added in that object.

[SNIP]
> control plane either by TE-link or FA-LSP. When the server capacity is
> higher then the capacity of the current LSP (we mean not at the same
> rate of the client) , the server is structured and the current LSP is
> adapted in the server using 1.25 or 2.5 tributary slots depending from
> the capability of both the endpoints of the server.

So, unless I'm misunderstanding you, the "link by link server resources"
is the same as "[need] (c) Intermediate nodes", which we've agreed depends on the capabilities of the nodes at the end of the links/FA-LSP

[ALU] The two endpoints of the same TE-link/FA negotiate the TS size dependently from their own capabilities.

I believe your additional point, is that the TSG of the "current LSP" is immaterial at intermediate nodes.  correct?

[ALU] The TSG of the " LSP current" is an information useful for potential client of this LSP, so is not correlated on how this LSP is mapped on server resources.

[SNIP]

[ALU] yes

[SNIP]

[ALU]  No reason to think differently for ODU-flex or ODU0.
Both signals are adapted on a server using one or more  1.25 TS.
As ODU2 at 2.5 TS does not exist, in the same way an ODU0 or ODU-flex at 1.25 TS does not exist.
The fact that currently the ODU0 and ODU can be, by definition adapted on a server using only 1.25 TS is not relevant for signal specification.
Nothing prevents in the future that ODU0 can be carried on a different TS size.

[SNIP]
> ODU3 LSPs that export 1.25 TS.

Right.  Unless I misunderstand you, you're saying and I agree that at the mapping point between the ODU0 LSP and the ODU2 LSP, the ODU2 LSP must be able to support the proper, 1.25, TSG.  Assuming this is correct this may be at an intermediate node in the network, which was my
original "need (c)".   So we're back to a seeming agreement on all three
needs.

[ALU] You're considering the case an add/drop of a service ODU0 using ODU2 LSP as H-LSP , that is not terminated in the same points of ODU0 service?
This is not possible:
wherever you start the ODU0 service, you need to terminate the ODU2 LSP used as H-LSP. So again this is an end point for server/H-LSP.
Coming back to the example, in order to switch an ODU0 service on an intermediate node,it is needed to terminate first the ODU2 LSP used as H-LSP. In order to be usable by an ODU0 LSP that is currently set, the ODU H-LSP must offer to the ODU0 LSP a 1.25 TSG.
For completeness, if the LSP that is currently set is an ODU2 LSP, the ODU H-LSP must offer to the ODU2 LSP a 1.25 or a 2.5 TSG.

[SNIP]
100% agreed. Note that G-PID really isn't typically used as part of route/path computation today.

[ALU] Not clear what you mean here: our proposal of the usage of G-PID is in the signaling not for path computation for which we should have the dedicated information in the routing.

[ALU] No, point c is clear. The meaning of our sentence is that compatibility validation has to be done in the end points no need in the intermediate ones.

So, it seems we all agree that TSG information is needed in both signaling and routing.

[ALU] This is the same conclusion reached in July: yes, TSG information is needed both in signaling and routing

 Can we also agree that G-PID isn't the right place for this information?

[ALU] We are not close on only one solution: G-PID , for the reason we tried to explain it seems , among the present objects/fields, the best candidate, as recognized by the most of the interested people in the July discussion.
Said that, as above, there is also an alternative solution , and we would like to have a common agreement on one of the two from WG.

BR

SERGIO BELOTTI

ALCATEL-LUCENT
Terrestrial System Architect
Optics Portfolio Evolution

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

-----Messaggio originale-----
Da: Lou Berger [mailto:[email-masked]]
Inviato: sabato 1 ottobre 2011 14.34
A: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); BELOTTI, SERGIO (SERGIO)
Cc: CCAMP
Oggetto: Re: R: [CCAMP] Thought on where to carry G.709-v3 TSG

Pietro and Sergio,

Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 03 Oct 2011 10:21:51 -0400

Sergio,
	In interest in keeping the conversation focused, I've narrowed this
mail to just the first point in your prior mail.

On 10/3/2011 9:10 AM, BELOTTI, SERGIO (SERGIO) wrote:
> 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.
> 
> Signal type and encoding should be discarded because both imply that
> the current LSPs uses exclusively intermediate links/FAs exporting
> the TSG granularity embedded in the Encoding or in the signal type.
> This is not required.

huh?  WRT encoding, RFC 3471 says:

      LSP Encoding Type: 8 bits

         Indicates the encoding of the LSP being requested.
and
     Switching Type: 8 bits

         Indicates the type of switching that should be performed on a
         particular link.

In other words encoding is an end-to-end attribute that relates to the
LSP.  Switching Type relates to what is happening link by link.  While
not typically done, Switching Type could change hop-by-hop, but encoding
is persistent across an LSP.

So I see personally see no issue or conflict if encoding indicates 1.25G
TSG but the label indicates 2.5G TSG.  Or for that matter mapping a
1.25G TSG signal on an H-LSP that uses 2.5G TSGs.

WRT to signal type, RFC 4328 says:

3.2.1.  Signal Type (ST)

   This field (8 bits) indicates the type of G.709 Elementary Signal
   that comprises the requested LSP.

So, as with Encoding, this relates to the end-to-end LSP and doesn't
indicate the TSG on a particular link.  Again, TSG is covered in the
label.  So again I see no issue or conflict if signal type indicates
1.25G TSG but the label indicates 2.5G TSG.

> 
> The G-PID might be used on the penultimate hop to select the right
> interface, but you say that it cannot be considered because by design
> it should be used only on endpoints. About this fact RFC 3471 says
> instead that exceptions are possible.

> 
> If our interpretation is correct, the only real possibilities for
> signaling are either allowing an exception on G-PID usage or
> introduce a dedicated object.

Yes, I think we have a disagreement on interpretation (as well as a
really good discussion!)  IMO encoding and signal type are both better
suited to the requirements than G-PID given the above.  Furthermore, per
my previous mail, I think Signal type is better then Encoding.

Has your opinion changed/been impacted by the above interpretation of
signal type and encoding?  If not, can you elaborate?

[major snip]

Much thanks,
Lou

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Tue, 4 Oct 2011 10:31:59 +0200

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.

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.
  
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. 
The extension of G-PID would be one to one consistent with G.709.

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.  

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 ?

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.   

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. 

BR 
Pietro & Sergio

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: lunedì 3 ottobre 2011 16.22
To: BELOTTI, SERGIO (SERGIO); GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP
Subject: Re: R: R: [CCAMP] Thought on where to carry G.709-v3 TSG (point 1)

Sergio,

3.2.1.  Signal Type (ST)

[major snip]

Much thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 04 Oct 2011 07:50:26 -0400

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?

(*) 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.

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.

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

> one consistent with G.709.

This is where our perspective diverges.

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

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

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

Much thanks,
Lou