Re: [mpls] last call on three mpls wg documents
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [mpls] last call on three mpls wg documents

See in-line responses.

At 01:54 PM 11/19/2008, AISSAOUI Mustapha wrote:

Lou,
it is very confusing to refer to a "response" to the reroute request
when there is no such a message in existing RSVP protocol and that this
document does not define a new one.
Yes, per my last message, I understand you are not happy with the choice of words. Please note that it says a "response" not a "response message". I think this is proper usage of the word "response". 


As for the valid responses as defined in this document, here is the
paragraph from Section 2.1.1:
"
   Valid responses are a PathTear message or a trigger
   Path message with an ERO avoiding the resource that was indicated in
   the reroute request.
"

I do not believe you can use a Path message with an ERO that avoids the
resource as a "response" to the reroute request because the LSPid is
different. You really cannot tell the trigger for the Path message. Only
a PathTear from the headend for that LSPid or a state timeout will
cancel the timer.


perhaps you missed my previous response.  I said:
> MBB is only SHOULD, so we need to cover the case where the ingress
> uses a modified ERO.

Lou


Regards,
Mustapha.

> -----Original Message-----
> From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On
> Behalf Of Lou Berger
> Sent: Thursday, November 13, 2008 8:02 PM
> To: AISSAOUI Mustapha
> Cc: mpls at ietf.org
> Subject: Re: [mpls] last call on three mpls wg documents
>
> Mustapha,
>          Thanks for the comments.  See in-line responses.
>
> At 01:14 PM 11/7/2008, AISSAOUI Mustapha wrote:
> >Dear all,
> >below are my comments on draft-ietf-mpls-gmpls-lsp-reroute-02.txt.
> >
> >Regards,
> >Mustapha.
> >
> >1) Section 2.1.1
> >    Reroute request timeouts are used to remove an LSP when
> there is no
> >    response to a reroute request.  Reroute request timeouts
> MUST NOT be
> >    used, when the LSP is not to be removed at the expiration of the
> >    Reroute request timeout period.
> >
> >MA> The timeout is not for expecting a response but for deleting the
> >state.
>
> which is a form of a response as is stated in the subsequent sentence.
>
> >There is no such a thing as an explicit response to the reroute
> >request. Even a PathTear received before the timeout does
> not mean it
> >was in response to the reroute request. There could have
> been another
> >condition which triggered it.
>
> while this is true, the paragraph defines what is meant by
> response.  So there is no technical issue.  You may not be
> happy with the phrasing, but that's an issue of style.
>
> >I believe the main point to convey in this paragraph is that
> a timeout
> >is required if state must be removed within a time limit. I
> propose to
> >rephrase this as follows:
> >"
> >    Reroute request timeouts are used when the the LSP must
> be removed
> >within a
> >    finite time limit.
> >"
>
> there's a bit of redundancy in the text, so don't mind
> eliminating the negative form.
>
>
> >2) Section 2.1.1
> >    When such LSP removal is desired and
> >    after initiating a reroute request, the initiating node
> MUST initiate
> >    a timeout during which it expects to receive a response to the
> >    reroute request.  Valid responses are a PathTear message
> or a trigger
> >    Path message with an ERO avoiding the resource that was
> indicated in
> >    the reroute request.  If either type of message is received, the
> >    timeout period MUST be canceled and no further action is needed.
> >
> >MA> The PathTear or a refresh timeout are the only events that will
> >cancel the timer. I do not think we can use any other
> message to cancel
> >the timer as first of all the LSPid will be different and there is no
> >way to correlate a new Path message to the reroute request.
>
> MBB is only SHOULD, so we need to cover the case where the ingress
> uses a modified ERO.
>
> >Secondly,
> >the new path computed by the head-end node may not traverse
> this node.
>
> yes, but it *may* so the text is valid.
>
> >3) Section 2.1.1
> >    Removal is indicated upstream via a PathErr message with
> >    the error code of "Service preempted".  The
> Path_State_Removed flag
> >    MUST be set if supported.  When the Path_State_Removed
> flag is not
> >    supported, a corresponding ResvTear MUST also be sent.
> >
> >MA> I do not believe there needs to be a precedence in using
> these two
> >methods. Either of them should be used. I propose to change this to:
> >"
> >Removal SHOULD be indicated upstream via either a ResvTear
> or a PathErr
> >message with the error code of "Service preempted" and the
> >Path_State_Removed flag set.
> >"
>
> I think you may have misread the text. It says use Path_State_Removed
> flag *iff* it's supported.  I see no reason to use a less efficient
> (i.e., more expensive) mechanism in the case it's supported.
>
> Much thanks for the comments.
>
> Lou
>
> >=============================================================
> ===========
> >========
> > > -----Original Message-----
> > > From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On
> > > Behalf Of Loa Andersson
> > > Sent: Monday, October 20, 2008 5:52 PM
> > > To: mpls at ietf.org
> > > Cc: Ross Callon; David Ward
> > > Subject: [mpls] last call on three mpls wg documents
> > >
> > > Working group,
> > >
> > > the authors of
> > >
> > > draft-ietf-mpls-gmpls-lsp-reroute-02.txt
> > > draft-ietf-mpls-soft-preemption-13.txt
> > > draft-ietf-mpls-3209-patherr-03.txt
> > >
> > > has asked that we issue a working group last call on these
> > > document as a group. This mail starts the wg last call.
> > >
> > > There has gone quite an effort to align the three document
> > > and to create a coherent structure.
> > >
> > > The working group last call will end on Nov 7.
> > >
> > > Please send comments to the working group mailing-list or to
> > > the working group co-chairs.
> > >
> > > /Loa
> > >
> > > --
> > > Loa Andersson
> > >
> > > Principal Networking Architect
> > > Acreo AB                           phone:  +46 8 632 77 14
> > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > Kista, Sweden                      email:  loa.andersson at acreo.se
> > >                                            loa at pi.nu
> > > _______________________________________________
> > > mpls mailing list
> > > mpls at ietf.org
> > > https://www.ietf.org/mailman/listinfo/mpls
> > >
> >_______________________________________________
> >mpls mailing list
> >mpls at ietf.org
> >https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
> mpls mailing list
> mpls at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>


_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.