The MPLS WG Archive

[Changcheng Huang <changcheng.huang@tellabs.com>]

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;

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;

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.

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