Re: Moving right along ...

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

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