Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.txt

[Lou Berger <[e-mail]>]

Fei,

	Per my last message.  The introduction of ILH does not require, or
proposal, any change to the WG OTN documents.  (Although it does imply
the use of a new Switching Type for OTNv3 -- which is already in the
drafts.)

If someone wants to propose changes to the OTN drafts based on ILH,
that's fine, but such a proposal is *not* in our draft.

Lou

On 2/28/2012 4:46 AM, [e-mail] wrote:
> 
> Hi Lou, John
> 
> I am confused with the introduction of ILH also, try to figure out it
> based on the exact example (like OTN, which is the hot topic discussed
> recently).
> 
> Below is my understanding provided for discussion, please do not
> hesitate to let me know if it is wrong.
> 
> (1) The ISCD of the ODUK/OTUK is not changed except that the added ILH
> field and moving the Max LSP Bandwidth per priority as a TLV into the
> SCSI TLV?
> 
> (2) The ISCD of the ODUj is reflected by the ILH (for example 1 ODU1/2
> ODU2/3 ODU3/4 ODU4/ 8 ODU0/ 9 ODU2e/10 ODUflex CBR...) and the TLV
> carrying the unreserved bandwidth looks like?
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Reserved     | Num of stages |T|S| TSG | Res |   Priority    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    Stage#1    |      ...      |   Stage#N     |    Padding    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Unres ODUj at Prio 0      |     Unres ODUj at Prio 1      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Unres ODUj at Prio 2      |     Unres ODUj at Prio 3      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Unres ODUj at Prio 4      |     Unres ODUj at Prio 5      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Unres ODUj at Prio 6      |     Unres ODUj at Prio 7      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Notes:
> (1) The structure is copied from the draft
> http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-ospf-g709v3-01.txt with
> no sigal type there.
> 
> (2) For the trunk ODUK, both Max and Unreserved TLV SHOULD be carried
> with the same ISCD header.
> 
> (3）The IACD is changed like?
> 
> Consider an interface which support OTN and SDH switching,or OTN and
> packet switching.
> The VC-4 frames/GFP frames can be mapped directly into ODU0, but ODU1 is
> forbidden (local polices).
> In this case, the Lower ILH will be useful.
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Upper SC      | Upper Encoding| Reserved            |Upper ILH|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Lower SC      | Lower Encoding| Reserved           |Lower ILH |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Notes: the other parts is snipped here. and the XRO
> 
> 
> Best regards
> 
> Fei
> 
> 
> *John E Drake <[e-mail]>*
> 发件人:  [e-mail]
> 
> 2012-02-28 07:51
> 
> 	
> 收件人
> 	Lou Berger <[e-mail]>
> 抄送
> 	CCAMP <[e-mail]>
> 主题
> 	Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.txt
> 
> 
> 	
> 
> 
> 
> 
> 
> Snipped, comments inline
> 
>> >
>> > [JD]  This is the same problem I have had all along.  Viz, you are
>> > explicitly equating trunk bandwidth with layer boundaries.
>> >
>> > I have yet to hear anyone articulate why this is necessary or useful,
>> > and even if it were necessary or useful, advertising an explicit
>> > field is duplicative because we *already* advertise trunk bandwidth,
>> > and hence in this formulation, layer boundaries.  If an
>> > implementation were to decide that having an explicit field was
>> > necessary or useful, it could easily be included in their internal
>> > data structures without cluttering the advertisements.
>> >
>> > As an aside, PSC 1-4 did not do this.  Instead, PSC 1-4 was an
>> > entirely logical concept, which meant that the network designer could
>> > place the layer boundaries wherever they wished.
>> >
>>
>> John,
>>
>> Yes.  MPLS and label stacking are wonderfully flexible technologies.
>> Unfortunately, SDH and OTN are not as flexible and there is a fixed
>> multiplexing structure.  (See page pgs 16 & 17 of G.709, there are only
>> a finite number of mappings down to the physical layer.)
> 
> [JD] You didn't actually answer any of my points but rather just
> re-asserted that a layer indicator is needed and that layers correspond
> to trunk bandwidths.  I continue to find both assertions questionable as
> we didn't need a layer indicator in SDH/SONET and people far more
> knowledgeable than either you or I have said it is unnecessary in OTN.
> 
> To put it another way, if a TE advertisement contained a layer
> indicator, what *exactly* would you differently in your processing of
> such an advertisement?
> 
>>
>> ILH *could* be used to represent this, or it could *not*.  This is a
>> discussion for the future as all the draft says at this point is:
>>
>>    The mapping of ILH values to specific
>>    levels of hierarchy within a data plane technology is specific to
>>    each switching technology and is therefore outside the scope of this
>>    document.
> 
> [JD]  This presupposes that a mapping of ILH values to specific levels
> of hierarchy is either necessary or useful.  
> 
>>
>> and I previously said, "I would not recommend any changes to
>> gmpls-ospf-g709v3 at this time."  So we really can leave this argument
>> until such time as someone makes a proposal on using ILH with OTN...
> 
> [JD] Your email to which I initially responded proposed *exactly* this.
>  If no one knows how ILH is to be used, why are we introducing it?
> 
>>
>> Lou
>>
>>
>> > Thanks,
>> >
>> > John
>>
>> >
>> >
>> >
>> >
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
>