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

[John E Drake <[e-mail]>]

Igor,

This sounds like arm waving to me.  To put things in perspective, let's remember that you are the only person that is claiming that an operator wants any of this.  I have seen nothing to date in I-Ds pertaining to OTN that has said any of this is needed.  It is also completely contrary to the ITU modeling work for OTN, which uses a single flat network.  (Of which you were, until recently, completely unaware.)

As a general rule, what should be advertised in the TE database is the type of client signals that can be placed on a given link and not its server characteristics, which are more or less totally irrelevant.

John

> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]
> Sent: Thursday, July 22, 2010 10:13 AM
> To: John E Drake; [e-mail]
> Cc: BELOTTI, SERGIO (SERGIO); [e-mail]; Snigdho Bardalai; Ong,
> Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai
> Zhang
> Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-
> 01.txt
>
> John,
>
> One reason is that ISCD allows for advertising of available LSP
> bandwidth per priority level, which could change for the same OTN link
> depending on role. Coloring won't allow to do so. Also, ISCD encoding
> type allows for encoding the signal type, mux. capabilities, etc.
> without introduction of OTN specific sub-TLVs. We want to help operator
> to provision  topologies, ID them and provide a simple way to constrain
> a given LSP to be routed within a topology.  ISCD gives you a simple
> way to do so in a technology independent way, so that constraining LSP
> to belong, say, OTN_LO or OTN_HO topology will not be different from
> constraining LSP to belong to, say, ETH_EVPL layer.
>
> Igor
>
> -----Original Message-----
> From: John E Drake [mailto:[e-mail]]
> Sent: Thursday, July 22, 2010 12:19 PM
> To: [e-mail]; Igor Bryskin
> Cc: BELOTTI, SERGIO (SERGIO); [e-mail]; Snigdho Bardalai; Ong,
> Lyndon; Daniele Ceccarelli; Snigdho Bardalai; Varma, Eve L (Eve); Fatai
> Zhang
> Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-
> 01.txt
>
> Igor,
>
> There is no reason to define multiple ISCD values for OTN networks in
> order to constrain the path of a given LSP to only certain links.  The
> right way to do this is link colors (nee Administrative Groups, defined
> in RFC 3630), which is what it was designed to do.
>
> I know this is a radical thought but why don't we use ISCD for what it
> was designed to do?
>
> Thanks,
>
> John
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Wednesday, July 21, 2010 2:38 PM
> > To: Igor Bryskin
> > Cc: BELOTTI, SERGIO (SERGIO); [e-mail]; Snigdho Bardalai; Ong,
> > Lyndon; Daniele Ceccarelli; John E Drake; [e-mail]; Snigdho
> > Bardalai; Varma, Eve L (Eve); Fatai Zhang
> > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > 01.txt
> >
> >
> > Igor,
> >
> > A current solution would be to use ML/MT extensions.  A GMPLS E-NNI
> > could also solve this problem if designed to isolate clients and
> > resources in this manner.
> >
> > No hacking of RFC 4203 is needed.  No (new) warts need to be added.
> >
> > Curtis
> >
> >
> > In message <052C67B4ED558D41BBDEA7CA9FC6DCDC53C0D763B5@atl-srv-
> > exgen.atl.advaoptical.com>
> > Igor Bryskin writes:
> >
> > Hi Sergio,
> >
> > I'd like to run with you the following logic.
> >
> > 1. Suppose an operator after some planning decides to provision an
> > infrastructure ODU and use it as a link. Why would he do so?  One
> > reason that I can think of is because he wants to build a virtual
> > topology for a set of clients (with possibly himself as one from the
> > set). The purpose of this topology, generally speaking,  is:
> > a)      To be non-congruent with underlying topology (virtual or
> > OTU/OCh). For example, to interconnect nodes that do not have a
> common
> > OTU/OCh link;
> > b)      To constrain said set of clients to resources of the topology
> > (rather than, for example, to use OTU/OCh links directly).
> > The question is how the operator can constrain the routing of the
> ODUs
> > for the clients from the set to the prepared for this purpose virtual
> > topology within the flat ITU routing model?
> >
> > 2. Would you agree that the only reason why a TE link advertises an
> > attribute is to be able to constrain a path computation based on the
> > attribute? Your definitions of the OTN encoding types, for example,
> > are:
> > "     ....
> >       o 8 - Lambda (Photonic)
> >       o 12 - G.709 ODUk (Digital Path)
> >       ....
> > "
> >
> > which will give the operator an ability to route an OTN connection
> > either straight over OTUs or over infrastructure ODUs with no regard
> to
> > the roles assigned to the links. Do you believe this would be
> flexible
> > enough for the operator?
> >
> > 3. What is it you can achieve with the suggested OTN routing that can
> > not be achieved using multiple 4203 ISCDs?
> >
> > Thanks,
> > Igor
> >
> >
> > -----Original Message-----
> > From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-
> > lucent.com]
> > Sent: Wednesday, July 21, 2010 10:59 AM
> > To: Igor Bryskin
> > Cc: [e-mail]; Snigdho Bardalai; Ong, Lyndon; Daniele
> Ceccarelli;
> > John E Drake; [e-mail]; Snigdho Bardalai; Varma, Eve L (Eve);
> > Fatai Zhang
> > Subject: R: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-
> > 01.txt
> >
> > Igor,
> >
> > For point 1) and 2) I do not think we are so far.
> > You're proposing a three-layer approach , we are aligned with what
> ITU
> > is proposing but we also have different roles in the network (lambda
> > and sub-lambda) and than needs for constrains and policy in the
> > network.
> > The fact to have three switching capability to characterize the
> > different roles in the same technology it seems to me a little
> against
> > the concept of switching capability itself.
> > You could say that for packet there is already 4 PSC SC defined. But
> > here we are in TDM , we have not label stacking capability.
> >
> > For point 3) and 4) , I do not discuss about the generality or not of
> > the issue, but surely you cannot negate that the problem of spatial
> > allocation is raised as soon as SDH CP has been implemented . Then
> the
> > same problem come in for OTN , and your intention to cope the issue
> in
> > a generic way with modifications of RFC 4203 is a good intention, but
> > take also into account that also our proposed format can be generic
> as
> > soon as you change the signal types supported.
> >
> > You're right we need to discuss face to face but my perception is
> that
> > we ca be less far than you believe.
> >
> > Cheers
> >
> > Sergio
> >
> > Sergio Belotti
> >
> > System Architecture
> > Optics Division-Terrestrial Optics Unit
> > ALCATEL-LUCENT
> >
> > [phone]
> > [phone]
> >
> >
> > -----Messaggio originale-----
> > Da: [e-mail] [mailto:[e-mail]] Per conto
> di
> > Igor Bryskin
> > Inviato: mercoledì 21 luglio 2010 15.51
> > A: Ong, Lyndon; Daniele Ceccarelli; John E Drake; [e-mail];
> > Snigdho Bardalai
> > Cc: [e-mail]; Snigdho Bardalai
> > Oggetto: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-
> framework-
> > 01.txt
> >
> > 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:ccamp-
> > [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:ccamp-
> > [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- g709-
> [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
> >
> > _______________________________________________
> > CCAMP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ccamp
> >