Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument status]

[Dimitri.Papadimitriou@alcatel.be]

Eve,

the E-NNI interface is an "administrative" partitioning of the control
plane within the same layer, then additional sub-partitioning are 
provided for design and topology issues but always within the same
layer (to be brief, the latter is what g.8080 refers to as I-NNI). I 
refer here to g.8080 "The transport plane is also partitioned to match 
the administrative domains." since it is a partitioning the model lies 
on the same layer. My remark focus on the client-server-client (router-
to-XC-to-router, to be more illustrative) where the call-connection
separation applies, to be even more clear this is recursive, meaning
that for instance (SDH-to-G.709-to-SDH, to be illustrative) also 
requires call-connection separation.

hope this clarifies,
- dimitri.

Eve Varma wrote:
> 
> Hi Dimitri,
>    Just a quick note re information flows per G.807 - it is correct that for the
> UNI reference point, network routing information is not provided; typical info
> flows include policy and endpoint information.  However, for the E-NNI reference
> point expected info flows include reachability/summarization info, and for the
> I-NNI ref. point topology and routing information is expected.
>                                         Cheers,
>                                             Eve
> 
> Dimitri.Papadimitriou@alcatel.be wrote:
> >
> > Bert,
> >
> > i see many issues, the statement refers to "call" while from the
> > ietf terminology, this term is referred to as "session"; as such
> > it could be appropriate from our side to review the statement
> > made in the "ITU liaison" because the proposed separation plugs
> > a "telephony-oriented" model (or telephony-like model) to a data
> > /circuit switched oriented network - but not with "64kb" - one
> > speak here about connections from 51.84 Mb (more precisely the
> > payload of a C3 is 48384 kbps) to 2.5, 10 or even 40 Gbps !
> > This separation (adapted for public telephony network) is also
> > constructed on an assumption that there is no control plane
> > protocol as we have today with GMPLS protocols but that connection
> > signalling is performed by the transport plane (using embedded
> > signalling) or through management plane. So there is an under-
> > lying fundamental question isn't the G.ASON model only a "public
> > overlay model" and then we have to ask ourself if the scope of
> > GMPLS has to be adapated/restricted to such public networks
> > using an overlay control plane inter-connection: imho, clearly no
> > but what could be considered is a "GMPLS profile" for G.ASON.
> >
> > Moreover this "assumption" resulted to the fact that G.ASON is
> > based on a fundamental assumption: no routing information exchange
> > between the client and server layer. GMPLS does not have such
> > stringent restriction. Consequently, this makes the separation
> > call/connection (while mandatory per requirement in the stringent
> > G.ASON model) not at all mandatory in the IETF scope since the
> > "routing exchanges" fulfill the role played by the call operation:
> > the source knows the status and the availability of the set of
> > destinations it can reach. Since routing is one of the foundation
> > of any data network, i think we should probably also discuss if
> > this separation is adapted for other types of GMPLS networks. In
> > brief, i don't think we have to restrict the ubiquity of the GMPLS
> > protocol suite.
> >
> > Hope this clarifies,
> >
> > regards,
> > - dimitri.
> >
> > "Wijnen, Bert (Bert)" wrote:
> > >
> > > Erik et all, the "official communications from the ITU" are
> > > listed under the Liaison Statements on the IETF Web Page.
> > > The page is at: http://www.ietf.org/IESG/liaison.html
> > >
> > > If you see trouble/issues with any of those, pls let WG chairs and
> > > ADs know, so we can take action.
> > >
> > > Bert
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : dimitri.papadimitriou@alcatel.be
> > Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > Address: Alcatel - Optical NA, Fr. Wellesplein, 1
> >          B-2018 Antwerpen, Belgium
> > Phone:   Work: +32 3 2408491 - Home: +32 2 3434361

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
Address: Alcatel - Optical NA, Fr. Wellesplein, 1 
         B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361