Subject: Re: [Pals] Comments on draft-brissette-pals-pw-fec-label-request-00

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 25 Oct 2014 16:42:01 +0000

Sami,

Lots of thanks for a prompt response.

Regarding my technical comment, I think that:

- the draft is equally relevant for all applications of FEC-128 and FEC-129 (P2P. AndVPLS) even if you did not try to address VPLS needs

- my comment is relevant also for P2P applications.

Regarding RFC 7267 - I will look it up, and, of course, a reference is needed.

Thumb typed on my LG,
Sasha

------ Original message ------
From: Sami Boutros (sboutros)
Date: 24/10/2014 21:58
To: Alexander Vainshtein;
Cc: Patrice Brissette (pbrisset);Kamran Raza (skraza);[email-masked];[email-masked];[email-masked];Rotem Cohen;Gideon Agmon;
Subject:Re: Comments on draft-brissette-pals-pw-fec-label-request-00

Hi Sasha,

On Oct 23, 2014, at 10:15 PM, Alexander Vainshtein wrote:

​​Hi all,
I've read the draft and I think that it closes an important gap left by the original RFC 4447.

Sami: Thanks.

At the same time I have a couple of comments regarding the current text.

Technical:

Neither FEC-128 nor FEC-129 explicitly specify the remote PE. The same PWid (in the case of FEC-128) or the same triple {AGI, SAII, TAII} (in the case of FEC-129) can be assigned to multiple PW endpoints in a given PE provided  that their remote PEs are different. This fact is used, e.g., for setting up a full mesh of Ethernet PWs between multiple VSIs forming a single VPLS in RFC 4762.
At the same time, each occurrence of { Remote PE, PW FEC} is bound to a different PW label because these labels are used as PW demultiplexers.

Suppose now that PE-1 has used the same PW-FEC-1 for two PWs, one with remote peer PE2, and the other - with remote peer PE-2, and allocated PW labels L12 and L13 as incoming PW labels to these two PWs.
I assume that, if PE2 sends Label Request for PW-FEC-1 to PE1, it would only receive the label mapping message with L12; however, this is not explicitly specified in the draft.

The same logic presumably should be applied to the situations when requests for wildcard PWFEC (general or Typed) are received, i.e., regardless of the specific FEC for which label requests has been issued:

  *   Only labels bound to combinations of the requester as the remote PE and suitable PW FEC would be re-advertised
  *   If the PW FEC is not associated with any PW endpoint having the requester as its remote PE,   a "No PW"  Notification would be sent, even if the PWFEC itself is used in conjunction with other PEs.

IMHO and FWIW such a clarification in the draft would be beneficial.

Sami: The scope of the document is for label request for p2p PWs between 2 PEs as defined in RFC 4447 and PWE3 reference model. However, we will look at those comments and see how we can clarify given the scope of our document.

Editorial:
Section 3.2 mentions a "TT-PE". Judging by the context, I think that this should be T-PE (a reference to S-PE appears immediately after the sentence mentioning T-PE).

Sami: We mean here Target Terminating Provider Edge (TT-PE) as defined in RFC 7267. But I agree we need to provide the reference.

Thanks,

Sami

Hopefully these comments will be useful.

Regards,
Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 26 Oct 2014 05:59:13 +0000

​Sami and all,

In the wake of my previous email I have looked up RFC 7267, and it indeed defines the terms ST-PE and TT-PE that you use in Section 3.2 of the draft.

However, it seems that these terms only apply to dynamically placed PWs, where ST-PE is identified as the T-PE that assumes the active signaling role and TT-PE-as the T-PE that assumes the passive signaling role.

However, section 7.2.1 of RFC 6073 states that, if FEC-129 is used for signaling MS-PWs with statically placed S-PEs, both T-PEs may assume active role. It is not clear to me whether the terminology of RFC 7267 applies for this scenario, since it includes such terms as "forward direction (from ST-PE to TT-PE)" and "reverse direction (from TT-PE to ST-PE)". In this regard RFC 7267 (which deals only with dynamically placed MS-PW) follows RFC 6073 that states that, for dynamically placed MS-PWs exactly one T-PE must assume active role.

However, to the best of my understanding, the draft definitely is relevant for the scenarios with static placement of S-PEs, and hence the use case where both T-PEs assume active role should be  covered as well.

My 2c,

Sasha

________________________________
From: Pals <[email-masked]> on behalf of Alexander Vainshtein <[email-masked]>
Sent: Saturday, October 25, 2014 7:42 PM
To: Sami Boutros (sboutros)
Cc: Patrice Brissette (pbrisset); Kamran Raza (skraza); Gideon Agmon; [email-masked]; [email-masked]; [email-masked]; Rotem Cohen
Subject: Re: [Pals] Comments on draft-brissette-pals-pw-fec-label-request-00

Sami,

Thumb typed on my LG,
Sasha

------ Original message ------
From: Sami Boutros (sboutros)
Date: 24/10/2014 21:58
To: Alexander Vainshtein;
Cc: Patrice Brissette (pbrisset);Kamran Raza (skraza);[email-masked];[email-masked];[email-masked];Rotem Cohen;Gideon Agmon;

Hi Sasha,

​​Hi all,

Sami: Thanks.

Technical:

Editorial:

Thanks,

Sami

Regards,
Sasha

---

From: "Patrice Brissette (pbrisset)" <[email-masked]>
Date: Sun, 26 Oct 2014 13:24:30 +0000

Thanks Alexander for your comments.

I agree with your comments. The terminology needs some clarification.
Also, kind in mind that draft relevant for both static and dynamic placement of MS-PW.
We will make sure the draft cover aspects discussed in RFC6073 and RFC7267.

Regards,

Patrice

   [http://www.cisco.com/web/europe/images/email/signature/est2014/logo_06.png?ct=1406640631632]

Patrice Brissette
TECHNICAL LEADER.ENGINEERING

[email-masked]<mailto:[email-masked]>
Phone: +1 613 254 3336

Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Canada
Cisco.com<http://www.cisco.com/global/CA/>

[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Please click here<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for Company Registration Information.

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Date: Sunday, October 26, 2014 at 1:59 AM
To: Sami Boutros <[email-masked]<mailto:[email-masked]>>
Cc: Patrice Brissette <[email-masked]<mailto:[email-masked]>>, "Kamran Raza (skraza)" <[email-masked]<mailto:[email-masked]>>, Gideon Agmon <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Rotem Cohen <[email-masked]<mailto:[email-masked]>>
Subject: Re: Comments on draft-brissette-pals-pw-fec-label-request-00

​Sami and all,

My 2c,

Sasha

________________________________
From: Pals <[email-masked]<mailto:[email-masked]>> on behalf of Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, October 25, 2014 7:42 PM
To: Sami Boutros (sboutros)
Cc: Patrice Brissette (pbrisset); Kamran Raza (skraza); Gideon Agmon; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Rotem Cohen
Subject: Re: [Pals] Comments on draft-brissette-pals-pw-fec-label-request-00

Sami,

Thumb typed on my LG,
Sasha

------ Original message ------
From: Sami Boutros (sboutros)
Date: 24/10/2014 21:58
To: Alexander Vainshtein;
Cc: Patrice Brissette (pbrisset);Kamran Raza (skraza);[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;Rotem Cohen;Gideon Agmon;

Hi Sasha,

​​Hi all,

Sami: Thanks.

Technical:

Editorial:

Thanks,

Sami

Regards,
Sasha