[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bi-directional LSPs Incompatibility
George's point is that strict alignment does not need to be a goal.
If you look at the O-UNI as a user of GMPLS services, there is no
reason to expect this user to use all available services.
> Hi George,
> As long as both the documents are not aligned, we can say there
> is some incompatibility. I think one can argue it in both ways. Is it a
> incompatibility or a feature that GMPLS offers but UNI is unable to make use
> of it ?
> >From: George Swallow <email@example.com>
> >To: "manoj juneja" <firstname.lastname@example.org>
> >CC: email@example.com, firstname.lastname@example.org
> >Subject: Re: Bi-directional LSPs Incompatibility
> >Date: Wed, 18 Jul 2001 18:23:39 -0400
> > > Hi All,
> > > There is some incompatibility in documents of OIF
> > > (oif2000.125.5) and IETF (draft-ietf-mpls-generalized-rsvp-te-03.txt)
> > > related to bidirectional LSPs. OIF's O-UNI document says [docId
> > > oif2000.125.5, page 93 Figure 12-1] the destination UNI-C must
> > > insert a RESV_CONFIRM object in the RESV message and should wait for
> > > ResvConf message before start transmitting data.
> > > But, the IETF document says the terminator node process path message
> > > as usual with the exception that the upstream label can immediately be
> > > used to transport data traffic associated with the LSP upstream towards
> > > the initiator.
> > >
> > > Please Help.
> > >
> > > Regards,
> > > manoj.
> >I don't see a problem in this case. Having the two ends more
> >constrained than the middle as to when a circuit can be considered in
> >service doesn't seem to present a problem.
> >But my personal opinion is that the RESV Conf should be optional for
> >the UNI.
> >George Swallow Cisco Systems (978) 244-8143
> > 250 Apollo Drive
> > Chelmsford, Ma 01824
> Get your FREE download of MSN Explorer at http://explorer.msn.com