Dear all,
I received comments from Daniel regarding the intended use of the optional
active PW selection mechanism in section 5.1. I pasted below the corresponding
paragraph of Section 5.1 with the changes we agreed to underlined.
He also asked if the default active PW selection mechanism should be referenced
in Section 5.2 with the Master/Slave mode of operation. Although, it is not
stricly required for interoperability, implementations would benefit from a
consistent behaviour. I used SHOULD in that case. The text is also pasted below
with the changes underlined.
Let me know if you have any comments on this.
Regards,
Mustapha.
=======================================================================================
I. Changes to Section 5.1 - 3rd paragraph:
"
If more than one PW qualifies for the Active state, each PW endpoint MUST
implement a common mechanism to choose the PW for forwarding. The default
mechanism MUST be supported by all implementations and operates as follows:
1. For FEC128 PW, the PW with the lowest pw-id value is selected.
2. For FEC129 PW, each PW in a redundant set is uniquely identified at each
PE using the following triplet: AGI::SAII::TAII. The unsigned integer form of
the concatenated word can be used in the comparison. However, the SAII and TAII
values as seen on a PE node are the mirror values of what the peer PE node
sees. To have both PE nodes compare the same value we propose that the PE with
the lowest system IP address use the unsigned integer form of AGI::SAII::TAII
while the PE with the highest system IP address use the unsigned integer form
of AGI::TAII::SAII. This way, both PEs will compare the same values. The PW
which corresponds to the minimum of the compared values across all PWs in the
redundant is selected.
Note 1: in the case where the system IP address is not known, it is recommended
to implement the optional active PW selection mechanism described next.
Note 2: in the case of segmented PW, the operator needs to make sure that the
pw-id or AGI::SAII::TAII of the redundant PWs within the first and last segment
are ordered consistently such that the same end-to-end MS-PW gets selected.
Otherwise, it is recommended to implement the optional active PW selection
mechanism described next.
The PW endpoints MAY also implement the following optional active PW selection
mechanism.
1. If the PW endpoint is configured with the precedence parameter on each
PW in the redundant set, it must select the PW with the lowest configured
precedence value.
2. If the PW endpoint is configured with one PW as primary and one or more
PWs as secondary, it must select the primary PW in preference to all secondary
PWs. If a primary PW is not available, it must use the secondary PW with the
lowest precedence value. If the primary PW becomes available, a PW endpoint
must revert to it immediately or after the expiration of a configurable delay.
3. This active PW selection mechanism assumes the precedence parameter
values are configured consistently at both PW endpoints and that unique values
are assigned to the PWs in the same redundancy set to achieve tie-breaking
using this mechanism.
"
II. Changes to Section 5.2 - 5th paragraph:
"
If more than one PW qualify for the Active state, the Master PW endpoint node
selects one. There is no requirement to specify a default active PW selection
mechanism in this case but for consistency across implementations, the Master
PW endpoint SHOULD implement the default active PW selection mechanism
described in Section 5.1.
If the Master PW endpoint implements the optional active PW selection mechanism
based on primay/secondary and precedence parameters, it MUST follow the
following behaviour:
1. If the PW endpoint is configured with the precedence parameter on each
PW in the redundant set, it must select the PW with the lowest configured
precedence value.
2. If the PW endpoint is configured with one PW as primary and one or more
PWs as secondary, it must select the primary PW in preference to all secondary
PWs. If a primary PW is not available, it must use the secondary PW with the
lowest precedence value. If the primary PW becomes available, a PW endpoint
must revert to it immediately or after the expiration of a configurable delay.
"
=======================================================================================
________________________________
From: Aissaoui, Mustapha (Mustapha)
Sent: Wednesday, March 07, 2012 12:56 PM
To: Andrew G. Malis
Cc: stbryant(_at_)cisco(_dot_)com;
draft-ietf-pwe3-redundancy-bit(_at_)tools(_dot_)ietf(_dot_)org;
pwe3(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: RE: [PWE3] Last Call: <draft-ietf-pwe3-redundancy-bit-06.txt>
(Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
makes sense Andy.
Thanks,
Mustapha.
________________________________
From: Andrew G. Malis [mailto:amalis(_at_)gmail(_dot_)com]
Sent: Wednesday, March 07, 2012 12:53 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: stbryant(_at_)cisco(_dot_)com;
draft-ietf-pwe3-redundancy-bit(_at_)tools(_dot_)ietf(_dot_)org;
pwe3(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: [PWE3] Last Call: <draft-ietf-pwe3-redundancy-bit-06.txt>
(Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
Mustapha,
You might want to wait for any other LC comments before updating.
Thanks,
Andy
On Wed, Mar 7, 2012 at 9:49 AM, Aissaoui, Mustapha (Mustapha)
<mustapha(_dot_)aissaoui(_at_)alcatel-lucent(_dot_)com<mailto:mustapha(_dot_)aissaoui(_at_)alcatel-lucent(_dot_)com>>
wrote:
Ooops. Thank you for pointing this out Stewart. I will make the update and
publish a new revision.
Mustapha.
-----Original Message-----
From: Stewart Bryant
[mailto:stbryant(_at_)cisco(_dot_)com<mailto:stbryant(_at_)cisco(_dot_)com>]
Sent: Wednesday, March 07, 2012 12:48 PM
To:
draft-ietf-pwe3-redundancy-bit(_at_)tools(_dot_)ietf(_dot_)org<mailto:draft-ietf-pwe3-redundancy-bit(_at_)tools(_dot_)ietf(_dot_)org>
Cc: ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>;
pwe3(_at_)ietf(_dot_)org<mailto:pwe3(_at_)ietf(_dot_)org>
Subject: Re: Last Call: <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseudowire
Preferential Forwarding Status Bit) to Proposed Standard
Authors
There was on point that I notice that you did not address from the AD review
and so I am picking it up as a LC comment:
In section 10 you say:
"This document makes the following update to the PwOperStatusTC
textual convention in RFC5542 [8]: "
This update should be recorded in the metadata (top left front page) and it is
usual to put a one line note in the abstract.
Stewart
On 07/03/2012 17:00, The IESG wrote:
The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Pseudowire Preferential Forwarding Status Bit'
<draft-ietf-pwe3-redundancy-bit-06.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org> mailing lists by
2012-03-21. Exceptionally, comments may
be sent to iesg(_at_)ietf(_dot_)org<mailto:iesg(_at_)ietf(_dot_)org> instead.
In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This document describes a mechanism for standby status signaling of
redundant pseudowires (PWs) between their termination points. A set
of redundant PWs is configured between provider edge (PE) nodes in
single-segment pseudowire (SS-PW) applications, or between
terminating provider edge (T-PE) nodes in multi-segment pseudowire
(MS-PW) applications.
In order for the PE/T-PE nodes to indicate the preferred PW to use
for forwarding PW packets to one another, a new status bit is needed
to indicate a preferential forwarding status of Active or Standby for
each PW in a redundant set.
In addition, a second status bit is defined to allow peer PE nodes to
coordinate a switchover operation of the PW.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org<mailto:IETF-Announce(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/ietf-announce
--
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________
pwe3 mailing list
pwe3(_at_)ietf(_dot_)org<mailto:pwe3(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/pwe3