|
Hi Sasha, I think the misunderstanding could be solved if we worded the association to the virtual ES differently. The association is really to a group of PWs that share the same unidirectional
LSP pair (rather than to the LSP, which I can see why is confusing). The multi-homing procedures are done on the PWs and not on the LSPs. In other words, in Figure 2, we could two vESes composed of PW3/PW5 and PW4/PW6, or you could group them together and
have only one vES, i.e. PW3+PW4/PW5+PW6. The latter is a way to reduce the amount of ethernet segments given that e.g., PW3 and PW4 share fate in case one of their transport LSPs fail. About the additional questions: 1. It is my understanding that in the case of LSP as a multi-homed virtual Ethernet Segment, the service carving algorithm would be applied to each individual PW aggregated in this LSP. E.g., in the example of Figure 2 in the draft, the situation in which PW3 is elected as the DF in the {PW3, PW5} pair while PW6 is elected as the DF in the {PW4, PW6} pair may occur. Can you please confirm is this correct? Yes. Note that we are using the definition of Ethernet Tag as in RFC8584, where the Ethernet Tag can be a configured ID or configured EVI value, or etc. as long as it represents the BD
and it is consistently configured on all the PEs attached to the ES. 2. If (1) above is correct, can you please clarify, which value should be used as the Ethernet Tag of the specific PW in this LSP, since the reverence to a VLAN ID in Section 3.5 of the draft looks problematic to me. See above. In the implementations that I know of, an ID identifying the BD is configured consistently in the PEs attached to the ES. That can be a VLAN ID or an EVI or anything as per
RFC8584. I don’t see a problem here. Thanks. Jorge
From: Alexander Vainshtein <Alexander.Vainshtein@xxxxxxxx>
Jorge, Lots of thanks for a prompt response. I will try to summarize our agreements and disagreements. I also have an additional question regarding usage of LSPs as virtual Explicit Segments. First, the summary: 1. As I see, we agree that LSP as a virtual Ethernet Segment actually means “a pair of unidirectional LSPs where the origination endpoint of one matches the termination endpoint of the other”, so that one direction of the aggregated PWs uses on of these LSPs and the other direction – the other one. (This presumably implies that the two LSPs also share the life span). 2. We also seem agree that the (data plane of the) EVPN PE that acts as the tail-end of one of these LSPs MUST be able to identify the PW packets it receives as being delivered in this LSP. This precludes using PHP towards EVPN PE Neither of these points is explicitly mentioned in the current version of the draft (or at least I have not found any mention of them).
Our disagreement seems to be entirely about references to MPLS-TP: 1. You object to restricting LSPs as virtual Ethernet Segment to MPLS-TP and static PWs. 2. From my POV: a. A pair of unidirectional LSPs with a common life span and such that the head-end of one matches the tail-end of the other and vice versa is exactly what RFC 59060 calls an “associated bidirectional LSP” in MPLS-TP b. MPLS-TP also strongly discourages usage of PHP c. These definitions do not say anything about the method by which such a pair of LSPs and the PWs that us it are set up:
i. RFC 6373 defines a framework for dynamically signaling
various types of MPLS-TP LSPs and states that the common PW control plane can be used for signaling PWs that use MPLS-TP LSPs
ii. AFAIK there are implementations of such a control plane. From my POV, my comment would be resolved if you clarified the above-mentioned points of agreement even without mentioning MPLS-TP.
Now my additional question. Sections 3.5 and 4.1 of the draft explain how the default (“service carving”) DF Election algorithm as defined in RFC 7432 could be used with virtual Ethernet Segments.
2. If (1) above is correct, can you please clarify, which value should be used as the Ethernet Tag of the specific PW in this LSP, since the reverence to a VLAN ID in Section 3.5 of the draft looks problematic to me. Regards, and lots opf thanks in advance Sasha From: Jorge Rabadan (Nokia) <jorge.rabadan@xxxxxxxxx>
Hi Sasha, “To me this is equivalent to your definition.” Sure, however, I was not excluding any LSP type, and I don’t think we need to, since the actions are really happening on the PWs riding on those LSPs. So if your suggestion is that we should add text to restrict this to static PWs and MPLS-TP LSPs, I don’t agree. That does not reflect what implementations are
doing. Thanks. Jorge
From: Alexander Vainshtein <Alexander.Vainshtein@xxxxxxxx>
Jorge, Lots of thanks for your response. This indeed may be a matter of terminology. A point-to-point associated bidirectional LSP between LSRs A and B consists of two unidirectional point-to-point LSPs, one from A to B and the other from B to A, which are regarded as a pair providing a single logical bidirectional transport path. To me this is equivalent to your definition. Did I miss something substsntial? Regards, Sasha
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
