Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

[Igor Bryskin <[e-mail]>]

We need to discuss this face to face. The biggest disagreements with Daniele are:
1) I don't believe that flat routing model of a multi-layer OTN network is correct.
2) I think each OTN role defines a separate topology of OTN links, and there is a need to be able to constrain the routing of a given OTN connection to one or more (but not necessarily all) such topologies;
3) There is an issue in the current definitions of GMPLS OSPF extensions (RFC 4203), which does allow to specify multiple ISCDs but does not guide as to how the available bandwidth on the link is partitioned between ISCDs. This is a generic issue and should be resolved in a generic way;
4) Other than (3) we don't need any OTN or TDM specific CP machinery for TE and routing in OTN networks. Unless we see strong reasons to the contrary we should not invent such machinery.

Cheers,
Igor

-----Original Message-----
From: Ong, Lyndon [mailto:[e-mail]]
Sent: Wednesday, July 21, 2010 8:30 AM
To: Daniele Ceccarelli; Igor Bryskin; John E Drake; [e-mail]; Snigdho Bardalai
Cc: [e-mail]; Snigdho Bardalai
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

I support this as well, of course.  Whether this is a technology-specific extension of the ISCD format or a separate sub-TLV is a detail, however as Daniele points out many of the same considerations apply to both OTN and SONET/SDH.

Lyndon



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, July 21, 2010 12:49 AM
To: Igor Bryskin; John E Drake; [e-mail]; Snigdho Bardalai
Cc: [e-mail]; Snigdho Bardalai
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Igor,

In other words it could be possible to define 3 Switching Cap (LO, HO and SHO) and put what we defined in the encoding draft into the Switching Capability-specific information of the ISCD.

Something like this:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Switching Cap |   Encoding    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 1              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 2              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 3              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 4              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 5              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 6              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 7              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----Switching Capability-specific information
   |0|1|2|3|4|5|6|7|  T  |         |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P1                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P2                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P3                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P4                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P5                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P6                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P7                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                            ...                              ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P1                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P2                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P3                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P4                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P5                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P6                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |F|               Bandwidth @ P7                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I still don't understand why we need partitioning the network in three layers while just Sublamba and Full lambda distinction is enough (distinction supported advertising different signal types for full lambdas and sublambdas.

Personally i still prefer advertising these pieces of information as a separate sub-TLV (called OTN-ISCD subTLV in the draft but easily estensible to TDM-ISCD accordingly to http://tools.ietf.org/html/draft-ong-gmpls-ason-routing-exper-02 format proposed by the OIF) but this could be a valid solution too.

BR
Daniele

-----Original Message-----
From: Igor Bryskin [mailto:[e-mail]]
Sent: martedì 20 luglio 2010 23.02
To: John E Drake; [e-mail]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [e-mail]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

John,

Do you understand the quote from RFC4203:
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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Switching Cap |   Encoding    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 1              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 2              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 3              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 4              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 5              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 6              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 7              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Switching Capability-specific information              |
   |                  (variable)                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

You can use the last field for OTN switchcap to advertise unresolved bandwidth available for the ISCD on per priority level.

Igor

-----Original Message-----
From: John E Drake [mailto:[e-mail]]
Sent: Tuesday, July 20, 2010 4:35 PM
To: Igor Bryskin; [e-mail]; Snigdho Bardalai
Cc: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang; [e-mail]
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Snipped...

> IDSC sub-TLV and you can specify the unreserved bandwidth per priority
> level for every ISCD.

JD:  Igor, what part of my quote from RFC 4202 did you not understand?  You do not advertise unreserved bandwidth in the ISCD TLV.  In particular, for TDM, what is advertised is the max and min bandwidth allowed for a single LSP.  It was designed to produce a compact representation by taking advantage of the SDH/SONET hierarchy.

Advertising a separate ISCD for each supported rate is allowed but wasteful.

>
> Igor
>
>
> > On Tue, Jul 20, 2010 at 9:16 AM, Igor Bryskin
> <[e-mail]>wro=
> > te:
> >
> > > John,
> > >
> > > I totally agree with you. It is absolutely non OTN specific.
> However if a
> > > TE link advertises more than one ISCD (with each ISCD containing
> only max
> > > lsp bandwidth per priority), it is necessary to indicate how the
> total li=
> > nk
> > > unreserved bandwidth is partitioned between several ISCDs. What I
> am
> > > suggesting is instead of advertising the unreserved bandwidth
> multiple ti=
> > mes
> > > (one per ISCD), indicate how the bandwidth is split between the
> ISCDs: e.=
> > g
> > > ISCD1 75%, ISCD2 25%.
> > >
> > > Igor.
> > >
> > > -----Original Message-----
> > > From: John E Drake [mailto:[e-mail]]
> > >  Sent: Tuesday, July 20, 2010 11:54 AM
> > > To: Igor Bryskin; Daniele Ceccarelli; Snigdho Bardalai; Fatai
> Zhang;
> > > [e-mail]
> > > Cc: [e-mail]
> > > Subject: RE: [CCAMP] Comment on
> > > draft-ietf-ccamp-gmpls-g709-framework-01.txt
> > >
> > > Igor,
> > >
> > > Unreserved bandwidth is not advertised in the TDM ISC TLV, so the
> issue o=
> > f
> > > partitioning unreserved bandwidth across multiple advertised TDM
> ISC TLVs=
> >  is
> > > actually a non-issue.
> > >
> > > Unreserved bandwidth by priority has always been advertised using
> the MPL=
> > S
> > > sub-TLV.  My point has been that we have never had a requirement
> (includi=
> > ng
> > > SDH/SONET) in the past to advertise unreserved bandwidth by signal
> type, =
> > so
> > > what is special about OTN?
> > >
> > > A further point would be that if we do decide that it is necessary
> to
> > > advertise unreserved bandwidth by signal type, it should be done
> > > in
> a
> > > general way and not in an OTN specific manner.  (And in fact, the
> argumen=
> > ts
> > > that unreserved bandwidth by signal type needs to be advertised,
> such as =
> > the
> > > latest e-mail from Curtis, are not OTN specific.)
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]] On
> Behalf
> > > > Of Igor Bryskin
> > > > Sent: Tuesday, July 20, 2010 8:21 AM
> > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang;
> [e-mail]
> > > > Cc: [e-mail]
> > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > > > 01.txt
> > > >
> > > > It is a valid point, but the suggested solution is way too
> expensive.
> > > > All you need is a way to say how the advertised unreserved
> bandwidth is
> > > > partitioned between ISCDs in case the TE link advertisement
> contains
> > > > several of them. One cheap way of doing so is to allocate 3-4
> bits out
> > > > of the ISCD sub-TLV reserved bits to indicate the fraction of
> total
> > > > unreserved bandwidth associated with the ISCD. Another way is to
> use
> > > > swicthcap specific extension.
> > > > BTW: this is not an OTN specific issue, rather more general: any
> time
> > > > when a TE link advertises more than one ISCD (which is perfectly
> Ok
> > > > according to 4203) you'll have the same problem.
> > > >
> > > > Igor
> > > >
> > > > -----Original Message-----
> > > > From: Daniele Ceccarelli
> > > > [mailto:[e-mail]]
> > > > Sent: Tuesday, July 20, 2010 10:57 AM
> > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang;
> > > > [e-mail]
> > > > Cc: [e-mail]
> > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > > > 01.txt
> > > >
> > > > Igor,
> > > >
> > > > The need for unreserved resources advertised per signal type is
> the
> > > > concurrent path computation. I'll answer quoting a section from
> the
> > > > info-model draft, please have a look in particular to the
> example:
> > > >
> > > >
> > > >    " Unreserved resources need to be advertised per priority and
> per
> > > >    signal type in order to allow the correct functioning of the
> > > >    restoration process.  [RFC4203] only allows advertising
> unreserved
> > > >    resources per priority, this leads not to know how many LSPs
> of a
> > > >    specific signal type can be restored.  As example it is
> possible to
> > > >    consider the scenario depicted in the following figure.
> > > >
> > > >                   +------+ component link 1 +------+
> > > >                   |      +------------------+      |
> > > >                   |      | component link 2 |      |
> > > >                   |  N1  +------------------+  N2  |
> > > >                   |      | component link 3 |      |
> > > >                   |      +------------------+      |
> > > >                   +------+                  +---+--+
> > > >
> > > >    Suppose to have a TE link comprising 3 ODU3 component links
> with
> > > >    32TSs available on the first one, 24TSs on the second, 24TSs
> on the
> > > >    third and supporting ODU2 and ODU3 signal types.  The node
> would
> > > >    advertise a TE link unreserved bandwidth equal to 80 TSs and
> > > > a
> MAX
> > > >    LSP bandwidth equal to 32 TSs.  In case of restoration the
> network
> > > >    could try to restore 2 ODU3 (64TSs) in such TE-link while
> > > > only
> a
> > > >    single ODU3 can be set up and a crank-back would be
> originated.  In
> > > >    more complex network scenarios the number of crank-backs can
> be much
> > > >    higher."
> > > >
> > > > In other words, advertising the number of availble resources per
> signal
> > > > type does not avoid the possibility of cranck-back but decreases
> it as
> > > > much as possible. For sure a good routing prevents from crank-
> backs
> > > > caused by the restoration of LSP originating on the same Ingress.
> The
> > > > cranck-backs due to the concurrent restoration of LSPs
> originating on
> > > > different ingress nodes cannot be avoided.
> > > >
> > > > BR
> > > > Daniele
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Igor Bryskin [mailto:[e-mail]]
> > > > Sent: marted=EC 20 luglio 2010 16.16
> > > > To: Daniele Ceccarelli; Snigdho Bardalai; Fatai Zhang;
> [e-mail]
> > > > Cc: [e-mail]
> > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > > > 01.txt
> > > >
> > > > In line
> > > >
> > > > -----Original Message-----
> > > > From: Daniele Ceccarelli
> > > > [mailto:[e-mail]]
> > > > Sent: Tuesday, July 20, 2010 4:32 AM
> > > > To: Snigdho Bardalai; Igor Bryskin; Fatai Zhang;
> > > > [e-mail]
> > > > Cc: [e-mail]
> > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > > > 01.txt
> > > >
> > > > Igor, one more question.
> > > >
> > > > What about the unreserved bandwidth?
> > > > If you're advertising the max lsp bandwidth by 1 ISCD per role
> per
> > > > (muxCap & signal type) you also need to advertise the unreserved
> > > > bandwidth using 1 unreserved bandwidth sub-TLV per ISCD, correct?
> This
> > > > also implies extending the unreserved bandwidth TLV so to create
> a
> > > > corrispondence between the couples (ISCD-unreserved bandwidth
> subTLV).
> > > >
> > > > IB>> Agree that max lsp bandwidth should be advertised by 1 ISCD
> per
> > > > IB>> role per (muxCap & signal type) per priority level.
> > > > IB>> However,
> total
> > > > IB>> unreserved bandwidth IMO is OK to share between roles
> > > > IB>> unless
> you
> > > > IB>> see a compelling reason to the contrary (which I don't)
> > > >
> > > > Igor
> > > >
> > > > Thanks
> > > > Daniele
> > > >
> > > > -----Original Message-----
> > > > From: Snigdho Bardalai [mailto:[e-mail]]
> > > > Sent: luned=EC 19 luglio 2010 17.48
> > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang;
> [e-mail]
> > > > Cc: [e-mail]
> > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > > > 01.txt
> > > >
> > > > Understood...
> > > >
> > > > Regards
> > > > Snigdho
> > > >
> > > > > -----Original Message-----
> > > > > From: Igor Bryskin [mailto:[e-mail]]
> > > > > Sent: Monday, July 19, 2010 8:46 AM
> > > > > To: Snigdho Bardalai; Daniele Ceccarelli; Fatai Zhang;
> > > > > [e-mail]
> > > > > Cc: [e-mail]
> > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> > > > framework-
> > > > > 01.txt
> > > > >
> > > > > [SCB] Are you saying the ISCD as defined today with minor
> extensions
> > > > > (i.e. to further classify the information) will be sufficient
> > > > >
> > > > > That's exactly what I've been
> > > > > trying to say all along.
> > > > >
> > > > > Cheers,
> > > > > Igor
> > > > >
> > > > > -----Original Message-----
> > > > > From: Snigdho Bardalai [mailto:[e-mail]]
> > > > > Sent: Monday, July 19, 2010 11:31 AM
> > > > > To: Igor Bryskin; Daniele Ceccarelli; Fatai Zhang;
> [e-mail]
> > > > > Cc: [e-mail]
> > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> > > > framework-
> > > > > 01.txt
> > > > >
> > > > > Igor
> > > > >
> > > > > Please see inline.
> > > > >
> > > > > Regards
> > > > > Snigdho
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Igor Bryskin [mailto:[e-mail]]
> > > > > > Sent: Monday, July 19, 2010 7:43 AM
> > > > > > To: Daniele Ceccarelli; Fatai Zhang; [e-mail]
> > > > > > Cc: [e-mail]; Snigdho Bardalai
> > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> > > > > framework-
> > > > > > 01.txt
> > > > > >
> > > > > > Daniele,
> > > > > >
> > > > > > Please, see in line.
> > > > > >
> > > > > > Cheers,
> > > > > > Igor
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Daniele Ceccarelli
> [mailto:[e-mail]]
> > > > > > Sent: Monday, July 19, 2010 10:31 AM
> > > > > > To: Igor Bryskin; Fatai Zhang; [e-mail]
> > > > > > Cc: [e-mail]; Snigdho Bardalai
> > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> > > > > framework-
> > > > > > 01.txt
> > > > > >
> > > > > > Hi Igor,
> > > > > >
> > > > > > I didn't understand if you're proposing to (a) send an ISCD
> per
> > > > role
> > > > > > (i.e. OTN_HO_SC, OTN_LO_SC) or (b) an ISCD per role per
> signal
> > > > type.
> > > > > >
> > > > > > IB>> in ISCD:
> > > > > > switchCap =3D role;
> > > > > > encodeType =3D muxCap & signal type; We also have 16
> > > > > > reserved bits which can use for OTN specific
> info
> > > > in
> > > > > > case we need it.
> > > > > [SCB] I am yet to clearly understand what the role of "role"
> is, but
> > > > > agree with your observation on the encode-type and the 16
> > > > > reserved-bits to further classify the switching information.
> > > > > >
> > > > > > In case (a) you're still missing a lot of information. For
> each
> > > > role
> > > > > > you would advertise just the unreserved bandwidth but you
> wouldn't
> > > > > know
> > > > > > if such bandwidth is available for a certain type of ODUj
> > > > > > LSP
> (e.g.
> > > > > 15
> > > > > > Gbps available on 3 component links: you advertise 45 Gbps
> > > > available
> > > > > > but no ODU3 can be set up on such TE link).
> > > > > >
> > > > > > In case (b) the number of ISCDs would cause serious
> scalability
> > > > > issues
> > > > > > and the requirement of being able to bundle component links
> > > > together
> > > > > > wouldn't be satisfied.
> > > > > >
> > > > > > IB>> Disagree. ISCD is a relatively small subTLV, several
> ISDCs
> > > > will
> > > > > > provide a lot of flexibility: you can specify different
> things
> > > > (e.g.
> > > > > > available bandwidth) for the same link in different roles.
> > > > > [SCB] Are you saying the ISCD as defined today with minor
> extensions
> > > > > (i.e. to further classify the information) will be sufficient?
> > > > > >
> > > > > > Cheers,
> > > > > > Daniele
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail] [mailto:[e-mail]]
> On
> > > > > Behalf
> > > > > > Of Igor Bryskin
> > > > > > Sent: luned=EC 19 luglio 2010 15.40
> > > > > > To: Fatai Zhang; [e-mail]
> > > > > > Cc: [e-mail]; Snigdho Bardalai
> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> > > > > framework-
> > > > > > 01.txt
> > > > > >
> > > > > > Fatai,
> > > > > >
> > > > > > Please, see my responses on-line.
> > > > > >
> > > > > > Cheers,
> > > > > > Igor
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail] [mailto:[e-mail]]
> On
> > > > > Behalf
> > > > > > Of Fatai Zhang
> > > > > > Sent: Sunday, July 18, 2010 10:49 PM
> > > > > > To: Igor Bryskin; [e-mail]
> > > > > > Cc: [e-mail]; Snigdho Bardalai
> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> > > > > framework-
> > > > > > 01.txt
> > > > > >
> > > > > > Hi Igor,
> > > > > >
> > > > > > Thanks.
> > > > > > I understand what you said. Therefore, we have added some
> text to
> > > > > > address the requirment in FWK document. However, we still
> don't
> > > > > > think that we need to extend ISC to meet the requirment. The
> role
> > > > of
> > > > > > the
> > > > > ODU
> > > > > > can be get from the routing information implicitly. In the
> [draft-
> > > > > > ceccarelli-ccamp-gmpls-ospf-g709-02] draft, a kind of  "Full
> > > > Lambda"
> > > > > is
> > > > > > introduced.
> > > > > >
> > > > > > IB>> This is possible, however:
> > > > > > a) this requires OTN specific advertising and processing
> rules;
> > > > > > b) disallows topology separation in technology independent
> way
> > > > > >
> > > > > > A quick question on your statement: "the role of an ODU
> container
> > > > > does
> > > > > > not change hop-by-hop (as some people seem to believe). The
> role is
> > > > > > only meaningful on the ODU terminating nodes and irrelevant
> on
> > > > > transit
> > > > > > nodes. It is it's position in the hierarchy (but not role)
> that may
> > > > > > change hop-by-hop. "
> > > > > >
> > > > > > For example, A(AI1)----(BI1)B(BI2)----(CI1)C,  Interfaces
> > > > > > AI1
> and
> > > > > > CI1 can support Ho ODU2 and Lo ODU2, However, BI1 and BI2
> > > > > > can
> only
> > > > > support
> > > > > > Lo ODU2 (the role is Lo OTN Level). If a connection ODU2
> > > > > > with
> the
> > > > > role
> > > > > > of Ho ODU level is requested,  according to your statement,
> this
> > > > > > conneciton will be allowed to be created. However, it should
> not be
> > > > > > allowed because the ISC is not consistent along the LSP.
> > > > > >
> > > > > > IB>> No, your understanding is not correct. A11 and C11 TE
> link
> > > > ends
> > > > > > will be advertised with two ISCDs: OTN_HO_SC and OIN_LO_SC,
> while
> > > > > > B11 and B12 - only with a single ISCD: OTN_LO_SC. If the
> > > > > > path computation is constrained to the OTN_HO_SC topology,
> > > > > > B11 and
> B12
> > > > TE
> > > > > > links will
> > > > > be
> > > > > > disallowed, and the resulting path (if any) will not go
> through B11
> > > > > and
> > > > > > B12. If one circumvents the path computation by providing
> > > > > > the
> fully
> > > > > > explicit path, the signaling should fail on node B for the
> same
> > > > > reason:
> > > > > > inconsistency of required (signaled) and supported (by local
> > > > > > interfaces) switchcap.
> > > > > >
> > > > > > Please see the text from RFC3473:   "Nodes MUST verify that
> the
> > > > type
> > > > > > indicated in the Switching Type  parameter is supported on
> the
> > > > > > corresponding incoming interface.  If  the type cannot be
> > > > supported,
> > > > > > the node MUST generate a PathErr message with a "Routing
> > > > > > problem/Switching Type" indication."
> > > > > > IB>> Indeed
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Best Regards
> > > > > >
> > > > > > Fatai
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Igor Bryskin" <[e-mail]>
> > > > > > To: "Fatai Zhang" <[e-mail]>;
> > > > > > <[e-mail]>
> > > > > > Cc: "John E Drake" <[e-mail]>; "Snigdho Bardalai"
> > > > > > <[e-mail]>; "Lou Berger" <[e-mail]>;
> > > > > > <[e-mail]>; <draft-ietf-ccamp-gmpls-g709-
> > > > > > [e-mail]>
> > > > > > Sent: Friday, July 16, 2010 12:34 AM
> > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> > > > > framework-
> > > > > > 01.txt
> > > > > >
> > > > > >
> > > > > > Fatai,
> > > > > > Please, see my answers in line.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Fatai Zhang [mailto:[e-mail]]
> > > > > > Sent: Wednesday, July 14, 2010 9:52 PM
> > > > > > To: Igor Bryskin; [e-mail]
> > > > > > Cc: John E Drake; Snigdho Bardalai; Lou Berger;
> [e-mail];
> > > > > draft-
> > > > > > [e-mail]
> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> > > > > framework-
> > > > > > 01.txt
> > > > > >
> > > > > > Hi Igor and all,
> > > > > >
> > > > > > Thanks for all your comments.
> > > > > >
> > > > > > I think role does not equal switching capability. The
> operators can
> > > > > > define different roles depending on their policy and achieve
> the
> > > > > > role through different methods. However, for OTN networks,
> the
> > > > > > containers (e.g., ODUk) all have the same switching
> capablility
> > > > > > (i.e., TDM
> > > > > > switching) and I think we should reflect the natural
> > > > characteristics
> > > > > of
> > > > > > links in the routing. In addition, if we extend the ISC, it
> will
> > > > > > make the encoding type lose its' own meaning(ie., ISC
> overrides
> > > > > > encoding type).
> > > > > >
> > > > > > IB>> When a GMPLS CP instance controls several layers, it
> views the
> > > > > > network as a stack of topologies. Whether a given topology
> > > > > > is
> real
> > > > > > or virtual is of no importance.
> > > > > > The GMPLS ISCD link sub-tlv and, in particular, its
> > > > > > switching capability field (confusing name as it is) is a
> > > > > > good way to
> > > > describe
> > > > > a
> > > > > > layer in technology independent way, so that, say, MPLS-TP-
> >OTN_LO-
> > > > > > >OTN_HO->OTN_SHO->WDM layer stack could be perceived as a
> stack of
> > > > > > topologies that could be easily separated in technology
> independent
> > > > > way
> > > > > > should path computation be constrained to particular one or
> > > > > > sub-stack of them.
> > > > > > I think a good way to identify an OTN (virtual) topology is
> via
> > > > > > (infrastructure) ODU container role of ODUs comprising the
> > > > topology.
> > > > > > BTW IMO the role of an ODU container does not change hop-by-
> hop (as
> > > > > > some people seem to believe). The role is only meaningful on
> the
> > > > ODU
> > > > > > terminating nodes and irrelevant on transit nodes. It is
> > > > > > it's
> > > > > position
> > > > > > in the hierarchy (but not role) that may change hop-by-hop.
> ODU's
> > > > > role
> > > > > > is the level of topology it is provisioned for and it is the
> same
> > > > > > for all ODUs that comprise the topology. For, example a user
> may
> > > > > provision
> > > > > > a LO topology and constrain ODUs he sells to a set of
> > > > > > clients
> to
> > > > use
> > > > > > the topology rather than any resources available on OTN
> network.
> > > > > > The bottom line: container's role is the same as the role of
> > > > virtual
> > > > > > topology the container is a part of and could be advertised
> as the
> > > > > > corresponding link switchcap.
> > > > > >
> > > > > > According to the point 3, I don't know how to advertise the
> roles
> > > > > > and muxing capabilities with the ISCD of RFC4202, could you
> > > > clarify?
> > > > > >
> > > > > > IB>> switchcap =3D ODU role (e.g. LO_OTN_SC, HO_OTN_SC,
> > > > > > IB>> etc.)
> > > > > >      encoding type =3D mux. capabilities code
> > > > > >
> > > > > > In addition, could you clarify my questions in another email
> > > > (copied
> > > > > as
> > > > > > follows):
> > > > > >
> > > > >
> > > >
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> >
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> 3
> D=3D=
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > =3D
> > > > > >
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > =3D=3D=3D=3D=3D=3D=3D
> > > > > > For  Lo ODU, Ho ODU, SHO ODU, they are relative to each
> other.
> > > > > > IB>> I disagree. You define role =3D=3D position in the
> hierarchy,
> > > > which
> > > > > is
> > > > > > a mistake IMO.
> > > > > >
> > > > > > For example, ODU1->ODU2->ODU3->ODU4, how to regard ODU2 or
> ODU3 as
> > > > > > Ho OTN Level or Lo OTN Level? Another example is, if there
> > > > > > is
> a
> > > > OTU3
> > > > > link
> > > > > > supporting ODU2 switching, which can be used as Lo ODU2
> (service
> > > > > > over
> > > > > > ODU2 directly) and Ho ODU2 (ODU1 is over this ODU2), in this
> case,
> > > > > how
> > > > > > to differentiate if this ODU2 is Lo OTN Level or Ho OTN
> Level?
> > > > > >
> > > > > > IB>> As I mentioned earlier, ODU role is only important on
> the ODU
> > > > > > terminating nodes (i.e. on either side of corresponding
> link). What
> > > > > > happens on the ODU transit nodes and its place in the
> hierarchy on
> > > > > the
> > > > > > transit nodes are of no importance. My LO container can be
> carried
> > > > > > by somebody else's LO container and can carry my client's LO
> > > > container.
> > > > > To
> > > > > > some extent it is similar to MPLS LSP role: LSP always has a
> role
> > > > > (e.g.
> > > > > > PW LSP or TE- LSP) and it could be anywhere in MPLS stack
> along its
> > > > > > path.
> > > > > >
> > > > > > Cheers,
> > > > > > Igor
> > > > > >
> > > > > >
> > > > >
> > > >
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> >
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> 3
> D=3D=
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > =3D
> > > > > >
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > =3D=3D=3D=3D=3D=3D
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > Fatai
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Igor Bryskin" <[e-mail]>
> > > > > > To: <[e-mail]>
> > > > > > Cc: "John E Drake" <[e-mail]>; "Snigdho Bardalai"
> > > > > > <[e-mail]>; "Fatai Zhang"
> <[e-mail]>;
> > > > > > "Lou Berger" <[e-mail]>; <[e-mail]>;
> > > > > > <draft-ietf-ccamp-
> > > > > gmpls-
> > > > > > [e-mail]>
> > > > > > Sent: Wednesday, July 14, 2010 10:36 PM
> > > > > > Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> > > > > framework-
> > > > > > 01.txt
> > > > > >
> > > > > >
> > > > > > Curtis,
> > > > > >
> > > > > > Thanks for your comment.
> > > > > >
> > > > > > I agree that there should be multiple OTN specific encoding
> types
> > > > > > introduced. But IMO they should indicate the link's mux
> > > > capabilities
> > > > > > rather than the link's role (i.e. level in the OTN hierarchy:
> LO,
> > > > > > HO, SHO, etc.). The link's role or roles IMO should be
> indicated
> > > > > > with a separate switchcaps. I can give you several reasons:
> > > > > >
> > > > > > 1. Links with the same mux capabilities may have different
> roles;
> > > > 2.
> > > > > > Link may advertise several roles (e.g. HO and SHO) with
> different
> > > > > > mux.capabilities per role; 3. Link's role and mux.
> capabilities can
> > > > > be
> > > > > > advertised with ISCDs as defined in RFC4202 (no OTN-style
> ISCD is
> > > > > > required); 4. The combination of swicthcaps and encoding
> > > > > > type
> will
> > > > > look
> > > > > > to CP as a separate layer, which is exactly how ITU models
> OTN
> > > > > > hierarchies in all aspects but routing (!?) 5. If the
> operator
> > > > would
> > > > > > want to constrain the routing of OTN connections to pre-
> configured
> > > > > > topology with a specific role (e.g. constrain all ODUs it
> sells to
> > > > > the
> > > > > > clients to one or more pre-configured LO topologies), this
> would be
> > > > > > possible to do in a technology independent way. Suppose an
> instance
> > > > > of
> > > > > > GMPLS CP manages WDM and OTN NEs. Then separation of LO from
> HO OTN
> > > > > > links will be no different from the separation of WDM links
> from
> > > > > OTUs.
> > > > > >
> > > > > > Cheers,
> > > > > > Igor
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail] [mailto:[e-mail]]
> > > > > > Sent: Tuesday, July 13, 2010 6:24 PM
> > > > > > To: Igor Bryskin
> > > > > > Cc: John E Drake; Snigdho Bardalai; Fatai Zhang; Lou Berger;
> > > > > > [e-mail]; draft-ietf-ccamp-gmpls-g709-
> > > > [e-mail]
> > > > > > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> > > > > framework-
> > > > > > 01.txt
> > > > > >
> > > > > >
> > > > > > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D1E1FE@atl-
> srv-
> > > > > > exgen.atl.advaoptical.com>
> > > > > > Igor Bryskin writes:
> > > > > > >
> > > > > > > I think OTN links require more than one switchcaps: as
> > > > > > > many
> as
> > > > the
> > > > > > depth of the deepest possible OTN DP hierarchy, for example:
> > > > > > >
> > > > > > > typedef enum
> > > > > > > {
> > > > > > >    LSPSwitchType_Unknown =3D0            /* Unknown */
> > > > > > >    , LSPSwitchType_PSC_1 =3D1            /* PSC-1 */
> > > > > > >    , LSPSwitchType_PSC_2 =3D2            /* PSC-2 */
> > > > > > >    , LSPSwitchType_PSC_3 =3D3            /* PSC-3 */
> > > > > > >    , LSPSwitchType_PSC_4 =3D4            /* PSC-4 */
> > > > > > >    , LSPSwitchType_L2SC  =3D50           /* L2SC */
> > > > > > >    , LSPSwitchType_TDM   =3D100          /* TDM */
> > > > > > >
> > > > > > > /*****/
> > > > > > >    , LSPSwitchType_OTN_LO=3D124   /* OTN low order */
> > > > > > >    , LSPSwitchType_OTN_HO=3D125   /* OTN high order */
> > > > > > >    , LSPSwitchType_OTN_SHO=3D126  /* OTN super high order
> */
> > > > /*****/
> > > > > > >    , LSPSwitchType_LSC   =3D150          /* LSC */
> > > > > > >    , LSPSwitchType_FSC   =3D200          /* FSC */
> > > > > > > }e_LSPSwitchType;
> > > > > >
> > > > > >
> > > > > > It would be better IMHO to keep the Switch Type as TDM and
> make the
> > > > > > Encoding Type OTN_LO, OTN_HO or OTN_SHO.
> > > > > >
> > > > > > This would replace the 20006 OTN Encoding Type for G.709
> Digital
> > > > > > Path layer and G.709 Optical Channel layer for 2009 OTN,
> which had
> > > > > > in turn replaced the Encoding Type of "Digital Wrapper" a
> long time
> > > > ago.
> > > > > >
> > > > > > Replacing the Encoding Type would insure that any LSR that
> did not
> > > > > > understand what the TS type meant did not try to multiplex
> its LO
> > > > > > ODU at TS granularity 2.5 onto a HO ODU that had alraedy
> commited
> > > > to
> > > > > using
> > > > > > a 1.25 TS granularity for another LO ODU.
> > > > > >
> > > > > > It could also be stated that if an LSR advertises OTN_LO,
> OTN_HO or
> > > > > > OTN_SHO FA, and also advertises G.709 Digital Path FA, then
> the
> > > > > latter
> > > > > > is for backward compatibility and should be ignored if
> OTN_LO,
> > > > > > OTN_HO or OTN_SHO is understood.  If the LSR commits to 1.25
> TS
> > > > > > granularity, then the corresponding G.709 Digital Path FA
> > > > > > can
> be
> > > > withdrawn.
> > > > > >
> > > > > > The Encoding type would be the lower encoding at each end of
> the
> > > > LSP
> > > > > > regardless of what goes on in the middle since that
> determines what
> > > > > can
> > > > > > be wrapped inside it.
> > > > > >
> > > > > > For example:
> > > > > >
> > > > > >                         OTU3
> > > > > >               OTU2      ODUk=3D3 --------------
> > > > > >    OTU1       ODUk=3D2 -- ODUj=3D2
> > > > > >    ODUk=3D1 --- ODUj=3D1 --
> > > > > >
> > > > > > This is OK and the outer ODUk=3D1 could hold a ODUj=3D0 or
> ODUj=3Df=
> > lex
> > > > > > even though the ODUk=3D2 at the next hop could not directly
> contain
> > > > an ODU0.
> > > > > > If the SHO Encoding Type is used, then it indicates that two
> levels
> > > > > of
> > > > > > multiplexing could be supported at that switch/LSR.
> > > > > >
> > > > > > The nominal bytes/sec rates can still be provided.  RFC 4328
> Switch
> > > > > > Types currently don't include an ODUj or ODUk distinction
> > > > > > but
> if
> > > > > > Encoding Type indicated LO or HO, that may not be needed.
> Along
> > > > > > with the new Encoding Type new Signal Types for ODU0, ODU4,
> and
> > > > > > ODU-flex, and ODU2e, can be added.
> > > > > >
> > > > > > btw - the 1.25 or 2.5 TS type is a valuable addition but I'm
> not
> > > > > clear
> > > > > > how in an FA it can be indicated that either type is
> currently
> > > > > > available (NE capable of both and hasn't committed to either
> one
> > > > > yet).
> > > > > >
> > > > > > BTW- Maybe I'm missing something but the number of messages
> on this
> > > > > > would indicate a huge controversy and I'm not getting it
> (other
> > > > than
> > > > > a
> > > > > > strong preference to rely on bytes/sec or on enumerated type
> > > > fields).
> > > > > >
> > > > > > draft-bccg-ccamp-otn-g709-info-model-01 is nice work.  I'm
> not sure
> > > > > if
> > > > > > the intent is to merge with draft-ietf-ccamp-gmpls-g709-
> framework,
> > > > > > or other intent.  Could someone (either draft) concisely
> summarize
> > > > > > the multiplexing restrictions in one place, including
> restrictions
> > > > > > on number of multiplexing layers at one LSR.  That might
> help.
> > > > > >
> > > > > > Curtis
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: John E Drake [mailto:[e-mail]]
> > > > > > > Sent: Thursday, July 08, 2010 1:59 PM
> > > > > > > To: Igor Bryskin; Snigdho Bardalai; Fatai Zhang; Lou
> > > > > > > Berger
> > > > > > > Cc: [e-mail];
> > > > > > > [e-mail]
> > > > > > > Subject: RE: [CCAMP] Comment on
> > > > > > > draft-ietf-ccamp-gmpls-g709-framework-01.txt
> > > > > > >
> > > > > > > What do you mean by "different switchcaps"?
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: [e-mail] [mailto:ccamp-
> [e-mail]] On
> > > > > > > > Behalf Of Igor Bryskin
> > > > > > > > Sent: Thursday, July 08, 2010 10:53 AM
> > > > > > > > To: Snigdho Bardalai; Fatai Zhang; Lou Berger
> > > > > > > > Cc: [e-mail];
> > > > > > > > [e-mail]
> > > > > > > > Subject: Re: [CCAMP] Comment on
> > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-
> > > > > > > > 01.txt
> > > > > > > >
> > > > > > > > Snigdho,
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > =D8  I think we need to sort out the issues with the
> framework
> > > > > > > > document before we can embark on any proposals to the
> problem.
> > > > I
> > > > > am
> > > > > > > > still not clear why do we have to deviate from the
> general
> > > > > approach
> > > > > > > > that has been established in RFC 4202.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > IB>> Agree absolutely. GMPLS is inherently multi-layer
> control
> > > > > > > > IB>> plane, and
> > > > > > > > it is highly desirable to adhere to the layer
> > > > > > > > independent
> > > > > paradigm
> > > > > > > > of advertising of TE links, and there is no reason to
> invent an
> > > > > OTN
> > > > > > > > specific ISCD. The combination of Switching Capability
> and
> > > > > Encoding
> > > > > > > > type of RFC4202 ISCD allows for specifying both
> multiplexing
> > > > > > > > capabilities and OTN layer (LO, HO, SHO) of an OTN link,
> and,
> > > > if
> > > > > > > > this not sufficient, you have another reserved 16 bits.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >Additionally, I do not see any reason to advertise a
> > > > > > > > >new TE-link
> > > > > > to
> > > > > > > > represent >the low-order ODUj bandwidth within the high-
> order
> > > > > > containers.
> > > > > > > > This is simply >blowing up the solution to a very simple
> > > > problem.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > IB>> Here I disagree. In order to give a user
> > > > > > > > IB>> possibility
> to
> > > > > create
> > > > > > > > IB>> OTN
> > > > > > > > hierarchies and constrain LO connections to HO
> containers, one
> > > > > > needs
> > > > > > > > to advertise OTN links with different switchcaps.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > >
> > > > > > > > Igor
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Regards
> > > > > > > >
> > > > > > > > Snigdho
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > From: Fatai Zhang [mailto:[e-mail]]
> > > > > > > > Sent: Wednesday, July 07, 2010 6:33 PM
> > > > > > > > To: Snigdho Bardalai; Lou Berger
> > > > > > > > Cc: [e-mail];
> > > > > > > > [e-mail]
> > > > > > > > Subject: Re: [CCAMP] Comment on
> > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-
> > > > > > > > 01.txt
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi Snigdho and Lou,
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Yes, we have lots of off-line discussions among authors
> and
> > > > > > > > other interested experts, and we think the proposal
> described
> > > > in
> > > > > "draft-
> > > > > > > > ceccarelli-ccamp-gmpls-ospf-g709" [OSPF-Encoding] draft
> is more
> > > > > > > > feasible for OTN networks.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > The framework draft just tells you what information
> needed for
> > > > > > > > control plane, no matter how you encode the routing
> > > > information.
> > > > > > For
> > > > > > > > TDM networks, you know the resource is allocated based
> > > > > > > > on
> TS,
> > > > so
> > > > > > the
> > > > > > > > available TS should be get or induced before creating
> cross-
> > > > > > connect.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > If you are trying to find how to encode the routing
> > > > information,
> > > > > I
> > > > > > > > think you need go to the routing drafts (info model and
> > > > > encoding).
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > If you look at the routing drafts (info model and
> encoding),
> > > > you
> > > > > > > > will find that one of your suggestions is adopted (i.e.,
> simply
> > > > > > > > advertize the available number of ODU0, ODU1, ODU2, ...,
> ODU4
> > > > > > container instances).
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > One more thing for your first comment:
> > > > > > > >
> > > > > > > > If you create an ODU2 LSP (usually over multi OTU3
> > > > > > > > links)
> as FA
> > > > > for
> > > > > > > > ODU1, you have to advertise a new TE link or put this FA
> as a
> > > > > > > > component link of an existing TE link (like RFC4206bis).
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Best Regards
> > > > > > > >
> > > > > > > > Fatai
> > > > > > > >
> > > > > > > >
> > > > > > > > ----- Original Message -----
> > > > > > > >
> > > > > > > > From: "Snigdho Bardalai" <[e-mail]
> > > > > > > > <mailto:[e-mail]> >
> > > > > > > >
> > > > > > > > To: "Lou Berger" <[e-mail]
> <mailto:[e-mail]> >
> > > > > > > >
> > > > > > > > Cc: <[e-mail] <mailto:[e-mail]> >;
> > > > > > > > <draft-ietf-ccamp-gmpls- [e-mail]
> > > > > > > > <mailto:draft-ietf-ccamp-gmpls-g709-
> > > > > > > > [e-mail]> >
> > > > > > > >
> > > > > > > > Sent: Wednesday, July 07, 2010 11:43 PM
> > > > > > > >
> > > > > > > > Subject: Re: [CCAMP] Comment on
> > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-
> > > > > > > > 01.txt
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > Hi Lou
> > > > > > > > >
> > > > > > > > > Thanks, I also would like to hear about the same.
> > > > > > > > >
> > > > > > > > > Snigdho
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Lou Berger [mailto:[e-mail]]
> > > > > > > > > Sent: Wednesday, July 07, 2010 8:37 AM
> > > > > > > > > To: Snigdho Bardalai
> > > > > > > > > Cc: [e-mail] <mailto:[e-mail]> ;
> > > > > > > > > draft-ietf-ccamp-gmpls-
> > > > > > > > [e-mail] <mailto:draft-ietf-ccamp-
> gmpls-
> > > > > g709-
> > > > > > > > [e-mail]>
> > > > > > > > > Subject: Re: [CCAMP] Comment on
> > > > > > > > > draft-ietf-ccamp-gmpls-g709-framework-
> > > > > > > > 01.txt
> > > > > > > > >
> > > > > > > > > Snigdho,
> > > > > > > > > I believe there has been some off-line discussion on
> how to
> > > > > > better
> > > > > > > > > align the work with 4202.  Use of common approaches is
> of
> > > > > course
> > > > > > > > > one of the main objectives of *C*CAMP.  I look forward
> to
> > > > > hearing
> > > > > > > > > from the draft and discussion contributors on there
> progress
> > > > > > > > > on
> > > > > > this point.
> > > > > > > > >
> > > > > > > > > Lou
> > > > > > > > >
> > > > > > > > > On 7/6/2010 3:59 PM, Snigdho Bardalai wrote:
> > > > > > > > >> Hello,
> > > > > > > > >>
> > > > > > > > >> I have a comment and a question on Section 3.1.2.1.
> This
> > > > > section
> > > > > > > > >> describes the link-parameters that are required for
> OTN
> > > > > service
> > > > > > > > >> routing purposes.
> > > > > > > > >>
> > > > > > > > >> My comment is how are we going to advertise the low-
> order
> > > > > > > > >> ODUj availability within a higher-order container.
> > > > > > > > >> For example, consider an
> > > > > > > > >> OTU3 link which has 16 time-slots of 2.5G granularity
> and
> > > > > > > > >> then
> > > > > > we
> > > > > > > > >> establish an ODU2 service over the link. At this
> > > > > > > > >> point
> in
> > > > > > > > >> time the OTU3 link has 12 time-slots available for
> ODU2
> > > > > > > > >> services
> > > > > and
> > > > > > > > >> up to 12+4 time-slots available for ODU1 services (4
> ODU1s
> > > > > > > > >> are contained over the ODU2). So it is obvious from
> this
> > > > > > > > >> example
> > > > > > that
> > > > > > > > >> the number of time-slots available is different based
> on the
> > > > > > signal-type (i.e. ODU1 and ODU2).
> > > > > > > > >> How do we address this issue based on the approach
> specified
> > > > > in
> > > > > > > > >> the
> > > > > > > > draft?
> > > > > > > > >>
> > > > > > > > >> My other question is why not simply advertize the
> available
> > > > > > > > >> number of ODU0, ODU1, ODU2, ..., ODU4 container
> instances or
> > > > > the
> > > > > > > > >> equivalent bandwidth in bytes/sec within a link? This
> > > > > > > > >> approach seems to be more in-line with the general
> approach
> > > > > > > > >> outlined in RFC-4202. Refer to
> > > > > > > > section
> > > > > > > > >> 3.4 in RFC 4202 for an example that shows multiple
> ISCDs
> > > > > > > > >> being advertised per VC rate for an SDH link. The
> additional
> > > > > > > > >> benefit
> > > > > > is
> > > > > > > > >> that the advertisement is TS size independent and
> hence will
> > > > > > > > >> simplify the implementation.
> > > > > > > > >>
> > > > > > > > >> Regards
> > > > > > > > >>
> > > > > > > > >> Snigdho
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp