Subject: Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward

From: Lizhong Jin <[email-masked]>
Date: Sun, 4 Oct 2015 23:42:53 +0800

Hi Stewart,
Thanks for the comment. This is a long email.
You give us three options:

1) Leave the design as it is, but add text to describe the constraint and
what happens if you have to change mode and what to do about it.

2) Exclude optimization in the FEC PWid(0x80) case

3) Add an appendix describing support for the FEC PWid(0x80) case.

 Then I prefer option 1. Because option2 is not reasonable, and the
solution in option3 provided by the author is not the best one.

I would like to provide opition4 for WG to consider:
4) Add description to support for the FEC PWid(0x80) case, in appendix or
text I don't care. The solution is:

label release message should not be sent in section 6.1.

For PW signaling, the unacceptable of any Interface Parameter will not
lead to any

label release, but just simply let the PW down in forwarding plane.

Regards
Lizhong

> ---------- Forwarded message ----------
> From: Stewart Bryant <[email-masked]>
> To: "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Date: Fri, 2 Oct 2015 16:41:05 +0100
> Subject: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward
> I am sorry that this is a long email, but I wanted to collect the
> facts together in one place and set out the complete scene to
> the PALS WG.
>
> The critical concern is contained in the following email fragment
> from Lizhong:
>
> =======
>
> In RFC4447 and 4447bis, it clearly said:
>
> Using the PWid FEC, each of the two pseudowire endpoints
>
>    independently initiates the setup of a unidirectional LSP.   An
>
>    outgoing LSP and an incoming LSP are bound together into a single
>
>    pseudowire if they have the same PW ID  and PW type.
>
> The behavior is a correct description for LDP-DU mode which PW applies.
>
> And that is also the behavior most vendors implement.
>
>
>
> Then in draft-ietf-l2vpn-vpls-pe-etree-09, it says:
>
>  A PE that receives a PW label mapping message with an E-Tree Sub-TLV
>
>    from its peer PE, after saving the VLAN information for the PW, MUST
>
>    process it as follows:
>
> .....
>
> 3) If the P bit is set
>
>
>
>       {
>
>
>
>           If the PE is a leaf-only node itself, a label release message
>
>       with a status code "Leaf to Leaf PW released" is sent to the peer
>
>       PE and exit the process;
>
>
>
>           Else the PE SHOULD set the Optimized-Mode to TRUE.
>
>
>
>       }
>
> That means, if PE1 receiving a label mapping from PE2 with P bit set,
>
> PE1 will send label release. Then PE2 will never send label mapping
>
> again to PE1 even when PE1 changes from leaf-only node to root-leaf node. For LDP-DU
>
> mode, PE2 will not send label mapping again when receiving PE1's label mapping.
>
> Then the PW will not be setup successfully. Then only way is to configure the
>
> same PW on PE2 again.
>
> The correct behavior is, label release message should not be sent.
>
> For PW signaling, the unacceptable of any Interface Parameter will not lead to any
>
> label release, but just simply let the PW down in forwarding plane.
>
>
>
> ========
>
> Andy looked at this from the point of view of the MEF and notes in
> private conversation:
>
> =========
> In the E-tree service as defined by MEF, you can have one or more roots
> and one or more leafs.
>
> In a single E-tree service (think of a multipoint PW with some of the CEs
> configured as roots as some as leafs), all leafs and roots receive frames
> sent by the roots. All roots receive frames sent by the leafs. However,
> leafs may not receive any frames sent by other leafs.
>
> The draft, as written, doesn't bring up an underlying pt-to-pt PWs to
> carry frames for the service between PEs that only have leafs attached.
> Since the leafs can't sent frames to each other, that is an economical
> use of PWs in the network.
>
> Lizhong's point is that this makes it impossible to add a new root to
> an existing PE in an E-tree that previously only had leafs.
>
> I agree that would be a problem if there was a requirement to modify
> an existing E-tree service. However, this draft has no other mechanisms
> to explicitly support E-tree modification, nor is such modification a
> requirement of the underlying MEF specification. BTW, since this work
> was started, the MEF replaced MEF 6.1 with MEF 6.2, "EVC Ethernet
> Services Definitions Phase 3", August, 2014, and that reference should
> be updated in the draft.
>
> My opinion is that the draft as it stands is technically correct if you
> don't need the ability to reconfigure an existing E-tree service
> dynamically.
>
> ==========
>
> Now whilst I can support the idea that dynamic reconfiguration of
> E-tree is not needed, I have a concern.
>
> My understanding the text in question is that it is saying that if
> A is configured as leaf only, and B which is also configured as
> leaf only attempts to configure a PW between them, then A rejects
> the PW setup.
>
> That sounds very reasonable to me, since there is a misconfig.
>
> If A did not do the reject, then B would forever be consuming
> resource waiting for A and B would have no idea of the
> misconfig. That accords with Andy's view above.
>
> However I was worried what would happen if A was misconfigured
> as leaf only and the configuration was corrected to root-leaf.
> What would in my view be difficult to accept was the need to
> take a human, or NMS action at B to recover the situation.
> However provided that A closed the LDP session with B
> and re-instate it B would then send the mapping message again.
> Thus the system is recoverable without needing to visit B which
> is in my mind a fundamental requirement since A could have
> got into the wrong mode as a result of an error.
>
> The problem I see is if A has a bunch of other PWs with B
> they will get torn down in order for A to have the config error
> fixed. However if that is a problem you need two LDP sessions
> between A and B, one for L2VPN and one for regular PWs.
>
> My inclination is that the draft is basically correct, and that whilst
> Lizhong is correct that the PW will not come up without some
> action, reconfiguring the PW on B is not the only action
> that will cause the PW to come up.
>
> So this comes down to a WG decision in terms of which is the
> least unacceptable behaviour - A having to re-cycle the LDP
> session, or B wasting resources. I think I prefer the behaviour
> proposed in the draft.
>
> A way forward is to leave the logic as written in the draft, but to
> add text describing the basis for excluding dynamic re-configuration
> as a normal operational mode and to note the actions that need
> to be taken when re-configuration is forced for some reason.
>
> Whilst we were pondering what do with the text the chairs
> and AD received another proposal from the authors:
>
> ======
>
> In general, FEC PWid(0x80) is used in VPLS with manual provisioning,
> while Generalized PWid (0x81) is used with auto-discovery.
>
> As discussed in Section 5.2, VLAN mapping parameters can be provisioned
> without a signaling protocol, Optimized Mode can also be a parameter
> to be provisioned.
>
> The approach we’ve taken in the current draft-ietf-l2vpn-vpls-pe-etree-09
> does allow this. Quite a few service providers may prefer to control
> all these E-Tree connectivity by themselves.
>
> When E-Tree signaling protocol for PWid FEC is considered, the following
> options are also feasible:
>
> a)       Disable Optimized mode for FEC PWid(0x80), thus root/leaf role
> change in the E-Tree topology will not have any influence on the PW.
>
> b)       Add another appendix into the document for the full support of
> Optimized mode with FEC PWid(0x80).
>
> The idea is: the PE sends a label mapping firstly and then send a label
> request to its peer PEs (so that they will reply with a label mapping
> respectively).
>
> Since Optimized mode is an optional piece in the document, I would
> regard option a) as a simple tradeoff (as I am aware, E-VPN does not
> support Optimized mode for E-Tree either.
>
> ========
>
>
> Thus we have three proposals on the table:
>
> 1) Leave the design as it is, but add text to describe the constraint and
> what happens if you have to change mode and what to do about it.
>
> 2) Exclude optimization in the FEC PWid(0x80) case
>
> 3) Add an appendix describing support for the FEC PWid(0x80) case.
>
> My inclination would be to go with option (1) but I seek the views of
> the WG, and of course any corrections in my analysis.
>
> - Stewart
>
>
> _______________________________________________
> Pals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pals
>
>

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Sun, 4 Oct 2015 18:19:55 +0000

