Subject: Re: [mpls-tp] [PWE3] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

From: [email-masked]
Date: Tue, 25 Aug 2009 16:20:18 +0800

Neil
thank you for replying quickly. according to your meaning. it is also 
unnecessary to consider interworking MPLS-TP and MPLS like PBB-TE and 
original Ethernet. whether we only need to regard mpls and mpls-tp as 
client/server relation? 
 
can my understanding to your meaning be true?

best regards
liu

<[email-masked]> 
2009-08-25 16:02

收件人
<[email-masked]>
抄送

主题
RE: [PWE3] [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: 
An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation 
(PWE3)"

You are very right to make this observation.  The new functions added to 
MPLS-TP will not mean it is compatible or the same layer network as MPLS 
(any type, eg LDP, targeted LDP, BGP4 (rfc2547) or RSVP-TE).
 
We can take an existing traffic unit and create a new layer network from 
it by changing some aspects....addressing is a key one, but other 
functional aspects can also apply.  For example, if I take the Ethernet 
traffic unit which is cl-ps in 802.1D, 802.1ad and 802.1ah spins, I can 
remove the cl-ps CP components (ie STP, BU, SA learning/ageing) and add a 
co mode CP/MP (say GMPLS) and create 802.1Qay, ie PBB-TE....and this is a 
completely different layer network to the original Ethernet cl-ps mode 
layer network even though the traffic units on which each are based is the 
same.
 
You cannot interwork PBB-TE and the original cl-ps type of Ethernet...they 
exist is quite different layer network spaces.
 
regards, Neil

From: [email-masked] [mailto:[email-masked]] 
Sent: 25 August 2009 08:34
To: Niven-jenkins,B,Ben,DMF R
Cc: [email-masked]; [email-masked]; Harrison,N,Neil,DEY2 R; 
[email-masked]
Subject: Re: [PWE3] [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - 
Nee RE: An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge 
Emulation (PWE3)"

ben 
thank you for your replying . IMO. since mpls may be extended to realize 
and encompass MPLS-TP requirements. while from the view of requirements 
aspect or function aspect , MPLS-TP will have more than MPLS. why regard 
mpls-tp as subset of MPLS. I don't see this point. 

best regards 
liu

<[email-masked]> 
2009-08-25 09:26 

收件人
<[email-masked]> 
抄送
<[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]> 
主题
Re: [PWE3] [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: 
An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation 
(PWE3)"

Liu,

MPLS-TP will be a subset of MPLS as MPLS will be extended to encompass
MPLS-TP requirements. Therefore ultimately MPLS will be capable of
everything TP can do and more (the more is the stuff that the Itu 
definition
of transport network does not require).

Ben

On 24/08/2009 03:02, "[email-masked]" <[email-masked]> 
wrote:

>
> ben and all,
> I admit and agree all opinions. IMO. MPLS-TP should not be regarded as 
subset
> of MPLS .because MPLS-TP  will have more requirements of transport 
functions
> than MPLS .
> if we only regard mpls-tp as subset of MPLS. it will not be good and 
helpful
> to develop MPLS-TP functions and standards. in addtional, it is diffcult 
for
> MPLS-TP
> products to be suitable for requirement of packet transport network of 
the
> future very well.
>
> best regards
> liu
>
>
>
>
> <[email-masked]> 2009-08-22 08:30
> 收件人
> <[email-masked]>, <[email-masked]>, 
<[email-masked]>,
> <[email-masked]>, <[email-masked]>, 
<[email-masked]>
> 抄送
> <[email-masked]>, <[email-masked]>
> 主题
> Re: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: 
[PWE3] An
> error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation
> (PWE3)"
>
>
>
>
> Igor,
>
> In my mind the MPLS-TP effort is broadly doing what you suggest. Maybe 
the
> clarity isn't there in all the documents but the intent is broadly 
aligned
> IMO.
>
> Ben
>
>
>
> On 21/08/2009 17:18, "Igor Bryskin" <[email-masked]> wrote:
>
>> Hi Neil,
>>
>> I understand and share your concerns.
>>
>> I think we (IETF folks) made a subtle yet important mistake by agreeing 
to
>> define MPLS-TP as a subset of MPLS needed to support packet switched
>> transport
>> networks. Such definition does not really define how MPLS relates to 
MPLS-TP.
>> In fact, MPLS-TP becomes increasingly a superset of MPLS. What should 
be done
>> IMO is as follows:
>>
>> 1. Separate MPLS into two distinct layers:
>> a)     MPLS Service layer (VPNs. PWs, VPLS, etc.);
>> b)     MPLS transport layer (label-switched transport for MPLS Service 
layer
>> with traffic engineering capabilities)
>> 1. Call the lower layer MPLS-TP and concentrate on its enhancements:
>> a)     Make it work without CP’
>> b)     Make it work for different address families;
>> c)     Expose it to other clients;
>> d)     Extend and improve its OAM;
>> e)     Etc.
>>
>> The important advantages of such architectural approach are:
>> 1. It would be cleat for everyone how MPLS-TP relates to MPLS - it is 
its
>> lower layer, nothing more and nothing less. For example. It would; be 
clear
>> that PWs are NOT a part of the MPLS-TP, there is no difference between 
MPLS
>> PWs and MPLS-TP PWs, and if there is anything wrong with PWs, it should 
be
>> fixed outside of the MPLS-TP effort;
>> 2. It would be also clear the importance of perseverance of MPLS OAM 
wherever
>> possible, and bringing in new (e.g. Y.1731) functionality only when/lf
>> needed;
>> 3. It would provide a niche for (e.g. Ethernet) vendors to develop “
pure”
>> MPLS-TP LSRs without necessarily providing full MPLS Service layer
>> functionality.
>>
>> Cheers,
>> Igor
>>
>>
>>
>> From: [email-masked] [mailto:[email-masked]] On 
Behalf Of
>> [email-masked]
>> Sent: Friday, August 21, 2009 5:38 AM
>> To: [email-masked]; [email-masked]; [email-masked];
>> [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee 
RE:
>> [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge
>> Emulation (PWE3)"
>>
>> Colleagues,
>>
>> I think there are some important issues here that appear not to be 
being
>> tackled correctly...and if we do not get our thinking/arch straight 
here
>> these
>> issues will not go away but surface time and time again until we are 
finally
>> forced to properly resolve them.  Here is my take on the salient 
points.
>>
>> 1   I saw an astute observation from Sasha on the PW CP.  And he was 
right to
>> raise this.  This harps back to my long-standing observation to PWE3 
that
>> once
>> PWs become multi-hop they create a new co-ps layer network above MPLS 
instead
>> of being just client/server adaptation function (1-hop case).  The 
deeper
>> history behind this is related to (i) the requirement in MPLS LDP for 
IP to
>> run raw in the DP to provide CP/MP functions, and (ii) the fact that 
LDP
>> creates mp2p merging LSP constructs.  The important consequence of the 
latter
>> point being that a PW label must convey source information semantics to
>> recover this lost information due to lower level LDP LSP merging. There 
is a
>> further, and still largely unrecognised IMO, problem in that when PWs 
move
>> from 1-hop to multi-hop entities the PW label needs to change semantic 
from
>> 'source information' to 'forwarding information'......I explained this 
issue
>> in detail in a (PWE3) mail to Matthew Bocci  29/11/2008...I attach for 
ease
>> of
>> reference.
>>
>> ====
>>
>>
>> 2   In MPLS-TP we need to be able to deterministically manage resource
>> (because MPLS-TP is supposed to be a next gen transport network, and 
resource
>> management is a principle requirement of transport networks).  This 
means we
>> must only create p2p and p2mp LSPs in MPLS-TP.....mp2p LSPs do not 
allow
>> deterministic resource management because they are not single source
>> *connection* constructs (G.800 explains why this is so).
>>
>> In MPLS-TP we are also required to take the CP/MP IP-based protocols 
out of
>> the traffic DP and run them in the logically OOB G-ACH link between 
adjacent
>> MPLS-TP nodes.....so this correctly follows the OOB CP/MP behaviour we 
are
>> forced to use for the co-cs mode in GMPLS.
>>
>> All these factors mean that the arch conditions that created PWs in 
MPLS no
>> longer exist in MPLS-TP.  Put very simply/bluntly, there is no reason 
to have
>> PWs in MPLS-TP at all....that is just a technical fact.  However, such 
a bald
>> technical statement could be considered rather embarrassing (for want 
of a
>> better word) given how much effort has gone into PW related topics so 
far.
>> Given this, what we can therefore do is keep PWs, in-name at least, but 
be
>> very clear we must not create a co-ps mode PW layer network above 
MPLS-TP.
>> And this is a very good thing because we can avoid generating a whole 
raft of
>> DP/CP/MP functions unnecessarily....which addresses Sasha's observation 
on
>> the
>> PW CP above, ie there is no need for a PW CP because there is not a PW 
layer
>> network in MPLS-TP, and its also addresses my previous point on the 
changing
>> nature of a PW label, ie the problem goes away because MS PWs are not 
allowed
>> in MPLS-TP.
>>
>> ===
>>
>>
>> 3   Let me now turn to section 3.4.1 of the draft under discussion. 
Firstly,
>> I
>> see talk of 'network layer' protocols which harps back to the flawed 
OSI Ref
>> Model architecture.  We really should leave the OSI RM behind now 
because we
>> should know (especially those who have been exposed to functional
>> architecture, and in particular G.800 unified modelling of networks) 
that any
>> technology that has routing/switching is a 'network layer' protocol by
>> definition.  Further, the L1, L2 and L3 classifications of technology 
are
>> meaningless at best, and the only thing that really matters is the 
cl-ps,
>> co-ps and co-cs mode classification of networks....no mode is more 
important
>> than the others, but each is different and all are required in a 
complete
>> network architecture model.
>>
>> ===
>>
>>
>> 4   It would appear from from what is said in section 3.4.1 that (i) we 
can
>> miss-out the PW adaptation for *DP* IP, MPLS and MPLS-TP clients and 
(ii) we
>> can select an arbitrary/normal forwarding label to identify each of 
these
>> clients (S=1 in this BOS header).  I don't think this is a good idea.
>>
>> Let me deal with the 2nd issue first:  This works fine under 
defect-free
>> conditions.  But what about the case of misconnectivity (including 
unintended
>> replication/merging defects)?  So here it would seem that we have a 
1st-order
>> combinatorial '2 out of 4' potential misconnectivity problem, ie across
>> IP/MPLS/MPLS-TP/PW cases (its actually worse than this as MPLS is not
>> singular).  If we are serious about using this 'BOS label' technique to
>> identify the client carried under all conditions (ie including all
>> misconnectivity cases) we really should be using labels that have a 
globally
>> well-known semantic.  In func arch speak we are creating a case of 
consistent
>> CI...and this is also why the OAM used on each LSP in the whole network 
needs
>> to be the same, ie under any case of misconnectivity the receiving node 
knows
>> how to parse and read the semantic of the information it sees (be this 
a
>> label/header or OAM).
>>
>> Wrt to the 1st issue above:  IMO it would be usually be preferable to 
have a
>> single/consistent way to deal with all clients.  So no matter what they 
are
>> they would always be encapsulated via a common PW adaptation function 
(which
>> can include a common PID function).  This is a cleaner/consistent
>> architectural approach.
>>
>> ====
>>
>>
>> 5   There is an important issue I ducked above (on purpose, because it
>> warrants examination on its own), and that is LSP nesting as sublayers, 
ie
>> the
>> S bit issue.  This is particularly important because there will be a
>> requirement on MPLS-TP to be able to create a functionally decoupled 
case of
>> MPLS-TPoverMPLS-TP....that is, where the MPLS-TP layer network of one 
party
>> is
>> carried transparently (all 3 traffic/control/management planes) over 
the
>> (*traffic DP*) of a server MPLS-TP layer network owned by a different 
party.
>>
>>  In the past we have discussed dealing with this by the insertion of a
>> degenerate 1-hop Ethernet PW to create a 'functional breakwater' 
between the
>> 2
>> MPLS networks.  This however in neither elegant nor efficient.  So we 
need a
>> better solution IMO.
>>
>> In the past I suggested we should select a special label from the 
reserved
>> set
>> (ie 0-15) to identify this functional breakwater between different LSP 
stacks
>> (so the S bit could be treated independently in each.  So this approach 
would
>> tie-in with the first case issue discussed under item 4 above, ie 
MPLS-TP as
>> a
>> client would have its own special label (just like the IP and MPLS 
cases
>> too).
>>
>> Alternatively we could use the approach discussed under the second case 
in
>> item 4 above, ie a consistent treatment of all clients using a common 
PW
>> adaptation (that could include a common PID function).
>>
>> ===
>>
>> I assume some/all of the above has been discussed within the MEAD team, 
and
>> it
>> would be useful to hear what analysis/conclusions were reached on the 
above
>> topics and why this was.
>>
>> Would someone from the MEAD team (Stewart or Adrian maybe?) be able to
>> comment
>> on the above please?
>>
>> thanks.....regards, Neil
>>
>>>
>>>
>>>
>>> From: Jiang Yuan-long [mailto:[email-masked]]
>>> Sent: 21 August 2009 02:59
>>> To: Yong Lucy; [email-masked]; 'Drake, John E'
>>> Cc: [email-masked]; Harrison,N,Neil,DEY2 R; [email-masked]
>>> Subject: Re: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D 
- Nee
>>> RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to 
Edge
>>> Emulation (PWE3)"
>>>
>>> Lucy,
>>>
>>>
>>>
>>> Please see my comments inline.
>>>
>>>
>>>
>>>   Thanks
>>>
>>> Yuanlong Jiang
>>>>
>>>> ----- Original Message -----
>>>>
>>>> From: Yong Lucy <mailto:[email-masked]>
>>>>
>>>> To: 'Jiang Yuan-long' <mailto:[email-masked]>  ; 
[email-masked]
>>>> ;
>>>> 'Drake, John E' <mailto:[email-masked]>
>>>>
>>>> Cc: [email-masked] ; [email-masked] ; [email-masked] ;
>>>> [email-masked] ; [email-masked]
>>>>
>>>> Sent: Friday, August 21, 2009 3:14 AM
>>>>
>>>> Subject: RE: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D 
- Nee
>>>> RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge 
to Edge
>>>> Emulation (PWE3)"
>>>>
>>>>
>>>> Hi Jiang and John,
>>>>
>>>> IMO. MPLS-TP supports two types of client: client network layer and 
client
>>>> non-network layer. IP can be as client in both cases. The matter is 
that
>>>> transport characteristics in two methods have some differences. As 
the
>>>> result, to carry a L3 network client, it is required to use the 
service
>>>> label. This is what I try to get clarification from John.
>>>>
>>>> [J]: I don't understand what you meant in the differences of 
transport
>>>> characteristics (in the last Email, you said the PW does not 
guarantee link
>>>> characteristics),IMO, PW can also be a bidrectional p2p connection. 
From
>>>> the
>>>> discussion with Matthew and Sasha, I think the service label may be a 
PW
>>>> label actually.
>>>>
>>>> In fact, both PW label and service label are the bottom label. (S=1). 
This
>>>> is
>>>> the importance. Separating them is to distinguish server transport 
methods,
>>>> not much to the payload itself.
>>>>
>>>> [J]: Yes, in the data plane, PW label and service label is
>>>> undistinguishable.
>>>> But how the egress node will process the demultiplexed IP payload? I 
think
>>>> there are some subtle processing differences:
>>>>   1) If the bottom label is a non-PW label, then the IP packet will 
be
>>>> routed, as in L3VPN;
>>>>   2) If the bottom label is a PW label, then the IP packet will just 
be
>>>> encapsulated with some data link header and forwarded (no routing is
>>>> needed),
>>>> as arp-mediation draft demonstrates.
>>>> Do you think so?
>>>>
>>>>
>>>> Regards,
>>>> Lucy
>>>>
>>>>
>>>>
>>>> From: Jiang Yuan-long [mailto:[email-masked]]
>>>> Sent: Wednesday, August 19, 2009 10:20 PM
>>>> To: [email-masked]; Drake, John E
>>>> Cc: [email-masked]; Yong Lucy; [email-masked];
>>>> [email-masked];
>>>> [email-masked]; [email-masked]
>>>> Subject: Re: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D 
- Nee
>>>> RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge 
to Edge
>>>> Emulation (PWE3)"
>>>>
>>>>
>>>> Hi Liu,
>>>>
>>>>
>>>>
>>>> Mapping our discussion topic to the nomenclature of this draft, it 
is:
>>>>
>>>> Can this service label be a PW label when the payload is IP?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yuanlong
>>>>>
>>>>> ----- Original Message -----
>>>>>
>>>>> From: [email-masked]
>>>>>
>>>>> To: Drake, John E <mailto:[email-masked]>
>>>>>
>>>>> Cc: [email-masked] ; Yong Lucy <mailto:[email-masked]> ;
>>>>> [email-masked] ; [email-masked] ; [email-masked] 
;
>>>>> [email-masked] ; Jiang Yuan-long <mailto:[email-masked]>
>>>>>
>>>>> Sent: Thursday, August 20, 2009 9:53 AM
>>>>>
>>>>> Subject: RE： [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - 
Nee
>>>>> RE:
>>>>> [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to 
Edge
>>>>> Emulation (PWE3)"
>>>>>
>>>>>
>>>>>
>>>>> hi,all
>>>>> I reviewed section 3.4.1 in draft-ieft-mpls-tp-framework-02, for all 
cient
>>>>> services, there is a unite service label(s=1) to identify procotol 
payload
>>>>> type, and The mapping between protocol payload type and Service 
Label is
>>>>> either configured or signaled.
>>>>> if this section will not changed in the future. I think that it is
>>>>> unnecessary to continue to disscuss the topic.
>>>>>
>>>>> how about all?
>>>>>
>>>>> best regards
>>>>> liu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   "Drake, John E" <[email-masked]>
>>>>>  发件人:  [email-masked]  2009-08-20 04:31
>>>>>   收件人   "Yong Lucy" <[email-masked]>, "Jiang Yuan-long"
>>>>> <[email-masked]>, <[email-masked]>, <[email-masked]>
>>>>>   抄送   [email-masked], [email-masked]
>>>>>   主题   [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee 
RE:
>>>>> [PWE3] An error in RFC 4446"IANA Allocations       for
>>>>> PseudowireEdge to Edge Emulation (PWE3)"
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  ie
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Lucy,
>>>>>
>>>>> I'm sorry but I don't understand your conclusion.  I think your
>>>>> penultimate sentence is correct but I don't understand its 
relevance,
>>>>> and your last sentence appears to have precipitated a layer 
inversion.
>>>>>
>>>>> Section 3.4.1 deals with client network layer payloads, where 
'network
>>>>> layer' is defined in RFC 3031 to be "synonymous with layer 3".
>>>>>
>>>>> Thanks,
>>>>>
>>>>> John
>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Yong Lucy [mailto:[email-masked]]
>>>>>>> Sent: Wednesday, August 19, 2009 12:44 PM
>>>>>>> To: Drake, John E; 'Jiang Yuan-long'; [email-masked];
>>>>>>> [email-masked]
>>>>>>> Cc: [email-masked]
>>>>>>> Subject: RE: [PWE3] An error in RFC 4446"IANA Allocations for
>>>>>>> PseudowireEdge to Edge Emulation (PWE3)"
>>>>>>>
>>>>>>> Hi John,
>>>>>>>
>>>>>>> One clarification on this:
>>>>>>>
>>>>>>> When client network layer over MPLS-TP LSP directly, the
>>>>>>> method implies that client network layer can use this MPLS-TP
>>>>>>> LSP as a client network link because the LSP is a
>>>>>>> bidirectional point to point connection. When client traffic
>>>>>>> over a PW, the PW does not guarantee link characteristics.
>>>>>>> Therefore, the method only applies to client non-network layer.
>>>>>>>
>>>>>>> Is my understanding correct?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Lucy
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>>> On Behalf
>>>>>>>>> Of Drake, John E
>>>>>>>>> Sent: Wednesday, August 19, 2009 8:09 AM
>>>>>>>>> To: Jiang Yuan-long; [email-masked]; [email-masked]
>>>>>>>>> Cc: [email-masked]
>>>>>>>>> Subject: Re: [PWE3] An error in RFC 4446 "IANA Allocations for
>>>>>>>>> PseudowireEdge to Edge Emulation (PWE3)"
>>>>>>>>>
>>>>>>>>> Yuanlong Jiang,
>>>>>>>>>
>>>>>>>>> Please see section 3.4.1 of the MPLS TP Framework I-D:
>>>>>>>>>
>>>>>>>>> http://www.ietf.org/id/draft-ietf-mpls-tp-framework-02.txt
>>>>>>>>>
>>>>>>>>> It describes how client network layer payloads (e.g., IP
>>>>>>> and MPLS) are
>>>>>>>>> carried directly, i.e., without a pseudo-wire, over an MPLS
>>>>>>> TP server
>>>>>>>>> network.
>>>>>>>>>
>>>>>>>>> Client non-network layer payloads still use pseudo-wires.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Jiang Yuan-long [mailto:[email-masked]]
>>>>>>>>>>> Sent: Tuesday, August 18, 2009 7:21 PM
>>>>>>>>>>> To: [email-masked]; [email-masked]
>>>>>>>>>>> Cc: [email-masked]
>>>>>>>>>>> Subject: Re: [PWE3] An error in RFC 4446 "IANA Allocations for
>>>>>>>>>>> PseudowireEdge to Edge Emulation (PWE3)"
>>>>>>>>>>>
>>>>>>>>>>> Neil,
>>>>>>>>>>>
>>>>>>>>>>> Thank you for your reply.
>>>>>>>>>>> As Himanshu said in the last email, 0x000B is actually
>>>>>>> the PW type
>>>>>>>>>>> for IP, rather than L2TP PW type for IP. So I believe it is 
also
>>>>>>>>>>> feasible for MPLS-TP.
>>>>>>>>>>>
>>>>>>>>>>> I agree with you that there is some difficulty for MPLS
>>>>>>> label stack
>>>>>>>>>>> to operate in the same manner as client/server layering
>>>>>>> model, but
>>>>>>>>>>> an adaptation layer such as PW functions now is indispensable.
>>>>>>>>>>>
>>>>>>>>>>>  Best Regards
>>>>>>>>>>> Yuanlong Jiang
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                 ----- Original Message -----
>>>>>>>>>>>                 From: [email-masked]
>>>>>>>>>>>                 To: [email-masked] ; [email-masked]
>>>>>>>>>>>                 Cc: [email-masked]
>>>>>>>>>>>                 Sent: Wednesday, August 19, 2009 4:16 AM
>>>>>>>>>>>                 Subject: RE: [PWE3] An error in RFC 4446 "IANA
>>>>>>>> Allocations for
>>>>>>>>>>> Pseudowire Edge to Edge Emulation (PWE3)"
>>>>>>>>>>>
>>>>>>>>>>>                 Hi Yuanlong Jiang,
>>>>>>>>>>>
>>>>>>>>>>>                 Where you said below:
>>>>>>>>>>>                 "I also wonder whether we should define a PW 
type
>>>>>>>>>>> for
>>>>>>> IP payload so
>>>>>>>>>>> that everything on PW is possible"
>>>>>>>>>>>
>>>>>>>>>>>                 This is precisely what a key consequence of
>>>>>>>> MPLS-TP is,
>>>>>>> ie in the
>>>>>>>>>>> LDP spin of MPLS we had to define PWs (one reason being that 
LDP
>>>>>>>>>>> requires that IP traffic units can run native in the DP with 
MPLS
>>>>>>>>>>> traffic units), but given we can't have IP in the MPLS-TP
>>>>>>> DP and we
>>>>>>>>>>> can't have LDP mp2p merging constructs in MPLS-TP anyway
>>>>>>> (the latter
>>>>>>>>>>> point is all about resource management determinism) then the
>>>>>>>>>>> original driver for PWs is gone.....just a fact.  So now
>>>>>>> everything
>>>>>>>>>>> is a PW and nothing is a PW....that is, we just have
>>>>>>> clients (any)
>>>>>>>>>>> of MPLS-TP.
>>>>>>>>>>>
>>>>>>>>>>>                 We still have a tricky issue with the S bit 
that
>>>>>>>> is not fully
>>>>>>>>>>> understood IMO yet (S bit => sublayering, as opposed to true
>>>>>>>>>>> client/server layering), which is also related to the 
important
>>>>>>>>>>> topic of being able to do MPLSoverMPLS as a proper 
client/server
>>>>>>>>>>> relationship.
>>>>>>>>>>>
>>>>>>>>>>>                 So what you point out below will be the case 
in
>>>>>>>> MPLS-TP anyway
>>>>>>>>>>> (though I'm not sure everyone is comfortable with the
>>>>>>> acceptance of
>>>>>>>>>>> this fact yet)
>>>>>>>>>>>
>>>>>>>>>>>                 regards, Neil
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ________________________________
>>>>>>>>>>>
>>>>>>>>>>>                                 From: [email-masked]
>>>>>>>>>>> [mailto:[email-masked]] On Behalf Of Jiang Yuan-long
>>>>>>>>>>>                                 Sent: 18 August 2009 14:01
>>>>>>>>>>>                                 To: [email-masked]
>>>>>>>>>>>                                 Cc: [email-masked]
>>>>>>>>>>>                                 Subject: [PWE3] An error in 
RFC
>>>>>>>> 4446 "IANA
>>>>>>> Allocations for
>>>>>>>>>>> Pseudowire Edge to Edge Emulation (PWE3)"
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                                 Hi, all:
>>>>>>>>>>>
>>>>>>>>>>>                                 I came accross an error in RFC
>>>>>>>> 4446 "IANA
>>>>>>> Allocations for
>>>>>>>>>>> Pseudowire
>>>>>>>>>>>                                 Edge to Edge Emulation 
(PWE3)".
>>>>>>>>>>>                                 In Sec 3.2, it says:
>>>>>>>>>>>                                 "   0x000B  IP Layer2 
Transport
>>>>>>>>>>>             [RFC3032]"
>>>>>>>>>>>
>>>>>>>>>>>                                 it should be:
>>>>>>>>>>>                                    0x000B  IP Layer2 Transport
>>>>>>>>>>>       [draft-ietf-l2tpext-pwe3-ip]
>>>>>>>>>>>
>>>>>>>>>>>                                 The same problem also exists 
in
>>>>>>>> web page version
>>>>>>>>>>> http://www.iana.org/assignments/pwe3-parameters
>>>>>>>>>>> <http://www.iana.org/assignments/pwe3-parameters> .
>>>>>>>>>>>
>>>>>>>>>>>                                 I wonder how about the status 
of
>>>>>>>> this expired
>>>>>>> WG draft, will any
>>>>>>>>>>> more work
>>>>>>>>>>>                                 continue on this document or 
just
>>>>>>>> expired as it is?
>>>>>>>>>>>                                 I also wonder whether we 
should
>>>>>>>> define a PW
>>>>>>> type for IP payload so
>>>>>>>>>>> that
>>>>>>>>>>>                                 everything on PW is possible.
>>>>>>>>>>>                                 Any comments? 
>>>>>>>>>>>
>>>>>>>>>>>                                    Thanks,
>>>>>>>>>>>                                 Yuanlong Jiang
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> pwe3 mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> _______________________________________________
>>>>> mpls-tp mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>>
>>>>> --------------------------------------------------------
>>>>> 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.
>
>
>
>
> --------------------------------------------------------
> 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.

--------------------------------------------------------
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.

--------------------------------------------------------
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.