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
I think Lou may mean a "response to an event" rather than a "response
message".
"reaction" may be almost a synonym.
A
----- Original Message -----
From: "AISSAOUI Mustapha" <Mustapha.Aissaoui at alcatel-lucent.com>
To: "Lou Berger" <lberger at labn.net>
Cc: <mpls at ietf.org>
Sent: Wednesday, November 19, 2008 7:54 PM
Subject: Re: [mpls] last call on three mpls wg documents
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.
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 timeFrom mpls-bounces at ietf.org Wed Nov 19 12:10:10 2008
Return-Path: <mpls-bounces at ietf.org>
X-Original-To: mpls-archive at megatron.ietf.org
Delivered-To: ietfarch-mpls-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 4CC8B3A683E;
Wed, 19 Nov 2008 12:10:10 -0800 (PST)
X-Original-To: mpls at core3.amsl.com
Delivered-To: mpls at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 093873A683E
for <mpls at core3.amsl.com>; Wed, 19 Nov 2008 12:10:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.273
X-Spam-Level:
X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325,
BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 2GH-V-Gs9+C7 for <mpls at core3.amsl.com>;
Wed, 19 Nov 2008 12:10:07 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248])
by core3.amsl.com (Postfix) with ESMTP id 75B343A6782
for <mpls at ietf.org>; Wed, 19 Nov 2008 12:10:06 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1])
by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id
mAJK9ldO016970; Wed, 19 Nov 2008 20:09:47 GMT
Received: from your029b8cecfe ([130.129.31.98]) (authenticated bits=0)
by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id
mAJK9jQ8016963; Wed, 19 Nov 2008 20:09:46 GMT
Message-ID: <FC3D9E3ABC9748ED98D26D9E74DF6BA5 at your029b8cecfe>
From: "Adrian Farrel" <adrian at olddog.co.uk>
To: "AISSAOUI Mustapha" <Mustapha.Aissaoui at alcatel-lucent.com>,
"Lou Berger" <lberger at labn.net>
References: <48FCFD7D.3080306 at pi.nu><4A5028372622294A99B8FFF6BD06EB7B04D073A1 at USDALSMBS03.ad3.ad.alcatel.com><20081114010158.9D7FA3A6A3A at core3.amsl.com>
<4A5028372622294A99B8FFF6BD06EB7B04D9116F at USDALSMBS03.ad3.ad.alcatel.com>
Date: Wed, 19 Nov 2008 20:09:40 -0000
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Cc: mpls at ietf.org
Subject: Re: [mpls] last call on three mpls wg documents
X-BeenThere: mpls at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <adrian at olddog.co.uk>
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
<mailto:mpls-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mpls>
List-Post: <mailto:mpls at ietf.org>
List-Help: <mailto:mpls-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
<mailto:mpls-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: mpls-bounces at ietf.org
Errors-To: mpls-bounces at ietf.org
I think Lou may mean a "response to an event" rather than a "response
message".
"reaction" may be almost a synonym.
A
----- Original Message -----
From: "AISSAOUI Mustapha" <Mustapha.Aissaoui at alcatel-lucent.com>
To: "Lou Berger" <lberger at labn.net>
Cc: <mpls at ietf.org>
Sent: Wednesday, November 19, 2008 7:54 PM
Subject: Re: [mpls] last call on three mpls wg documents
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.
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 willout will
cancel the timer.
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 Anderss
cancel the timer.
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
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls
on
> > 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
_______________________________________________
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.
