The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

See my comments within:

Changcheng Huang wrote:

> Hi Bora,
>
> Thank you for your comments. One particular question you have raised is
> about using RSVP-TE to support the mechanism defined in this draft. This is
> a very good question. We have been working on both RSVP and CR-LDP
> extensions for a while. Currently we see the following problems with
> RSVP-TE:
>
> 1. There are no objects defined in RSVP-TE to identify PSL, PML and a
> protected path;
>

These can be easily added.

>
> 2. No mechanism has been provided in RSVP-TE to setup a p2mp LSP for RNT if
> one carrier choose to use MPLS forwarding rather than hop-by-hop. Currently
> we are thinking to use the RESV message for the request and Confirmation
> message for the actual label allocation;
>

Much better to carry the RNT using IP.

>
> 3. There is no notification mechanism defined in RSVP-TE to support FIS or
> FRS. Currently we are thinking to use PathErr message for this purpose. It
> requires changing the behavior of a RSVP node.
>
> Therefore we are actually thinking an extension to RSVP-TE to support the
> features defined in this contribution. We would like to listen to your
> comments and comments from the community on this direction.
>

As I said before, it is easier to extend RSVP-TE then write yet another
protocol.

Regards

Bora


>
> Thanks,
>
> Chang
>
> --
> Changcheng Huang, Ph.D.
> Tellabs
> 4951 Indiana Avenue, MS 64
> Lisle, IL 60532
> Tel: (630) 512-7954
> Fax: (630) 512-8037
>
> akyol@pluris.com wrote:
>
> > I have read the draft and have the following comments:
> >
> >   1. It is unclear how the RNT mechanism with its FIS/FRS timers differs
> >      from RSVP with TE extensions. Specifically, the timers and the RNT
> >      mechanism resemble RSVP reservations with soft state but with
> >      inverted logic. This should be explained.
> >   2. The text does not specify via what mechanism the FIS/FRS packets
> >      are transmitted? Via UDP/TCP over IP, via the DCC in the SONET
> >      overhead using ISO CLNS? It would be nice to have some packet
> >      formats and outlines of transmission routines.
> >   3. It is pointed in the text that MPLS protection reserves bandwidth
> >      but the text fails to mention SONET also reserves bandwidth.
> >      Moreover, in most current IP/MPLS LSRs, unused bandwidth is usually
> >      used for lower traffic classes.
> >   4. I found sect. 2.2.1 useful.
> >   5. Are FIS and FRS defined somewhere?
> >   6. Timers: There are way too many timers. I do understand that the RNT
> >      cuts down on the amount of notifications, but on core routers with
> >      large number of interfaces with large number of LSPs flowing
> >      through them, 8 timers per RNT is a bit much. This is sort of
> >      related to the question 1 above too.
> >   7. It seems to me that there is a lot of state associated with each
> >      RNT especially when the inverse forking ratio (IFR) is high. It
> >      would help to clearly specify exactly what state needs to be
> >      maintained in a list.
> >   8. In general, people are not concerned with the volume (bw) of
> >      signaling traffic but the overhead it costs in terms of processing.
> >
> > In general, I found the draft of some value, but I think the RNT
> > mechanism should be either separated from the protection procedure or
> > put in an appendix.
> >
> > RNT bears striking similarity to RSVP and there are already quite a
> > number of fields defined in RSVP-TE for the purpose of protection
> > switching signaling, so can we just add what is needed to RSVP-TE?
> >
> > The text also omits all discussion of how restoration paths are
> > computed, what constraints need to be imposed, etc.
> >
> > There is also a lack of specificity in the text, which I hope will
> > improve in a subsequent version. Ideally, an Internet draft should lend
> > itself to being read and then implemented unlike a research paper.
> >
> > Finally, a question to the audience, how does the proposed scheme
> > interoperate with vendor proprieatry implementations of protection
> > switching? Now that the cat is out of the bag, we may want to open up
> > and agree on a standard.
> >
> > Thanks
> >
> > Bora Akyol