-----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
