RE: Moving right along ... gmpls-sonet-sdh-02

["Mannie, Eric" <Eric.Mannie@ebone.com>]

Hello Ben,

>1) Under Signal Type there are four transforms described and it
>   is suggested that these four may be applied in the specified
>   order.  I don't think transparency makes much sense after specifying
>   concatenation transforms.  This should be clarified.

We saw that point when we wrote the specification. That's one particular
case where the practical usage of the combination is not the most obvious
:-) We gave examples of that encoding (see examples number 5 and 6).

The point is that this draft is a toolbox. Some tools are more relevant than
others at some time. Technically, if somebody wants a VC-4-4c with the MS
DCC being transported transparently over an STM-64 network, why not ? Maybe
to carry some extra signaling or routing in that DCC. I could think at the
normal IP traffic being transported in the concatenated payload and the
management traffic running over the DCC, why not ? Technically it works fine
and has some benefit (e.g. the DCC may not be congested when the payload may
be congested). I would not bet that nobody is using that feature.

I don't think that it is the job of this draft to explicitly preclude some
scenarios. The concatenation combined with the transparency came also as a
side effect of the generalization of the transforms (to be orthogonal in the
specification). It is just a combination that is available if someone needs
it, not more (and you don't have to support it to be compliant of course).

>2) In the transparency section it states "Section/Regenerator 
>   Section layer transparency means that the entire frames must 
>   be delivered unmodified" and "Line/Multiplex Section layer 
>   transparency means that the LOH/MSOH must be delivered 
>   unmodified."  This would seem to preclude the forms of TDM
>   multiplexing supported by some equipment (e.g., 4xOC-48 into
>   "OC-192").  I think we should add language that allows for 
>   this.

Of course, we wrote also immediately after "This implies that pointers
cannot be adjusted" to attract the attention of the reader on that point
(that wording was validated by our ITU-T folks). We didn't want to put
tutorial information on SDH/SONET in that draft. Note that they are other
types of transparencies that we also defined allowing to combine
multiplexing and transparency as you said (see the SDH/SONET extensions
draft - they are in a separate draft).

Indeed that draft defines some simple general encoding to request circuits.
The beauty of the draft is that while the protocol extension is
straightforward (just a few fields), I don't know any type of circuit that
could not be requested (i.e. any type of circuit can be requested).

Kind regards,

Eric

-----Original Message-----
From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com]
Sent: Tuesday, October 30, 2001 12:03 AM
To: Kireeti Kompella
Cc: ccamp@ops.ietf.org
Subject: Re: Moving right along ... gmpls-sonet-sdh-02



A couple of comments on draft-ietf-ccamp-gmpls-sonet-sdh-02.txt

1) Under Signal Type there are four transforms described and it
   is suggested that these four may be applied in the specified
   order.  I don't think transparency makes much sense after specifying
   concatenation transforms.  This should be clarified.

2) In the transparency section it states "Section/Regenerator 
   Section layer transparency means that the entire frames must 
   be delivered unmodified" and "Line/Multiplex Section layer 
   transparency means that the LOH/MSOH must be delivered 
   unmodified."  This would seem to preclude the forms of TDM
   multiplexing supported by some equipment (e.g., 4xOC-48 into
   "OC-192").  I think we should add language that allows for 
   this.

Regards,
Ben Mack-Crane