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

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 <jdrake@juniper.net> 
发件人:  ccamp-bounces@ietf.org
2012-02-28 07:51

收件人
Lou Berger <lberger@labn.net>
抄送
CCAMP <ccamp@ietf.org>
主题
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
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp