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

[Lou Berger <[e-mail]>]

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?

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.

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?

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?

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: [e-mail] [mailto:[e-mail]] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>