On 4 Oct 2015, at 16:43, Lizhong Jin <[email-masked]<mailto:[email-masked]>> wrote:

Hi Stewart,

 Then I prefer option 1. Because option2 is not reasonable, and the solution in option3 provided by the author is not the best one.

I would like to provide opition4 for WG to consider:
4) Add description to support for the FEC PWid(0x80) case, in appendix or text I don't care. The solution is:

Listing

Doesn't that waste labels, which may be a problem in some systems, and create a vulnerability since someone may send a packet with that label which would be processed and sent out of the person egress.

-Stewart

Regards
Lizhong

---------- Forwarded message ----------
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 2 Oct 2015 16:41:05 +0100
Subject: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward

=======

   process it as follows:

.....

3) If the P bit is set

      {

      PE and exit the process;

      }

same PW on PE2 again.

========

=========

My opinion is that the draft as it stands is technically correct if you
don't need the ability to reconfigure an existing E-tree service dynamically.

==========

======

========

- Stewart

_______________________________________________
Pals mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pals

---

From: Lizhong Jin <[email-masked]>
Date: Mon, 5 Oct 2015 13:04:37 +0800

Hi Stewart,
For DU mode, if FEC is created, then label should be allocated. For the
vulnerability you mentioned, if I understand your question correctly, the
PW label will not be programmed into hardware, but only kept in control
plane. So the packet will not be wrongly processed.
The MTU interface Sub-TLV defined in RFC4447 section 6.4 said:

