RE: Editorial comments on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt

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

Hello Juergen,

>Requesting section/line overhead transparency but limiting the paylaod to a
STS-48-c-SPE doesn't make much sense to me.

An STS-48c signal with LOH DCC and E2 transparency is just an example to
illustrate the coding, not more as you said. That's right that this type of
signal is probably not very useful, it is not always easy rto find coding
examples for complex cases that make sense. But anyway, if somebody wants to
have a transparent STS-48c he can.

Of course if you want to have another "organisation" for the payload you can
provision an STS-48 circuit and then structure it as you like.

Kind regards,

Eric

-----Original Message-----
From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de]
Sent: Tuesday, May 29, 2001 2:37 AM
To: Mannie, Eric; 'Saha, Sayandeb'
Cc: 'ccamp@ops.ietf.org'; 'mpls@UU.NET'
Subject: RE: Editorial comments on
draft-ietf-ccamp-gmpls-sonet-sdh-00.txt


Eric,

that was one point I commented onthe draft version of the Sonet/SDH
document. Requesting section/line overhead transparency but limiting the
paylaod to a STS-48-c-SPE doesn't make much sense to me. Transparency at the
line/section layer but not at the path layer. Ok you could code it, but not
everything you can combine is usefull and we better avoid to define such
examples.

Regards

Juergen

> -----Original Message-----
> From:	Mannie, Eric [SMTP:Eric.Mannie@ebone.com]
> Sent:	Wednesday, May 23, 2001 10:08 PM
> To:	'Saha, Sayandeb'
> Cc:	'ccamp@ops.ietf.org'; 'mpls@UU.NET'
> Subject:	RE: Editorial comments on
draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
> 
> Dear Sayan,
> 
> Thanks for the comments. However note that when requesting transparency
for
> an STS-48 signal for instance, the signal type to use is STS-48. You cant'
> concatenate STS-1's since concatenation of STS-1 is not defined, but
> concatenation of STS-1 SPE's is. If you ask the concatenation of 48 x
STS-1
> SPE's you are not speaking about the frame with its overhead, so you
cannot
> request transparency. So we took the decision to use well defined signal
> types when requesting transparency (e.g. STS-48). And we took the
convention
> to indicate in NCC the number of SPE's in that signal that must be
> concatenated. It took us some time to find a way to code each possible
> signal in a non ambiguous way. So I the original examples are correct.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Saha, Sayandeb [mailto:ssaha@netplane.com]
> Sent: Wednesday, May 23, 2001 9:10 PM
> To: Mannie, Eric
> Cc: 'ccamp@ops.ietf.org'; 'mpls@UU.NET'
> Subject: Editorial comments on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt 
> 
> 
> Hi ALL,
> I noticed the following in section 4 of
> draft-ietf-ccamp-gmpls-sonet-sdh-00.txt .
> 
>  The example number 16 is ...
> 
> 16. An STS-48c signal with LOH DCC and E2 transparency is formed
>    by the application of CCT with Type 1, NCC with value 48, NVC with
>    value 0, MT with value 1 and T with flag 5 and 10 to an STS-48
>    Elementary Signal.
> 
> It should be 
> 
>    An STS-48c signal with LOH DCC and E2 transparency is formed
>    by the application of CCT with Type 1, NCC with value 48, NVC with
>    value 0, MT with value 1 and T with flag 5 and 10 to an STS-1 SPE
>    Elementary Signal.
> 
> The example number 17 is ...
> 
> 17. An STS-768c signal with K1/K2 and LOH DCC transparency is
>    formed by the application of CCT with Type 1, NCC with value 768,
>    NVC with value 0, MT with value 1 and T with flag 5 and 7 to an
>    STS-768 Elementary Signal.
> 
> It should be 
> 
>    An STS-768c signal with K1/K2 and LOH DCC transparency is
>    formed by the application of CCT with Type 1, NCC with value 768,
>    NVC with value 0, MT with value 1 and T with flag 5 and 7 to an
>    STS-1 SPE Elementary Signal.
> 
> Regards
> -Sayan
> 
> 
> 
>