Re: Fwd: Comments on GMPLS signalling drafts

[Lou Berger <lberger@movaz.com>]

see comments inline.

At 09:10 PM 12/13/2001, manoj juneja wrote:



> >From: "manoj juneja" <manojkumarjuneja@hotmail.com>
> >To: ccamp@ops.ietf.org
> >Subject: Comments on GMPLS signalling drafts
> >Date: Tue, 11 Dec 2001 16:15:10 -0700
> >
> >Hi All,
> >
> >1. SE-style supported by GMPLS or not ?
> >

GMPLS doesn't modify this.  See the appropriate base protocol docs.

>As labels are the resources on the link, one can't allocate different
> >label to different senders in the same RSVP session.
> >

I don't think you fully understand SE.  I suggest you read the base 
documents. (2205 and RSVP-TE)

>
> >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a
> >separate draft for TDM LSP bandwidth modification but what about the
> >bandwidth modification for other types of LSPs ? There is no mention of
> >these in any of the GMPLS drafts.
> >

GMPLS doesn't modify this.  See the appropriate base protocol docs.

>
> >3. It should be mentioned clearly that waveband section is still not
> >complete in the drafts.
> >
> >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What
> >about the Component_If_Id_Downstream/Upstream TLV ? The revised
> >bundling draft has removed these 2 TLVs. What about the GMPLS signalling
> >drafts ?
> >

It's still in, see the drafts for explanations.

> >5. STM-0 label representation using {SUKLM} should be mentioned in the
> >drafts (because it is a special case).
> >

the sonet draft is the right place for this.  I defer to Eric on this.

>
> >6. It should be mentioned that bandwidth encoding parameter is useful
> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc.
> >
> >7. There is an example scenario for contention resolution in case of bi-
> >directional LSPs. It should be mentioned that  :
> >
> >"contention resolution is an optimization, not a correctness issue ...
> >and no procedure can provide optimal resolution in all cases. An
> >implementor
> >may do differently to provide better resolution."
> >
> >The above quotes are extracted from one of the mails from Fong Liaw.
> >
> >If this is the case then this should be mentioned in the drafts.
> >

Read the Acknowledgments section of the draft.  (I'm sure Fong will be 
happy to see you protecting her interests!)

>
> >8. The LSP hierarchy concept is still not clear. Some days back I posted
> >one
> >doubt related to tunneling of TDM LSP over Lambda LSP using the concept of
> >forwarding adjacency and different people replied with different thoughts.
> >Does this mean this concept is not standardized in GMPLS ?
> >My question was :
> >
> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA
> >established from A to D and if a new TDM LSP request comes to node A
> >which is to be tunneled through the already established lambda FA-LSP
> >then the node A sends the Path/label request message directly to node
> >D. What label the node D will send back to node A in the RESV/label
> >mapping message since the FA-LSP is just one label (lambda) ? Does it
> >mean that all the LSPs which are tunneled through the lambda FA-LSP
> >will be allocated the same label by node D to node A ? If this type of
> >scenario can't exist in GMPLS then please let me know that too."

I believe this topic is being covered in other threads.

> >
> >
> >Regards,
> >manoj.
> >
> >
> >
> >
> >_________________________________________________________________
> >Join the world s largest e-mail service with MSN Hotmail.
> ><http://www.hotmail.com>http://www.hotmail.com
> >
> >
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at 
><http://explorer.msn.com/intl.asp>http://explorer.msn.com/intl.asp.