Re: Moving right along ...

["manoj juneja" <[e-mail]>]

Hi Dimitri,
            I don't think there is any issue in including the
conversion table in the draft. Even this table can be kept in some
informational draft. The inclusion of conversion table is a valid thing and 
probably nobody on ccamp mailing list would like oppose. I
still didn't get answers to other points in my mail.

Regards,
manoj.


>From: Dimitri Papadimitriou <[e-mail]>
>To: Zhi-Wei Lin <[e-mail]>
>CC: manoj juneja <[e-mail]>, [e-mail],   
>[e-mail]
>Subject: Re: Moving right along ...
>Date: Sat, 20 Oct 2001 16:05:01 +0200
>
>Hi Zhi,
>
>I would like to remember you something here: the SDH/Sonet I-D is not
>1) a textbook on how to use GMPLS-SIG but must be understood an
>    additional document complementing the signalling one
>2) a tutorial on Sonet/SDH (a framework has been proposed for that
>    purpose)
>
>We have spent hard time together with the SDH/Sonet I-D co-authors in
>order to find the best balance between reproducing well known SDH/Sonet
>concepts and paragraphs really providing an added value in this document
>
>Of course we can not make 100% people happy (even between the list of
>30 co-authors) some of us found there was too much explanations while
>others were requesting more content.
>
>Therefore for the non-covered content we are referencing the appropriate
>document either it comes from ITU or IETF. Please understand that we
>can not wait until everybody in this world has no question anymore or a
>full understanding on any technical detail in order to go forward with
>these documents.
>
>Thanks for your "virtual" understanding,
>Dimitri.
>
>Zhi-Wei Lin wrote:
> >
> > Hi Manoj,
> >
> > I agree with many of your points. I actually submitted an I-D several
> > months ago (I think it's expired) that proposes some text to add to the
> > GMPLS SONET/SDH on the rules for setting different values, such as for
> > STS-1-Xv, what is the range of value of X, for VC-4-Xv, what is the
> > range of acceptable value of X, etc.
> >
> > My rationale at that time was that not everyone is a SONET/SDH expert
> > and instead of asking them to look somewhere else and dig through those
> > documents to find the answer, if we can provide them in the GMPLS set of
> > drafts it would be extremely useful for the entire IETF community and
> > would help clarify the usage of these parameters. But unfortunately if
> > you were at the meeting at the time, it wasn't accepted because some
> > folks thought that these were obvious or that this info is not needed
> > because they can find it in other places referenced...
> >
> > If you have the old drafts, the file was:
> > draft-lin-ccamp-ipo-common-label-request-01
> >
> > But anyway...people will just have to read all the referenced documents
> > to understand how to use the different parameters...
> >
> > Zhi
> >
> > manoj juneja wrote:
> >
> > > Hi Kireeti,
> > >            I am not an active member of IETF but a regular reader of
> > > GMPLS drafts. I am not sure how much weight my mail will carry but as 
>a
> > > regular reader of these drafts, I recommend the following points 
>should
> > > be made clear in the documents before proceeding to the last call.
> > >
> > >
> > > 1. Can someone please tell me the usage of bandwidth encoding
> > > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
> > > will be drived from the signal type field. How the bandwidth encoding
> > > type will be interpreted in case of other LSP encoding types (lambda,
> > > waveband, fiber etc) ? The draft should list down the cases in which 
>the
> > > bandwidth encoding type is to be filled.
> > >
> > > 2. Usage of Label Set :
> > >        There are cases mentioned in the draft which explains the usage
> > > of label set. It should also mention that the range of labels in
> > > SDH/SONET does not make sense. Ranges in label set are applicable in
> > > case of waveband/lambda switching etc. The range in label set is valid
> > > in SDH/SONET only if there is one element in the range i.e. start 
>range
> > > and end range should be same.
> > >
> > > 3. There are couple of scenarios where there can be contention for
> > > establishing bi-directional LSPs. All the scenarios are not listed in
> > > the document. If it is not possible to list all the scenarios then the
> > > draft should say that this is one of the example scenario. The
> > > contention can also be possible in case where same label set and
> > > upstream label are used in both the directions.
> > >
> > > 4. As per OIF, the carrier requirement is that SDH LSPs should be
> > > either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS
> > > supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean 
>GMPLS
> > > has different set of carrier requirements in this regard ?
> > >
> > > 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table as
> > > an addendum to the draft.
> > >
> > > 6. The relation between switching capability and LSP encoding type
> > > should be clearly explained in the drafts. As the switching capability
> > > field was added very late (just 2 months back) in the drafts,
> > > specific reason should be mentioned for its addition.
> > >
> > > Regards,
> > > manoj.
> > >
> > >
> > >
> > >> From: Kireeti Kompella <[e-mail]>
> > >> To: [e-mail]
> > >> Subject: Moving right along ...
> > >> Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT)
> > >>
> > >> Despite the energetic subject line, we the WG chairs have been
> > >> lax in our duties.  So, here goes:
> > >>
> > >> Lou has submitted the latest versions of the generalized
> > >> signaling documents quite some time ago (thanks, Lou):
> > >>
> > >> draft-ietf-mpls-generalized-cr-ldp-04.txt
> > >> draft-ietf-mpls-generalized-rsvp-te-05.txt
> > >> draft-ietf-mpls-generalized-signaling-06.txt
> > >>
> > >> Also, Eric has posted the SONET/SDH documents (merci, Eric):
> > >>
> > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > >>
> > >> All of these should have addressed the issues raised in the earlier
> > >> versions.  Please read the new versions, and send your comments to
> > >> the list by Tuesday Oct 23.  At that point, when the final round
> > >> of comments have been addressed, these docs will go to IESG Last
> > >> Call.  If any one objects to sending these docs to IESG Last Call,
> > >> raise your issues now.
> > >>
> > >> I see that the GMPLS architecture document is a CCAMP WG doc, but
> > >> the minutes say that we should look for consensus on the list.  So,
> > >> if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> > >> arrived at a consensus, remind me :-))  If nothing is heard, the doc
> > >> will progress to WG Last Call.
> > >>
> > >> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> > >> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
> > >> CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> > >> list know what your thinking is on these.  (BTW, both these docs
> > >> were to have some edits done.  If the authors could do that before
> > >> the next IETF, we can try to make more progress then.)
> > >>
> > >> The MIB overview doc was recently posted.  Please read and comment
> > >> to the list.
> > >>
> > >> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > >> was generally thought to be useful; it will be published as a
> > >> CCAMP informational doc.  This begins a two week Last Call on
> > >> the doc, ending Tuesday Oct 30.
> > >>
> > >> There was no consensus on whether the GMPLS framework should be
> > >> a CCAMP WG doc.  Please indicate your pleasure.
> > >>
> > >> draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> > >> raised that this draft is close to ready for WG Last Call.  Please
> > >> review it, and let us know if you disagree.
> > >>
> > >> The OLI requirements doc was broadly accepted.  Please let the
> > >> list know if you think this doc should be a WG doc.
> > >>
> > >> It's still open whether we (the IETF) should be working on
> > >> LMP-WDM.  I urge the authors to keep on working on the doc, and
> > >> keeping it in sync with LMP; however, we will postpone making it
> > >> a CCAMP WG doc until the issue is resolved.  Hopefully that will
> > >> happen in Salt Lake City.
> > >>
> > >> There was reasonable interest in the tunnel trace requirements
> > >> doc.  Let's formalize this: do you think this should be made a
> > >> CCAMP WG document?
> > >>
> > >> Summary:
> > >>
> > >> 1) Final comments and IESG Last Call readiness for:
> > >> draft-ietf-mpls-generalized-cr-ldp-04.txt
> > >> draft-ietf-mpls-generalized-rsvp-te-05.txt
> > >> draft-ietf-mpls-generalized-signaling-06.txt
> > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > >>
> > >> 2) Should the following documents be CCAMP WG docs?
> > >> draft-bonica-tunneltrace-02.txt
> > >> draft-fontana-ccamp-gmpls-g709-00.txt
> > >> draft-ietf-ccamp-gmpls-architecture-00.txt
> > >> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > >> draft-many-ccamp-gmpls-framework-00.txt
> > >> draft-many-oli-reqts-00.txt
> > >>
> > >> 3) Comment on MIB overview.
> > >>
> > >> 4) Two week Last Call comments on
> > >> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > >>
> > >> 5) Last Call readiness of
> > >> draft-ietf-ccamp-gmpls-architecture-00.txt
> > >> draft-ietf-ccamp-lmp-01.txt
> > >>
> > >> Thanks,
> > >> Kireeti.
> > >>
> > >
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
> > >
> > >
><< dimitri.papadimitriou.vcf >>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp