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

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



Title: draft-bryant-pwe3-packet-pw-02.txt

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 ?

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


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.


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
https://www.ietf.org/mailman/listinfo/pwe3