[Pals] ***SPAM*** 7.278 (5) RE: Comments of draft-cheng-pwe3-mpls-tp-dual-homing-coordination-01

[程伟强 <[e-mail]>]

Hi  Lizhong,

 

Thank you very much for your comments. Jie and I answered your questions
inline.

[BTW: Some mails were not post on the WG board, because “Too many
recipients to the message”. In Following mail, I summarized all comments
and answers ] 

 

B.R.

Weiqiang Cheng

From: Lizhong Jin [mailto:[e-mail]] 
Sent: Tuesday, November 11, 2014 6:04 PM
To: 'Dongjie (Jimmy)'; '程伟强'; 'David Sinicrope'; [e-mail]; 'Shahram
Davari'
Cc: 'Stewart Bryant'; 'Andrew Malis'; [e-mail];
[e-mail]; 'Hui Deng'
Subject: Comments of draft-cheng-pwe3-mpls-tp-dual-homing-coordination-01

 

Hi,

Have a quick review of draft-cheng-pwe3-mpls-tp-dual-homing-coordination-01.

In section 3.2:

After the exchange of service PW state and switching request, both

   dual-homing PEs could determine the Active/Standby forwarding status

   of the working and protection service PWs.

The “switching request” and “switchover request” refer to the switchover
request by LDP defined in RFC6870, right? In that case, you need to describe
the interaction between the mechanism defined in RFC6870 and the DHC defined
in your document. One sentence as above is not enough. E.g., in case
Two-side Dual-homing Scenario, if independent mode is enabled between two
PEs, and the service PW is done, then when PE1 will switchover, after
waiting for protection PW to be active, or send packets to PE2, and let PE2
to drop packets first.

 

[Jie] Here the switching request refers to the “Dual-Node Switching TLV”
in DHC message exchanged between the dual-homing PEs, it does not rely on
RFC6870. 

 

[Jie] I guess the “PE2” in your above example means the remote side PE
(not the other dual-homing PE in the same side), right? If so, the
switchover coordination between PE1 and PE2 can be achieved using PSC
defined in RFC6378. 

[Lizhong] I see. Could you say that explicitly, and the relationship with
RFC6378? 

 

[Weiqiang] Agree. We will add one sentence to describe the relationship 

 

And I suggest to not use terminology “standby”. You could use, e.g.,
normal state on protection PW. A PW in standby state is clearly defined in
RFC6870.

 

[Weiqiang] Agree. Is that OK if We use “hot-standby” to replace the
“standby” in the draft?

 

Another concern from me is in the second presentation, slide 9, if failure 3
and 5 happened simultaneously (or failure 1 and 3), it is possible that one
packet from CE1 will be send to PE2 by PE1, and PE2 will send back to CE1
(the AC2 is active because of the failure5), then that looped packet may
influence the MAC table of CE switch. This is a corner case, but it seems it
is possible. If the CE switch allows MAC moving, this looped packet may lead
to traffic loss.

 

[Weiqiang] The forwarding behavior of the dual-homing PE nodes is determined
by the forwarding state machine as shown in the following  table:

 

          +-----------+---------+--------+---------------------+

          |Service PW |   AC    | DNI PW | Forwarding Behavior |

          +-----------+---------+--------+---------------------+

          |  Active   | Active  |   Up   |Service PW <-> AC    |

          +-----------+---------+--------+---------------------+

          |  Active   | Standby |   Up   |Service PW <-> DNI PW|

          +-----------+---------+--------+---------------------+

          |  Standby  | Active  |   Up   |    DNI PW <-> AC    |

          +-----------+---------+--------+---------------------+

          |  Standby  | Standby |   Up   |  Drop all packets   |

          +-----------+---------+--------+---------------------+

When the scenario you mentioned happens, the PE2’s state = (Service
PW=Active, AC= Standby, DNI PW= UP) => the forwarding behavior will be only
Service PW<->DNI PW which means the packets from DNI PW can only be
forwarded to PE2’s Service PW. 

 

Overall, if the mechanism is applied to the case of Two-side Dual-homing
Scenario, it switchover performance is not as good as local protection as
expected, because you have to wait for the signaling. 

 

[Jie] If it is a AC failure, switchover is needed only on the dual-homing
PEs in one side, signaling with the remote side is NOT needed. If it is a PW
failure in PSN network, switchover coordination between the two sides can be
performed by mechanism like PSC, and I think the performance would be
similar to PSC.

 

 

Regards

Lizhong

 

 

From: Lizhong Jin [mailto:[e-mail]] 
Sent: Tuesday, November 11, 2014 2:35 PM
To: '程伟强'; 'David Sinicrope'; [e-mail]; 'Shahram Davari'
Cc: 'Hui Deng'; 'Andrew Malis';
[e-mail]; bess@ietf.
org; 'Stewart Bryant'
Subject: RE: [Pals] PALS IETF 91 Slot Requests - Honolulu - SLIDES

 

Hi,

Have a quick review of draft-cheng-pwe3-mpls-tp-dual-homing-coordination-01.

In section 3.2:

After the exchange of service PW state and switching request, both

   dual-homing PEs could determine the Active/Standby forwarding status

   of the working and protection service PWs.

The “switching request” and “switchover request” refer to the switchover
request by LDP defined in RFC6870, right? In that case, you need to describe
the interaction between the mechanism defined in RFC6870 and the DHC defined
in your document. One sentence as above is not enough. E.g., in case
Two-side Dual-homing Scenario, if independent mode is enabled between two
PEs, and the service PW is done, then when PE1 will switchover, after
waiting for protection PW to be active, or send packets to PE2, and let PE2
to drop packets first.

 

Overall, if the mechanism is applied to the case of Two-side Dual-homing
Scenario, it switchover performance is not as good as local protection as
expected, because you have to wait for the signaling. 

 

Regards

Lizhong

 

 

From: 程伟强 [mailto:[e-mail]] 
Sent: 2014年11月11日 11:31
To: 'David Sinicrope'; [e-mail]; 'Shahram Davari'
Cc: 'Hui Deng'; 'Andrew Malis';
[e-mail]; bess@ietf.
org; 'Stewart Bryant'
Subject: Re: [Pals] PALS IETF 91 Slot Requests - Honolulu - SLIDES

 

Hi David,

Thank you very much for your arrangement.

Because of Visa issue, the authors of the draft in China could not attend
the meeting, and Shahram will help present the two topics.

If it is possible, we may need change the presentations sequence: “MPLS-TP
Dual homing protection” should be presented before “MPLS-TP Dual homing
coordination” to be easier understandable the overall work.

 

B.R.

Weiqiang Cheng

 

 

From: Pals [mailto:[e-mail]] On Behalf Of David Sinicrope
Sent: Tuesday, November 11, 2014 10:06 AM
To: [e-mail]
Cc: [e-mail]; Andrew Malis; IETF.PWE3; [e-mail]; Stewart Bryant
Subject: Re: [Pals] PALS IETF 91 Slot Requests - Honolulu - SLIDES
Importance: High

 

Hi All,

 

http://www.ietf.org/proceedings/91/agenda/agenda-91-pals

The agenda for PALS is above.

 

Speakers, please reply to this email with your slides as soon as possible…
only 1 hr left to the deadline.

 

Thanks,

Dave

 

 

From: David A Sinicrope <[e-mail]>
Date: Thursday, October 30, 2014 at 1:17 PM
To: "[e-mail]" <[e-mail]>
Cc: "IETF.PWE3" <[e-mail]>, "[e-mail]" <[e-mail]>, Stewart
Bryant <[e-mail]>, Andrew Malis <[e-mail]>,
"[e-mail]" <[e-mail]>
Subject: Re: [bess] PALS IETF 91 Slot Requests - Honolulu

 

 

Hi All,

I’m still waiting on the tools to catch up with the new WG to post the
agenda on the meeting materials web pages. 

 

In the meantime, below is the draft PALS agenda for Honolulu.

If you requested a slot and I haven’t allocated one, my apologies, please
complete the form below and send it in reply to this email.

If you haven’t requested a slot and need one, please complete the form
below and send it in reply to this email no later than 31 October 2014 12:00
EDT.

*** Taking a couple of minutes to complete the form helps me complete the
agenda quickly and accurately.  

 

Those that have slots allocated, please send me your slides no later than
Monday 10 Nov 2014 17:00 Honolulu time.

If I don’t have your slides by that time, you risk losing your slot.

