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

[Lou Berger <[e-mail]>]

Lyndon,
	This is actually one of the reasons to make the change. Signal type
will represent the e2e constant connection characteristics, i.e., not
change, while label can change hop-by-hop as is needed to represent
how/where the connection is being carried on a a link.

Lou

On 9/27/2011 7:36 PM, Ong, Lyndon wrote:
> Hi Lou,
> 
> Not quite sure what you are proposing - would this mean the signal
> type changes hop by hop if you are creating a connection that goes
> over links supporting different TS granularity?
> 
> Thanks,
> 
> Lyndon
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Lou Berger
> Sent: Tuesday, September 27, 2011 2:13 PM
> To: John E Drake
> Cc: CCAMP
> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
> 
> 
> 
> 
> On 9/27/2011 12:40 PM, John E Drake wrote:
>> Lou,
>>
>> Using Signal Type in signaling in addition to the bit map label is
>> probably okay.
> 
> 
>> I don't think it makes any sense in routing and would
>> prefer to continue to just have the two bits.
>>
> 
> On what basis?
> 
> Lou
> 
>> Thanks,
>>
>> John
>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:[e-mail]]
>>> Sent: Tuesday, September 27, 2011 11:29 AM
>>> To: John E Drake
>>> Cc: CCAMP
>>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>
>>> John,
>>>      Two points:
>>>
>>> As a general rule, it doesn't make sense to invent yet another way to
>>> carry information when an existing one will do.  This is actually a
>>> pretty fundamental tenant of GMPLS.
>>>
>>> Also, in GMPLS the general model for allocation is to carry resource
>>> requirements in the TS not the label.  Such use of the TS ensures that
>>> the information is unambiguous in all cases.  (For example, consider
>>> the
>>> corner case where you have a unidirectional LSP, where is TSG
>>> requirements of the sender/upstream node indicated in the Path
>>> message.)
>>>
>>> Lou
>>>
>>> On 9/27/2011 11:13 AM, John E Drake wrote:
>>>> Lou,
>>>>
>>>> Clearly, the info-model draft needs to be updated, but I am quite
>>>> happy with the what is currently in the signaling and routing drafts
>>>> and I haven't heard a compelling reason to change.
>>>>
>>>> Thanks,
>>>>
>>>> John
>>>>
>>>>> -----Original Message-----
>>>>> From: Lou Berger [mailto:[e-mail]]
>>>>> Sent: Tuesday, September 27, 2011 10:58 AM
>>>>> To: John E Drake
>>>>> Cc: CCAMP
>>>>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>>>
>>>>> John,
>>>>>    There isn't alignment in the WG info-model and the individual
>>>>> routing
>>>>> and signaling drafts.  I think we have enough ways of explicitly
>>>>> carrying signal information that we can leverage to come up with a
>>>>> clean
>>>>> an unified approach that satisfies all the needs for TSG
>>> information,
>>>>> i.e.:
>>>>>
>>>>>> Given all this [see below], I'd like to propose that we use Option
>>> 5,
>>>>>> Signal Type, to indicate TSG
>>>>>
>>>>> Do you see an issue with using Signal Type to indicate the *service*
>>>>> TSG?  I don't think there would be any change to your proposed
>>>>> (hop-by-hop) label encoding.
>>>>>
>>>>> Lou
>>>>>
>>>>>
>>>>> On 9/27/2011 10:37 AM, John E Drake wrote:
>>>>>> Nevermind.  What is wrong with the current signaling approach,
>>> which
>>>>> by the way I think is great?
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Lou Berger [mailto:[e-mail]]
>>>>>>> Sent: Tuesday, September 27, 2011 10:32 AM
>>>>>>> To: John E Drake
>>>>>>> Cc: CCAMP
>>>>>>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>>>>>
>>>>>>> John,
>>>>>>>  I guess I should have titled my mail "Proposal on..." so that the
>>>>>>> proposal would actually get read...
>>>>>>>
>>>>>>> Lou
>>>>>>>
>>>>>>>
>>>>>>> On 9/27/2011 10:23 AM, John E Drake wrote:
>>>>>>>> Lou,
>>>>>>>>
>>>>>>>> In routing (draft-ceccarelli-ccamp-gmpls-ospf-g709-07) we
>>> advertise
>>>>>>>> tributary slot granularity in a new field.  In signaling
>>>>>>>> (draft-zhang-ccamp-gmpls-evolving-g709-09), it is derived from
>>> the
>>>>>>>> length of the TS bit map and the size of the ODUk/OTUk on which
>>> the
>>>>>>>> LSP is to be established.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>>>>> Behalf
>>>>>>>>> Of Lou Berger
>>>>>>>>> Sent: Tuesday, September 27, 2011 9:20 AM
>>>>>>>>> To: CCAMP
>>>>>>>>> Subject: [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.
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> 3: Implicitly:
>>>>>>>>>    draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
>>>>>>>>>    signal TSG, but rather has it implied in the new ODU label.
>>>>>>>>>
>>>>>>>>> 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.)
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>    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.
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
> 
> 
>