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

[Lou Berger <[e-mail]>]

Young,

see below.

On 5/7/2013 3:06 PM, Leeyoung wrote:
> 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.

Great.

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

As you know: There's lots of information that shows up in both
signaling and routing, where the former provides the requirements of
a specific LSP and the latter provides the capabilities/availabilities
within the network.  Having information in routing doesn't obviate the
need for the same information in signaling, and information contained
in signaling need not be represented in routing. And, to oversimplify,
the more information that's available in routing the more likely that
a path computed for a LSP will be established without the use of
error/crankback processing, but also more likely the IGP/system will
run into scaling issues.

So GMPLS' current representation of G-PID in signaling, but not
routing, reflects a judgement call at the time GMPLS routing was
defined. (and to rely on error/crankback processing when there are
g-pid mismatches.)  While not an author of RFC4202, I believe part of
this tradeoff calculus was the assumption that there is a high
probability of there being a switch function at the egress that allows
the termination of an LSP coming in (from the network) on any interface
for any G-PID (and any other termination/egress constraint) supported
on the node.  Given that WSON clearly widens the scope to include nodes
where this assumption no longer holds, it seemed reasonable (at least
to me) for the WSON documents to revisit this decision.

> If you want Egress (tributary side) G-PID compatibility check using
> IGP, this is a whole different matter. 

It's not a matter of what I want, it's a matter of what the WSON
documents currently state & allow.  As I mentioned earlier in this
thread, the current text seems to support and even envision
advertisement of trib/egress resources, including G-PID. From my
perspective, advertisement of egress resources should be generic and
this was the main point of my comments.

Modifying the WSON documents make it clear that egress/trib resources
aren't being advertised resolves this comment.  (please don't forget to
add the other comments discussed in this thread.)

It does raise the question of why the current solution (i.e., crankback)
is fine for the egress case, but not for the regen case.  As I thought
you were covering both case, I haven't thought much on this.  Can you
explain why you made this tradeoff (G-PID advertisement for regen, but
not egress)?

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

As discussed above having information in routing doesn't obviate the
need for the same information & check to be present in signaling, it
just changes the probability of success/crankback.

Lou

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