If this parameter does not match
       in both directions of a specific PW, that PW MUST NOT be enabled.

The mechanism I proposed is what have been done for MTU interface sub-TLV.

Regards
Lizhong

On Mon, Oct 5, 2015 at 2:19 AM, Stewart Bryant (stbryant) <
[email-masked]> wrote:

>
>
>
>
> On 4 Oct 2015, at 16:43, Lizhong Jin <[email-masked]> wrote:
>
> Hi Stewart,
> Doesn't that waste labels, which may be a problem in some systems, and
> create a vulnerability since someone may send a packet with that label
> which would be processed and sent out of the person egress.
>
> -Stewart
>
> Regards
> Lizhong
>
>
>

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 9 Oct 2015 12:02:47 +0000

Hi all,

We had some discussions on this mechanism when the document was still an individual draft (in fact, when it was being updated to draft-jiang-l2vpn-vpls-pe-etree-03).
Just like Stewart, some service providers were also concerned that this mechanism may result in a great waste of platform labels. For example, in a network with one root PE and 1000 leaf PEs, only 1001 PW labels are needed for the approach in the document; but we will need 1000*999/2=499500 PW labels in all for the proposed mechanism (since leaf to leaf PWs are still allocated). That is the main reason we adopted the current approach.
Therefore, I will regard option 1) as the favorite way forward:
1) Leave the design as it is, but add text to describe the constraint and
what happens if you have to change mode and what to do about it.

I will be glad to see more inputs to this topic.

Thanks,
Yuanlong

From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, October 05, 2015 1:05 PM
To: Stewart Bryant (stbryant)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward

Hi Stewart,
For DU mode, if FEC is created, then label should be allocated. For the vulnerability you mentioned, if I understand your question correctly, the PW label will not be programmed into hardware, but only kept in control plane. So the packet will not be wrongly processed.
The MTU interface Sub-TLV defined in RFC4447 section 6.4 said:

Regards
Lizhong

On Mon, Oct 5, 2015 at 2:19 AM, Stewart Bryant (stbryant) <[email-masked]<mailto:[email-masked]>> wrote:

-Stewart

Regards
Lizhong

---------- Forwarded message ----------
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 2 Oct 2015 16:41:05 +0100
Subject: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward

=======

   process it as follows:

.....

3) If the P bit is set

      {

      PE and exit the process;

      }

same PW on PE2 again.

========

==========

======

========

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 9 Oct 2015 13:34:48 +0100

From my perspective, and with due regard as to where we are, option one
is the one that I would prefer to move things along.

That would not preclude us introducing another RFC at a later date if
there are further operational considerations or alternatives that there
is a consensus to support.

Do we have consensus to move forward with option 1?

Stewart

