Re: Fwd: Comments on GMPLS signalling drafts

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

Hi Sudheer,
            I fully agree with you. My concern was to list down the
GMPLS  features which are completely/fully specified by IETF and are
agreed upon by the IETF community and there is no further conflict for these 
in the industry.
Furthermore, these drafts should also list down the features (in GMPLS
functional Specification draft) which are under discussion/study and
the consensus is yet to be reached. The inclusion of these is very
important and going to help the implementors of GMPLS before moving
forward for RFC status.

Regards,
manoj.


>From: Sudheer Dharanikota <[e-mail]>
>To: manoj juneja <[e-mail]>
>CC: [e-mail], [e-mail], 
>[e-mail],        [e-mail]
>Subject: Re: Fwd: Comments on GMPLS signalling drafts
>Date: Wed, 19 Dec 2001 17:59:49 -0800
>
>Hi Manoj:
>
>You are asking for improvising GMPLS documents on bandwidth modification,
>which is still in infacy stage at ITU. We should draw line some where,
>as to which features will go into first version of the GMPLS standard.
>
>- sudheer
>
>
>manoj juneja wrote:
>
> > Hi Dimitri,
> >                My main concern was that if some topic is still being
> > discussed (like waveband and bandwidth modification for TDM LSPs), it
> > should be mentioned in the drafts that these sections are still not
> > complete and are under discussions/further study. To a reader of the
> > GMPLS drafts it should be clear that what all features are fully
> > specified by the IETF and there is no further conflict in the industry.
> > I still feel that there should be some reference for the bandwidth
> > modification for all the technologies (SDH/SONET, LSC and FSC) in the
> > drafrs.
> >
> > After reading the drafts one can question that :
> >
> > a) Can I increase the bandwidth of a TDM/FSC/LSC LSP ? If yes then
> > how ? Even one can question that is it under the scope of GMPLS ?
> >
> > These comments are just for completeness of the drafts before proceeding 
>to
> > the RFC status.
> >
> > Regards,
> > manoj.
> >
> > >From: Dimitri Papadimitriou <[e-mail]>
> > >To: manoj juneja <[e-mail]>
> > >CC: [e-mail], [e-mail], [e-mail]
> > >Subject: Re: Fwd: Comments on GMPLS signalling drafts
> > >Date: Wed, 19 Dec 2001 18:35:55 +0100
> > >
> > >Manoj,
> > >
> > >On the following "bandwidth modification" and "waveband switching":
> > >
> > >The first one is an ongoing topic discussed for instance in
> > 
> >http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> > >that will be reviewed and updated for the next upcoming meetings
> > >
> > >On "waveband switching" the question is do we consider something
> > >further than what's already included in the version -07.txt. We
> > >have provided for this purpose some ideas in:
> > 
> >http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt
> > >
> > >CCAMP (and IETF) community should tell us if it is worth going on
> > >with the latter topic. If there is any interest, etc. But anyhow
> > >this is for further discussion (i.e. not within the scope of the
> > >current last call). It is now greatly time to move on (as said by
> > >Lou)...
> > >
> > >Regards,
> > >- dimitri.
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi Lou/Eric/Dimitri,
> > > >
> > > >   Please see the following para from gmpls-architecture draft :
> > > >
> > > >    "LSP modification consists in changing some LSP parameters, but
> > > >    normally without changing the route. It is supported using the
> > > >    same mechanism as re-routing. However, the semantic of LSP
> > > >    modification will differ from one technology to the other. For
> > > >    instance, further studies are required to understand the impact
> > > >    of dynamically changing some SDH/SONET circuit characteristics 
>such
> > > >    as the bandwidth, the protection type, the transparency, the
> > > >    concatenation etc."
> > > >
> > > > If u say that SE style of reservation is supported then how are u 
>going
> > >to
> > > > share the bandwidth of SDH/SONET, Lambda or Fiber LSPs ? How can one
> > >assign
> > > > diferent labels (labels are the physical resources on the link) to
> > >different
> > > > senders that belong to the same RSVP session. Is it  that the SE 
>style
> > >of
> > > > reservation only supported to modify the bandwidth of LSP ? Can I 
>modify
> > >the
> > > > bandwidth of LSC/FSC LSP ? If yes then how ?
> > > >
> > > > Do u people think that waveband section is compelte in the drafts ?
> > > >
> > > > Please see other comments inline.
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > >From: Lou Berger <[e-mail]>
> > > > >To: "manoj juneja" <[e-mail]>
> > > > >CC: <[e-mail]>,<[e-mail]>,
> > > > ><[e-mail]>
> > > > >Subject: Re: Fwd: Comments on GMPLS signalling drafts
> > > > >Date: Fri, 14 Dec 2001 15:18:34 -0500
> > > > >
> > > > >see comments inline.
> > > > >
> > > > >At 09:10 PM 12/13/2001, manoj juneja wrote:
> > > > >
> > > > >
> > > > >
> > > > >> >From: "manoj juneja" <[e-mail]>
> > > > >> >To: [e-mail]
> > > > >> >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.
> > > > >
> > > > [Manoj]: What I want to say is that Component_If_Id_Downstream and
> > >Upstream
> > > > TLVs of IF_ID_RSVP_HOP object have been removed from the bundling 
>draft.
> > >Do
> > > > u still want to keep these TLVs in GMPLS drafts ? If yes then is 
>there
> > >any
> > > > reason for keeping these ?
> > > >
> > > > >> >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.
> > > > >
> > > > [Manoj]: Thanks for putting this info in the new version of the 
>draft.
> > > > >>
> > > > >> >6. It should be mentioned that bandwidth encoding parameter is
> > >useful
> > > > >> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc.
> > > > >> >
> > > > [Manoj]: I think u should include what all technologies will make 
>use of
> > > > this parameter.
> > > >
> > > > >> >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.
> > > > >
> > > > >
> > > >
> > > > _________________________________________________________________
> > > > Join the world’s largest e-mail service with MSN Hotmail.
> > > > http://www.hotmail.com
> > ><< dimitri.papadimitriou.vcf >>
> >
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device: http://mobile.msn.com
><< sudheer.vcf >>


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