[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

HENDERICKX Wim wrote:

-----Original Message-----
From: Stewart Bryant [mailto:stbryant at cisco.com] Sent: zaterdag 14 november 2009 18:16 
To: HENDERICKX Wim
Cc: pwe3 at ietf.org
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

HENDERICKX Wim wrote:

Stewart, more in-line indicated with WH>




------------------------------------------------------------------------

*From:* Stewart Bryant [mailto:stbryant at cisco.com]
*Sent:* donderdag 12 november 2009 16:42
*To:* HENDERICKX Wim
*Cc:* pwe3 at ietf.org
*Subject:* Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt


HENDERICKX Wim wrote:

Steward,
Had a few question/clarification on the following draft: draft-bryant-pwe3-packet-pw-02.txt 

1.      As discussed we could also have LER functionality besides LSR.
It would be good to clarify the encapsulation which would be used for IP-VPN or PW services using the packet PW service. 

We will add the clarification

Do we use 2 MPLS labels (service and transport)

The inner labels presented from the embedded client router are exactly



the same as the would be if the packet was going over a real data link



over a physical wire. Instead of using a real data link we use a label
to represent the PID in the datalink, and the use the PW in place of the physical wire.
WH> if we have multiple client services e.g. multiple LSR LSPs to different destinations how would they be distinguished in the case of the pkt-PW ?
SB> The ingress PE needs a PW to each egress PE that they have client traffic for. It is up to the embedded client router to select the correct pkt PW, i.e. the one that terminates on the egress PE that hosts 

the embedded client router that is the next hop in the client layer.


WH> what I meant is this:

            --------                       --------
   PE1-----|        |                     |        | --- PE3
           |  LSR   |------- PKT PW ------|  LSR   |
           |        |                     |        |
   PE2-----|        |                     |        |---- PE4
            --------                       --------

Assume PE1 has a LSP to PE3 and PE2 has an LSP to PE4, how is this
distinguished on the PKT PW ?
SB> I am not sure what you have drawn there, but it is not what is shown in the draft. The pkt pw run between the PEs and is carried over the LSPs. PWs are distinguished from each other at the PE via the PW label.
2. Is my understanding correct that for each protocol type we need to signal a different label? Meaning IP services get a label X, MPLS services get label Y, etc
In essence I get a different label for each protocol type I transport over this PW? 

Yes
If this is correct why do I not use a standard ETH PW for this since it has all these capabilities already. 

Three reasons:

1) We need 4 bytes instead of 14 bytes


WH> right but we need to signal more PID labels, one per protocol type


SB> Sure, but that is a control plane action.

WH> but the data-plane needs also the label per protocol type unless we
make them static.
SB> I don't understand what you are saying here. This is normal MPLS. You decide on a mapping between a label value and a context, and signal that mapping to your peer, who programs their hardware accordingly. There is no need for static labels. 
2) A pt-pt link has lower adjacency formation overhead
WH> I believe that for IGPs and MPLS links there are options for P2P support on ETH which would be the same.
SB> Yes, though there are some sublties. You still need to used ARP and the Multicast addresses. 

WH> this is correct
3) This is more consistent with RFC3031 which says that the protocol after the label with the S bit is learned from the context provided by
the label with the S bit. This was one of the areas that caused significant discussion in the MPLS-TP client design, and although pkt -PW is part of mainstream PWE3 rather than MPLS-TP it is good to be consistent. 


WH> understood

WH> We might want to clarify the above in the draft


If a vendor wished to deliver this service via a virtual Ethernet they
can, and no protocol specifications are required beyond those that already exist in PWE3. 

- Stewart



Cheers,

Wim





------------------------------------------------------------------------
_______________________________________________ 
pwe3 mailing list
pwe3 at ietf.org <mailto:pwe3 at ietf.org>
https://www.ietf.org/mailman/listinfo/pwe3