Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19

[Leeyoung <[e-mail]>]

Hi Lou,

Yes, the scope of drop ports mentioned in Section 6 of the info document is aimed at just Regen ports. I will make this point clear in the revision of the info draft. 

As we modeled Regen signal compatibility that includes Regen drop port limitation, G-PID compatibility identification for Regen (in and out) is included as part of the "package" per se to advertise all Regen related constraints using IGP. 

Egress G-PID compatibility check has been built as part of GMPLS Signaling, which I believe serves the purpose well. 
If you want Egress (tributary side) G-PID compatibility check using IGP, this is a whole different matter. First, I think we need a clear use-case and requirement why we want to do this in light of the signaling mechanism that does the check. Let me know if this is not the case from your perspective. Are there some reasons you believe GMPLS Signaling mechanism would not work to check the tributary egress G-PID check? 

Regards,
Young 

 

-----Original Message-----
From: Lou Berger [mailto:[e-mail]] 
Sent: Tuesday, May 07, 2013 8:52 AM
To: Leeyoung
Cc: CCAMP; [e-mail]
Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19

[oops, found this in my outbox -- sorry about the delay]

Young,

I think this discussion primarily comes down to the intent of mentioning drop ports in several places in Section 6 of the info document.

Is the scope of this text aimed at just regen ports or any drop (regen
&trib) ports? The text isn't scoped so, as I mentioned/asked in my mail on 4/4, I understood it to refer to the advertisement of information for any drop port.  so:
> Did I misunderstand the intent of mentioning drop ports in several 
> places in Section 6 of the info document?

If the intended scope is just regen, this needs to be made clear in the documents.  Furthermore,  as the same (G-PID compatibility
identification) issue exists with the egress, why wouldn't the same solution be used for both?

Much thanks,
Lou

