SONET/SDH label agreement for IETF, ITU-T and OIF

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

Hi All,

Please note:

The two updated drafts "implementing" the agreement were sent on the CCAMP
mailing list the 14th of December 2001.

> move "Appendix 1 - Signal Type Values Extension For Group 
> Signals" from the sonet-sdh document to the sonet-sdh-extensions document;

Was done and sent on the CCAMP mailing list as said before. I don't seen
where the agreement was not fulfilled (just copy/pasted the appendix to the
non standard draft).

> Afterwards I noticed that the latter agreement is 
> interpreted in different ways

The sentence that was added in the intro to implement the agreement was
reviewed by Maarten. It could certainly be improved, I agree, but this was
the result of several hours of discussions.

"A SONET signal which has an identical SDH signal SHOULD be requested using
the same traffic parameters as for the equivalent SDH signal, and will
consequently use the SDH label."

The key point here is that the LSP Encoding Type (i.e. the circuit type) in
the root GMPLS signaling will indicate either SDH or SONET (xor). It is
impossible to have a double coding since we have an exclusive OR. It is
impossible to interpret it in two different ways.

The sentence above should better speak explicitly in terms of LSP Encoding
Type.

Having said that, there is something magic of having the GMPLS SDH/SONET
specification accepted also by the ITU-T as part of GMPLS for G.ASON
(on-going activity). It would be a pity if the SONET label format prevents
it.

From my humble point of view, and since I understood that ITU-T and ATM
Forum have decided to work on PNNI extensions, there is also something magic
of using the same traffic parameters for GMPLS and PNNI, and moreover at the
IETF, ITU-T, ATM Forum and OIF. That will allow further interoperability
between the GMPLS and the PNNI control planes.

It would be a mistake if these discussions on the label format prevent us to
use the traffic parameter, and moreover if it results in different label
formats between IETF and ITU-T.

If we change the SONET label format there are two issues:

- already used by the OIF for UNI1.0.
- already implemented in many boxes.

The OIF started to work on UNI 2.0 and we could suggest to change the SONET
label such as it is fully identical to the SDH label as part of UNI 2.0.

Is there somebody fundamentally against changing the SONET label format in
the current context ?

I know that these issues are larger than the scope of IETF but it becomes
difficult to work without encompassing the broader scope of also ITU-T, OIF
and now ATM Forum.

I would suggest that Maarten and myself (with the help of Juergen and
Dimitri Papadimitriou) review the two SDH/SONET drafts and reach a FINAL
consensus (as far as we are concerned) such as these documents could be
re-used in different contexts to ensure interoperability. I am confident
that by the end of next week we could republish these two drafts with a very
strong consensus.

Please advice.

Kind regards,

Eric

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Friday, February 22, 2002 3:13 PM
To: Kireeti Kompella; Vijay Gill
Cc: ccamp; Maarten Vissers; Scott Bradner
Subject: RE: SONET/SDH label agreement?


WG chairs, I think Maarten is correct here in the sense
that by now, he (and the WG mailing list) could have 
expected an answer. 

PLEASE act asap.

Bert 

> -----Original Message-----
> From: Maarten Vissers [mailto:mvissers@lucent.com]
> Sent: Friday, February 22, 2002 9:17 AM
> To: Kireeti Kompella; Vijay Gill
> Cc: ccamp; Wijnen, Bert; Scott Bradner
> Subject: Re: SONET/SDH label agreement?
> 
> 
> Kireeti, Vijay,
> 
> On Feb. 8 I send you the email below. So far I haven't 
> received an answer and I
> assume the email has not been received by you or has got at 
> the bottom of the
> stack. As such a resent. Hope you will be able to respond today.
> 
> Thanks,
> 
> Maarten
> 
> Maarten Vissers wrote:
> > 
> > Vijay, Kireeti,
> > 
> > Almost two months ago we met in a small team to address the 
> issues hindering the
> > completion of draft-ietf-ccamp-gmpls-sonet-sdh and
> > draft-ietf-ccamp-gmpls-sonet-sdh-extensions.
> > When this meeting ended, I was convinced we had reached 
> agreement on the way to
> > continue:
> > 
> > - move "Appendix 1 - Signal Type Values Extension For Group 
> Signals" from the
> > sonet-sdh document to the sonet-sdh-extensions document;
> > 
> > - modify the sonet-sdh document such that the SDH traffic 
> parameters and label
> > will be used for SONET signals for which there exists an 
> identical SDH signal.
> > SONET signals for which there is no SDH equivalent will 
> keep using the SONET
> > specific traffic parameters and label.
> > 
> > Afterwards I noticed that the latter agreement is 
> interpreted in different ways:
> > 
> > A) keep both SONET and SDH specific traffic parameter and 
> label specifications
> > in the sonet-sdh document, and let the equipment 
> manufacturer and/or operator
> > choose if the traffic parameters and label for a SONET 
> signal (with identical
> > SDH signal) will use the SONET specification or the SDH 
> specification. This
> > results in a "double coding" scheme for SONET signals.
> > 
> > B) modify the sonet-sdh document such that there is one set 
> of traffic
> > parameters and label for each SONET signal. For those SONET 
> signals with
> > identical SDH signal (i.e. all SONET signals except VT-3) 
> only the SDH traffic
> > parameters and label will be specified. For those SONET 
> signals that do not have
> > an SDH equivalent (i.e. VT-3) the SONET traffic parameters 
> and label will be
> > specified. This results in a "single coding" scheme for 
> SONET signals.
> > 
> > This dual interpretation is again hindering the completion 
> of the sonet-sdh
> > document.
> > 
> > Note that interpretation B) sufficiently meets the request 
> from ITU-T SG15 as
> > laid down in the its communications statement and as such 
> was an acceptable
> > compromise for me.
> > 
> ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport
/COMMUNICATIONS/ccamp/IETF_ccamp_sdhgroup.html
> (note -  I can't find this document on the IETF web site anymore)
> Interpretation A) will at the best require two coding schemes to be
supported in
> each equipment, and at the worst will cause interworking problems. It
doesn't
> meet the request from ITU-T SG15. If I would have been aware of this
> interpretation, I would not have agreed with it.
> 
> May I ask you for your understanding/interpretation on this matter.
> 
> Regards,
> 
> Maarten