Re: Fwd: Comments on GMPLS signalling drafts

[Dimitri Papadimitriou <[e-mail]>]

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