On 4/24/2013 12:17 PM, Leeyoung wrote:
> Hi Lou,
> 
> I think the main point is if we need to advertise add/drop
> (tributary) ports in generic context? You said in the previous
> email:
> 
> "I agree that that is how it is normally done, but WSON seems to be changing this in two respects:
> 1) By advertising G-PID at all,
> 2) By advertising add/drop ports, where prior GMPLS approaches have only advertised the network facing interfaces."
> 
> These elements above are part of regeneration elements that constitute 
> a WSON lightpath which begins the line side of ingress and ends the 
> line side of egress. See the diagram below:
> 
>  ----                                 ----
>  |  |<------------     -------------->|  |
>  ----             |    |              ----
>                  --------
>                  |  REG |
>                  --------
> There is a clear use case for this for WSON as REG's are integral part 
> of a WSON lightpath which can cause an incompatibility/blocking issue 
> of the path. Drop/Add ports here in REG element may have wavelength 
> restriction and that is why this is an additional constraint to look 
> at.
> 
> Advertising tributary ports in general context is a different matter 
> to me. Not sure if there is a clear use case that can be justified to 
> support advertising tributary ports in general context. Even if there 
> is, I don't think that is part of the scope of the generic encoding.
> 
> 
> Regards,
> Young
> 
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Lou Berger
> Sent: Thursday, April 04, 2013 5:06 PM
> To: Leeyoung
> Cc: CCAMP; [e-mail]
> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19
> 
> Young,
> 	Please see below.
> 
> On 3/27/2013 1:59 PM, Leeyoung wrote:
>> Hi Lou,
>>
>> Please see my comments in-line. 
>>
>> Thanks.
>> Young
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Tuesday, March 19, 2013 11:44 AM
>> To: Leeyoung
>> Cc: CCAMP; Margaria, Cyril (NSN - DE/Munich); 
>> [e-mail]
>> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19
>>
>>
>> Young,
>> 	See below.
>> On 3/18/2013 1:02 PM, Leeyoung wrote:
>>> Hi Lou,
>>>
>>> The encoding is a part of the Resource Block
>>
>> Understood, but my comment was more on the definition of 
>> <ClientSignalList>/<client-signal-list> encoding.
>>
>>> (that includes Regenerators and Wavelength converters) which is a WSON specific entity.
>>
>> So I agree that the need for transit nodes to have detailed encoding 
>> and adaptation information to support 3R and certain other types of 
>> switching is (at least to my understanding) specific to WSON.
>>
> 
> Y> YOUNG>> RFC 3471 and RFC 4328 discuss G-PID as part of Generalized
> Y> Label Request parameters to indicate client/tributary layer of the 
> Y> LSP at the source/sink.
> Y>
> Y> I was not clear on what you meant "trib side resources." If you 
> Y> meant "trib side resources" are LSP encoding type, Switching Type 
> Y> and G-PID (which are covered by RFC 3471/4328), I believe RFC 
> Y> 3471/4328 are sufficient; if not could you elaborate?
> 
> trib side = add/drop port at ingress/egress
> 
> resources = attributes related to data that port can transport
> 
>>
>> But unless I misunderstand the WSON info draft, this same information 
>> can be advertised in support of the trib side resources (i.e., at the 
>> source/destination for add/drop) and this is a generic requirement 
>> shared with other technologies.
>>
> 
> y> YOUNG>> Here you seemed to allude the need for advertizing the
> y> Source/Destination tributary resource information using IGP. In 
> y> general, OSPF does not advertise the trib-side information, does it?
> y> I believe signaling check on the tributary resource info on LSP 
> y> level is good enough per RFC 3471/4328. Please correct me if my 
> y> understanding is wrong.
> 
> 
> I agree that that is how it is normally done, but WSON seems to be changing this in two respects:
> 1) By advertising G-PID at all,
> 2) By advertising add/drop ports, where prior GMPLS approaches have only advertised the network facing interfaces.
> 
> Did I misunderstand the intent of mentioning drop ports in several places in Section 6 of the info document?
> 
>>
>> So this lead me to ask about changing the G-PID list encoding to be 
>> defined in the generic drafts (to facilitate PID advertisement for 
>> non-WSON technologies.) Perhaps just having a generic encoding for a 
>> G-PID list won't be of much value, but I suspect that we'll end up 
>> needing it for other technologies too.
>>
> 
> Y> YOUNG>> This point is carried from the above discussion. G-PID has
> Y> been specified to cover all GMPLS related technologies.
> 
> Agreed that this is a derivative point and can wait until the above is clarified.
> 
>> -- For what it's worth I am having some trouble understanding how 
>> G-PID is advertised for add/drop.  As far as I can tell, you have a 
>> <LinkInfo> per add/drop port, mapped to <ResourcePool>, to a 
>> <ResourceBlockInfo> and infer output G-PID from the <InputConstraints>.
>> At least that's how I'm reading the info draft.
> 
> Y> YOUNG>> Actually G-PID is advertised as part of the Node
> Y> information: <Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...]
> Y>    [<ResourcePool>]
> 
> Got that.  That's what I was referring to when I said " mapped to <ResourcePool>"
>>
>> Look at the diagram below from info draft:
>>
>>       I1   +-------------+                       +-------------+ E1
>>      ----->|             |      +--------+       |             |----->
>>       I2   |             +------+ Rb #1  +-------+             | E2
>>      ----->|             |      +--------+       |             |----->
>>            |             |                       |             |
>>            | Resource    |      +--------+       |  Resource   |
>>            | Pool        +------+        +-------+  Pool       |
>>            |             |      + Rb #2  +       |             |
>>            | Input       +------+        +-------|  Output     |
>>            | Connection  |      +--------+       |  Connection |
>>            | Matrix      |           .           |  Matrix     |
>>            |             |           .           |             |
>>            |             |           .           |             |
>>       IN   |             |      +--------+       |             | EM
>>      ----->|             +------+ Rb #P  +-------+             |----->
>>            |             |      +--------+       |             |
>>            +-------------+   ^               ^   +-------------+
>>                              |               |
>>                              |               |
>>                              |               |
>>                              |               |
>>
>>                     Input wavelength      Output wavelength
>>                     constraints for       constraints for
>>                     each resource         each resource
>>
>>             Figure 1 Schematic diagram of resource pool model.
>>
>> Add/Drop ports to/from Resource Pool (i.e., I1,...IN and E1,..EN) is 
>> part of link information and advertised as link-TLV; however Resource 
>> Blocks and its internal connectivity is not modeled as node property 
>> as they are internal to Resource Pool.
>>
>> <ResourcePool> ::= <ResourceBlockInfo>...
>>    [<ResourceAccessibility>...] [<ResourceWaveConstraints>...]
>>    [<RBPoolState>]
>>
>> We modeled how RB's are accessible via matrices (input/ouput), if 
>> there are wavelength limitations and if RB's are available. All of 
>> these are modeled as the node property.
>>
>> And within RBinfo, we included Input/Output Constraints where ClientSignalList (GPID) is specified. 
>>
>> <ResourceBlockInfo> ::= ([<ResourceSet>] <InputConstraints>
>>    [<ProcessingCapabilities>] <OutputConstraints>)*
>>
>> Where 
>>    <InputConstraints> ::= <SharedInput> [<OpticalInterfaceClassList>]
>>    [<ClientSignalList>]
>>
>>
>>
>> I was delaying asking if a couple of related questions until the 
>> above was resolved, but perhaps it makes sense to ask them now:
>> - Shouldn't <ClientSignalList> also be allowed under <OutputConstraints>?
>>
>> YOUNG>> It is implied. <ClientSignalList> is checked in <InputContraints> and <OutputConstraints> has obviously the same property. We can add this comment to clarify. 
>>
> 
> So there is/will never (be) a case where the <OutputConstraints> differ from the <InputContraints>?  As you say, this certainly should be made explicit.
> 
>> - Doesn't it make sense to simplify the add/drop G-PID identification 
>> by adding <ClientSignalList> somewhere under (generic) <LinkInfo>?
>>
> y> YOUNG>> I think you meant doing this at the source/destination.
> sure, but aren't add/drop always at source/destination?  (I guess you 
> can come up with a case where they aren't, but this isn't the norm...)
> 
> Y>  Again
> y> I am not sure if we really need to advertise tributary client 
> y> signal as link TLV. We have signaling mechanism to verify this.
> 
> As you say, this point is covered above.
> 
>> Thanks,
>> Lou
>>
>>>
>>> Regards,
>>> Young
>>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:[e-mail]]
>>> Sent: Monday, March 18, 2013 8:07 AM
>>> To: Leeyoung; CCAMP
>>> Cc: Margaria, Cyril (NSN - DE/Munich); 
>>> [e-mail]
>>> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19
>>>
>>> Young/All,
>>>
>>> Some of the discussions last week (on 709 and dimitri's) got me 
>>> thinking more about the inclusion of G-PID on the wson specific 
>>> encoding.  As G-PID and other client/input information is not 
>>> technology specific, and it looks like there's a likely a need for a 
>>> general solution, shouldn't the G-PID (and other 'client/input') 
>>> information be in draft-ietf-ccamp-general-constraint-encode?
>>>
>>> Thoughts?
>>>
>>> Lou
>>>
>>> On 3/15/2013 5:35 AM, Leeyoung wrote:
>>>> Thanks. 
>>>>
>>>> Young
>>>>
>>>> -----Original Message-----
>>>> From: Margaria, Cyril (NSN - DE/Munich) 
>>>> [mailto:[e-mail]]
>>>> Sent: Thursday, March 14, 2013 5:53 PM
>>>> To: Leeyoung; CCAMP; 
>>>> [e-mail]
>>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19
>>>>
>>>>
>>>> Hi,
>>>>
>>>> Thanks for the quick feedback. As this introduce a dependency with 
>>>> the GPID, the text should indicate that the number of bit rate MUST match the number of GPID.
>>>>
>>>> Other than that I think this is acceptable
>>>>
>>>>
>>>>
>>>> Best regards / Mit freundlichen Grüßen Cyril Margaria
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: ext Leeyoung [mailto:[e-mail]]
>>>>> Sent: Wednesday, March 13, 2013 9:33 PM
>>>>> To: Margaria, Cyril (NSN - DE/Munich); CCAMP; 
>>>>> draft-ietf-ccamp-rwa- [e-mail]
>>>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19
>>>>>
>>>>> Hi Cyril,
>>>>>
>>>>> Thanks for your comment.
>>>>>
>>>>> This refers to the "Input Bit Rate" of the associated client 
>>>>> Signal Type in the RB.
>>>>> Below is a new section 5.4 that defines Input Bit Rate List 
>>>>> Sub-Sub- TLV. We removed "range" from this Sub-Sub-TLV.
>>>>>
>>>>> Let me know if this is acceptable.
>>>>>
>>>>> Thanks.
>>>>> Young
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ---
>>>>>
>>>>> 5.4. Input Bit Rate List Sub-Sub-TLV
>>>>>
>>>>> This sub-sub-TLV contains a list of bit rate of each input client 
>>>>> signal types specified in the Input Client Signal List Sub-Sub-TLV.
>>>>> Type := Input Bit Rate List
>>>>> Value := IEEE 32-bit IEEE Floating Point
>>>>>
>>>>>    0                   1                   2                   3
>>>>>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>   |       	          Input Bit Rate of GPID #1		    	|
>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>   :                                                               :
>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>   |       	          Input Bit Rate of GPID #N		           	|
>>>>>   
>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:[e-mail]] On 
>>>>> Behalf Of Margaria, Cyril (NSN - DE/Munich)
>>>>> Sent: Wednesday, March 13, 2013 8:54 AM
>>>>> To: CCAMP; [e-mail]
>>>>> Subject: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19
>>>>>
>>>>> Dear Authors,
>>>>>
>>>>> I have the following comments on 
>>>>> draft-ietf-ccamp-rwa-wson-encode-19
>>>>>
>>>>> Section 5.1  Resource Block Information Sub-TLV
>>>>>
>>>>> The sub-TLV format defines the "Input Bit Rate Range List  
>>>>> Sub-Sub-TLV (opt)"
>>>>> No section defines the Input Bit range List Sub-Sub-TLV, while it 
>>>>> was present in the previous version.
>>>>>
>>>>> I think the section should be re-added.
>>>>>
>>>>>
>>>>> Mit freundlichen Grüßen / Best Regards Cyril Margaria
>>>>>
>>>>> Nokia Siemens Networks Optical GmbH St.Martin-Str. 76
>>>>> D-81541 München
>>>>> Germany
>>>>> mailto:[e-mail]
>>>>> Phone: [phone]
>>>>> Fax:   [phone]
>>>>> ----------------------------------------------------------------
>>>>> Nokia Siemens Networks Optical GmbH Geschäftsleitung / Board of 
>>>>> Directors: Gero Neumeier, Dr. Rolf Nauerz Sitz der Gesellschaft: 
>>>>> München / Registered office: Munich
>>>>> Registergericht: München / Commercial registry: Munich, HRB 197143
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>