Thanks!

Dave

 

 

**********************************************************************

IETF 91 PALS - Wednesday, November 12, 2014 - 13:00 - 15:00 Coral 4

(45/120 min allocated; ** Please note the time adjustments.)

**********************************************************************

Chairs: Stewart Bryant and Andy Malis

Secretary: David Sinicrope

(x = slide sets NOT received as of October 30, 2014 19:00 EDT)

 

x1. 15 min - Agenda bash, WG Agenda and Status - Andy MALIS and Stewart
BRYANT

 

 

x2. 10 min - MPLS LDP - Patrice BRISSETTE

http://datatracker.ietf.org/doc/draft-brissette-pals-pw-fec-label-request

Objective:  First submission, asking for feedback

 

 

x3. 10 min - S-PE Outage Protection for Static Multi-Segment Pseudowires -
Andy MALIS

http://tools.ietf.org/html/draft-shawam-pwe3-ms-pw-protection-02

Objective: Update showing new solution based on received comments from the
previous revision, to prepare for WG adoption request.

 

 

x4. 10 min - A Unified Control Channel for Pseudowires - Stewart BRYANT

http://datatracker.ietf.org/doc/draft-ietf-pwe3-vccv-for-gal

Objective: Discuss comments and get some working group feedback on how they
were addressed or will be addressed.

 

**********************************************************************

Overflow (Will be presented if time permits.)

**********************************************************************

 

xx. - None currently

 

**********************************************************************

REMOTE INFORMATION FOR THE PALS SESSION(S)

**********************************************************************

Remote Participation Info: 

http://www.ietf.org/meeting/91/remote-participation.html

 

- No WebEx

- Audio and Jabber are TBD

 

 

On Mon, Oct 20, 2014 at 7:06 PM, David Sinicrope
<[e-mail]> wrote:

 

Hi All,

Time to request presentation slots for IETF 91.  

 

If you need a presentation slot for the IETF 91 PALS session, please reply
to this email (subject intact) completing the form below.   If L2VPNers
aren't sure if their drafts will be addressed in PALS or BESS, they can send
in a request, and slot requests that belong to BESS will be forwarded with a
copy to the requester.  (See Andy’s email below.)

 

Please use this form and please reply to this email.

 

- topic (e.g., MPLS and Ethernet OAM Interworking):

- draft URL (e.g.,
<http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-eth-oam-iwk/>
http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-eth-oam-iwk/):  

- brief statement of objectives and issues that need to be discussed and
resolved via the presentation during the meeting  (e.g., need to address
security issues and get direction from the WG):  

- requested duration (norm is 10 min):  

- speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE):  

 

Thanks!

Dave

 

 

From: Andrew Malis <[e-mail]>
Date: Friday, October 17, 2014 at 3:25 AM
To: "[e-mail]" <[e-mail]>
Cc: "IETF.PWE3" <[e-mail]>, "[e-mail]" <[e-mail]>, Stewart
Bryant <[e-mail]>, David A Sinicrope
<[e-mail]>
Subject: PALS WG on its way ....

 

If you haven't been following Adrian's recent emails, the expectation is
that PALS will be officially formed as a new WG in two weeks, and will meet
in Honolulu in the agenda spot currently reserved for L2VPN, Wednesday at
13:00. Our WG Secretary, David Sinicrope, will be issuing a call for agenda
items. For those of you that were planning to present at PWE3, you'll be
presenting at PALS instead. For those of you that were planning to present
at L2VPN, you may be presenting at PALS or at BESS, the latter primarily for
EVPN-related drafts. Let Stewart or me know if you have any questions. 

 

We would also like to start using the PALS WG email list going forward. My
understanding is that if you were on the PWE3 list, you've been
auto-subscribed to the PALS list. If you were on the L2VPN list but not on
the PWE3 list, you have to sign up for the PALS list on your own. The
relevant information for the list is:

 

List address:  <mailto:[e-mail]> [e-mail]
Archive:  <http://www.ietf.org/mail-archive/web/pals/>
http://www.ietf.org/mail-archive/web/pals/
To subscribe:  <https://www.ietf.org/mailman/listinfo/pals>
https://www.ietf.org/mailman/listinfo/pals

 

Thanks,

Andy

 


_______________________________________________
BESS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bess