[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt
I'm finding this discussion somewhat
bizarre. How can any discussion of MPLS efficiency ignore the fact that
MPLS cannot 'put bits on the wire'? This also relates to the MPLS-TP
discussion, ie MPLS-TP is claimed to be a *transport*
technology.....but how one one say this with a straight face when it would
have to run over a real transport network that has a physical layer
specification (ie binary=>q'ary symbol lexicon mapping) that can modulate an
EM wave in metallic/optical/radio media?
SDH and OTN obviously have physical
layer specifications, but so has Ethernet...indeed it has a very rich support
for all types of metallic/optical/radio media. Which is of course why MPLS
often runs over Ethernet...and which then begs the rather obvious question that
if one simply wants a transport network, then why not use Ethernet per
se?
regards, Neil
I see this as an experiment to
design a pure MPLS transport technology avoid of Ethernet and other L2
encapsulation.
Now it is in
virtual world, but targets at real world.
"Andrew G. Malis"
<amalis at gmail.com>
发件人: pwe3-bounces at ietf.org
2009-11-16 22:38
|
|
收件人
| HENDERICKX Wim
<wim.henderickx at alcatel-lucent.be>
|
|
抄送
| pwe3 at ietf.org,
stbryant at cisco.com
|
|
主题
| Re: [PWE3]
draft-bryant-pwe3-packet-pw-02.txt |
|
Wim,
It's still more efficient on the wire than a simulated
Ethernet PW,
because you would have one less label (the protocol
identifier), but
would add the Ethernet MAC header
instead.
Cheers,
Andy
On Mon, Nov 16, 2009 at 9:03 AM,
HENDERICKX Wim
<wim.henderickx at alcatel-lucent.be> wrote:
> Ok
good, this is what I thought, the client LSP exist in the "client
>
packet Network layer".
>
> Don't you think this is a huge stack
for such a function. You could have
> 4-6 LBL(s) + CW (optionally). I
understand this proposal re-uses
> existing functions defined in MPLS,
but there are lot's of optimizations
> possible here -> we could
combine FAT LBL, PID LBL, CW potentially.
>
> -----Original
Message-----
> From: Stewart Bryant [mailto:stbryant at cisco.com]
>
Sent: maandag 16 november 2009 14:49
> To: HENDERICKX Wim
> Cc:
pwe3 at ietf.org
> Subject: Re: [PWE3]
draft-bryant-pwe3-packet-pw-02.txt
>
>>
>>>
>>>
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.
>>
>>
> Wim
>
> Think of the PW
as a point to point link between a pair of PEs. The PE
> chooses what
traffic to sent over a given PW. The PE then pushes an MPLS
>
>
label to identify the destination. The mid-point LSRs have no clue
what
> is being carried over the LSP. The egress PE unwraps that packet
and
> figures out what the payload is.
>
> RFC3985 applies
to pkt pw as it does to any other PW.
>
> -
Stewart
>
>
>
>
_______________________________________________
> pwe3 mailing
list
> pwe3 at ietf.org
>
https://www.ietf.org/mailman/listinfo/pwe3
>
_______________________________________________
pwe3
mailing
list
pwe3 at ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.