[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Guys... I have seen to much of this. I have asked Kireeti
EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
WG mailing list. I do NOT want another 500 emails going back
and forth on this issue. We need to approach this pragmatically.
- WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the
WG mailing list on what exactly we agreed in SLC. That will
help to prepare a response to ITU-T as well
- Based on that WG chairs try to get (rough) CONSENSUS CALLED OUT
on the WG mailing list on the exact text.
- Then Eric (editor) makes the changes as per CONSENSUS
- Then we're done.
Sorry that I need to step in, but this has been going on TOO long.
Bert
speaking as AD
> -----Original Message-----
> From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
> Sent: Friday, February 22, 2002 5:03 PM
> To: 'ccamp@ops.ietf.org'
> Cc: 'sob@harvard.edu'; 'mvissers@lucent.com'; 'kireeti@juniper.net';
> 'vijay@umbc.edu'; 'bwijnen@lucent.com'
> Subject: SONET/SDH label agreement for IETF, ITU-T and OIF
> Importance: High
>
>
> 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
>