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:
- 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)
- 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:
- 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;
- 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;
- 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:
mpls-tp-bounces at ietf.org [mailto:mpls-tp-bounces at ietf.org] On Behalf Of neil.2.harrison at bt.com
Sent: Friday, August 21, 2009 5:38
AM
To: yljiang at huawei.com;
lucyyong at huawei.com; liu.guoman at zte.com.cn; John.E.Drake2 at boeing.com
Cc: pwe3 at ietf.org;
mpls-tp at ietf.org
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:yljiang at huawei.com]
Sent: 21 August 2009 02:59
To: Yong Lucy;
liu.guoman at zte.com.cn; 'Drake, John E'
Cc: mpls-tp at ietf.org;
Harrison,N,Neil,DEY2 R; pwe3 at ietf.org
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)"
Please see my comments inline.
-----
Original Message -----
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
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?
-----
Original Message -----
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
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:lucyyong at huawei.com]
> Sent:
Wednesday, August 19, 2009 12:44 PM
> To: Drake,
John E; 'Jiang Yuan-long'; neil.2.harrison at bt.com;
> pwe3 at ietf.org
> Cc:
l2tpext at ietf.org
> 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:
pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org]
> On Behalf
> > Of Drake,
John E
> > Sent:
Wednesday, August 19, 2009 8:09 AM
> > To: Jiang
Yuan-long; neil.2.harrison at bt.com; pwe3 at ietf.org
> > Cc:
l2tpext at ietf.org
> > 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:yljiang at huawei.com]
> > >
Sent: Tuesday, August 18, 2009 7:21 PM
> > > To:
neil.2.harrison at bt.com; pwe3 at ietf.org
> > > Cc:
l2tpext at ietf.org
> > >
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: neil.2.harrison at bt.com
> > > To: yljiang at huawei.com ;
pwe3 at ietf.org
> > > Cc: l2tpext at ietf.org
> > > 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: pwe3-bounces at ietf.org
> > >
[mailto:pwe3-bounces at ietf.org] On Behalf Of Jiang Yuan-long
> > > Sent: 18 August 2009 14:01
> > > To: pwe3 at ietf.org
> > > Cc: l2tpext at ietf.org
> > > 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
> >
pwe3 at ietf.org
> >
https://www.ietf.org/mailman/listinfo/pwe3
>
>
>
_______________________________________________
mpls-tp mailing
list
mpls-tp at ietf.org
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.