Re: Moving right along ...

[Zhi-Wei Lin <[e-mail]>]

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
> 
>