[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt
-----Original Message-----
From: Stewart Bryant [mailto:stbryant at cisco.com]
Sent: maandag 16 november 2009 14:28
To: HENDERICKX Wim
Cc: pwe3 at ietf.org
Subject: 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.
WH> What I tried to draw is PE(s) attached to the device (drawn with the
box) which is performing the LSR function on a PKT PW to another device
(drawn with the box) which attaching PE(s).
The question is if I have multiple LSPs from different PE(s) through the
PKT PW how are the distinguished. Do I need a separate PID LBL, a
separate PW, etc such that the LSR can make the correct LBL mappings.
>
>> 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
>>
>>
>>
>>
>>
>
>
>
>