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

["Ong, Lyndon" <[e-mail]>]

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