The MPLS WG Archive

[Lou Berger <lberger@labn.net>]

Adrian,
         Thank you for your usual quality comments.

See below for some responses.

Lou
At 04:33 PM 7/21/00 +0100, Adrian Farrel wrote:
>Peter, Lou,
>
>Good draft.
>
>Attached a few small questions, a couple of editorial suggestions and a
>clutch of typos.
>
>I hope this helps.
>
>Regards,
>Adrian
>
>Questions
>=========
>
>1. I know I was shot down last time I suggested this, but that was
>    in the optical discussion before the draft became "generalized"...
>    Given that we can now set up LSPs as downstream on demand, or
>    downstream on demand AND downstream unsolicited at the same time
>    i.e. bidirectional), why don't we allow downstream unsolicited on
>    its own?  This would make for a fully generalized solution .
>    The answer before was "There are no applications for this," but I
>    would argue for making this fully generalized while we're at this
>    stage especially since the work is simply to relax the requirement
>    that 'label request' must be present on REQUEST/Path to say that at
>    least one of 'label request', 'label' and 'generalized label' must
>    be present.

I still think understanding a use for this makes sense before considering 
adding it.  What application are you thinking about?

Also, in the bidirectional case, I completely don't see the point.  What am 
I missing?

>2. Is it an issue that you cannot choose at LSP set up whether the LSP
>    will switch a wavelength or the whole fiber?  Since this is a
>    property of the link and not of the signaled label, a link's usage
>    for wavelength switching or whole fiber switching cannot be
>    selected dynamically.  Is this an issue?

I don't think I understand the question.  Perhaps we should just talk about 
this one face-to-face in Pittsburgh.

>3. Could you explain the "compatibility reasons" why a new c-type is
>    required for a Generalized Label that contains a Waveband Label?
>    I've looked through the archive and can't find any reference - sorry
>    if I wasn't paying attention when this was discussed.

It allows nodes that don't support waveband switching to respond with an 
appropriate error message.  The message falls out of previously specified 
signaling behavior.  For RSVP the relevant behavior is defined in RFC2205, 
under handling of "Unknown C-Type for Known Class".


>4. Would it be worth prohibiting bidirectional LSP setup where the
>    forward label is of one type and the reverse label of a different
>    type?  This would be a bit odd since the resource requirements are
>    the same in both directions.

I'm not sure how you could signal setting up different label types in each 
direction.  Do you see a way?

>5. I like the concept of Egress Label in an ERO to support splicing to
>    an existing tunnel.  Would now not be a good time to add support
>    for stacking as well?

Again, I think this should be driven by application.  If you've got one, 
lets talk about it.

>  The ERO suboject format would match that of
>    Egress Label, but a new type would be needed.  I'm sure there would
>    be many uses in the optical world.
>
>    Compare with the ER-Hop type of LSPID in CR-LDP.

[Rest of original message delete, looked good to me.]

Thanks again,
Lou