On 09/10/2015 13:02, Jiangyuanlong wrote:
>
> Hi all,
>
> We had some discussions on this mechanism when the document was still 
> an individual draft (in fact, when it was being updated to 
> draft-jiang-l2vpn-vpls-pe-etree-03).
>
> Just like Stewart, some service providers were also concerned that 
> this mechanism may result in a great waste of platform labels. For 
> example, in a network with one root PE and 1000 leaf PEs, only 1001 PW 
> labels are needed for the approach in the document; but we will need 
> 1000*999/2=499500 PW labels in all for the proposed mechanism (since 
> leaf to leaf PWs are still allocated). That is the main reason we 
> adopted the current approach.
>
> *From:*Lizhong Jin [mailto:[email-masked]]
> *Sent:* Monday, October 05, 2015 1:05 PM
> *To:* Stewart Bryant (stbryant)
> *Cc:* [email-masked]; [email-masked]; 
> [email-masked]
> *Subject:* Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways 
> forward
>
> Hi Stewart,
>
> For DU mode, if FEC is created, then label should be allocated. For 
> the vulnerability you mentioned, if I understand your question 
> correctly, the PW label will not be programmed into hardware, but only 
> kept in control plane. So the packet will not be wrongly processed.
>
> On Mon, Oct 5, 2015 at 2:19 AM, Stewart Bryant (stbryant) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>      Then I prefer option 1. Because option2 is not reasonable, and
>     the solution in option3 provided by the author is not the best one.
>
>     4) Add description to support for the FEC PWid(0x80) case, in
>     appendix or text I don't care. The solution is:
>
>     From: Stewart Bryant <[email-masked] <mailto:[email-masked]>>
>     To: "[email-masked]
>     <mailto:[email-masked]>"
>     <[email-masked]
>     <mailto:[email-masked]>>,
>     "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     Cc: "[email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     a)Disable Optimized mode for FEC PWid(0x80), thus root/leaf role
>     b)Add another appendix into the document for the full support of
>     [email-masked] <mailto:[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 21 Oct 2015 16:52:59 +0100

I have heard nothing back from the group, and so I assume that this
is an acceptable way forward.

Please will the authors make the necessary updates to the text.

Regards

Stewart

On 09/10/2015 13:34, Stewart Bryant wrote:
>> example, in a network with one root PE and 1000 leaf PEs, only 1001 
>> PW labels are needed for the approach in the document; but we will 
>> need 1000*999/2=499500 PW labels in all for the proposed mechanism 
>> (since leaf to leaf PWs are still allocated). That is the main reason 
>> we adopted the current approach.
>>
>> correctly, the PW label will not be programmed into hardware, but 
>> only kept in control plane. So the packet will not be wrongly processed.
>>
>> <[email-masked]> wrote:
>>
>>
>> Doesn't that waste labels, which may be a problem in some systems, 
>> and create a vulnerability since someone may send a packet with that 
>> label which would be processed and sent out of the person egress.
>>
>> -Stewart
>>
>>
>>
>> Regards
>>
>> Lizhong
>>
>>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 28 Oct 2015 06:09:41 +0000

Stewart and all,

We would like to update the draft with the following changes:

1.       Update the reference  “[MEF6.1]” to “[MEF6.2]”, and replace “   [MEF6.1]  Metro Ethernet Forum, "Ethernet Services Definitions -Phase 2", Technical Specification MEF 6.1, April 2008.” with “[MEF6.2] Metro Ethernet Forum, "EVC Ethernet Services Definitions Phase 3", Technical Specification MEF 6.2, August 2014.”

2.       Add the following texts to the end of Section 6.1:  “When VPLS is set up using PWid FEC Element (see Appendix A of [RFC4762]), its E-Tree signaling is similar to the above process. Dynamic re-configuration of E-Tree should be avoided for this case, however, when re-configuration of E-Tree is forced on a PE for some reason (e.g., a configuration error), the PE may close the LDP session with its peer PEs for this VPLS instance, and re-install its PW labels, so that its peer PEs can send out the LDP label mapping message again.”
A new version will be submitted once the IETF site is reopened.
Any other opinions?

Thanks,
Yuanlong

From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, October 21, 2015 11:53 PM
To: Stewart Bryant; Jiangyuanlong; Lizhong Jin
Cc: [email-masked]; [email-masked]; [email-masked]; Stewart Bryant
Subject: Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward

Regards

Stewart

Stewart

Thanks,
Yuanlong

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Stewart,

Regards
Lizhong

-Stewart

Regards
Lizhong

---------- Forwarded message ----------
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 2 Oct 2015 16:41:05 +0100
Subject: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward

=======

   process it as follows:

.....

3) If the P bit is set

      {

      PE and exit the process;

      }

same PW on PE2 again.

========

==========

======

========

- Stewart

Pals mailing list

--