Subject: [mpls-tp] Comments on draft-ietf-mpls-tp-framework-09

From: [email-masked]
Date: Tue, 2 Feb 2010 11:07:58 +0800

Hi Editors and All,

In section 3.4(also reflected in Figure 5) MPLS-TP native services are 
divided into three types:

   o  A PW: PW Demultiplexer and PW encapsulation

   o  An MPLS Label (for example carrying a layer 2 VPN [RFC4664], a
      layer 3 VPN [RFC4364], or a TE-LSP [RFC3209])

   o  An IP packet

RFC4447 section 4 indicates that IP packet can be one particular client of 
PW, and in RFC4446 PW type 0x000B has been allocated to "IP Layer2 
Transport" by IANA.

Why not merge the MPLS-TP native service type "An IP packet" with "A PW" 
and treat "IP packet" as one client of PW like Ethernet?

Best Regards,
Xiao Min

---

From: <[email-masked]>
Date: Tue, 2 Feb 2010 08:56:15 -0000

[email-masked] wrote 02 February 2010 03:08

	Hi Editors and All, 
	
	In section 3.4(also reflected in Figure 5) MPLS-TP native
services are divided into three types: 

	  o  An MPLS Label (for example carrying a layer 2 VPN [RFC4664
<http://tools.ietf.org/html/rfc4664> ], a
	     layer 3 VPN [RFC4364 <http://tools.ietf.org/html/rfc4364>
], or a TE-LSP [RFC3209 <http://tools.ietf.org/html/rfc3209> ])
	
	  o  An IP packet 
	
	RFC4447 section 4 indicates that IP packet can be one particular
client of PW, and in RFC4446 PW type 0x000B has been allocated to "IP
Layer2 Transport" by IANA. 
	
	Why not merge the MPLS-TP native service type "An IP packet"
with "A PW" and treat "IP packet" as one client of PW like Ethernet? 
	
	Best Regards, 
	Xiao Min 

NH=> Your logic is correct.  MPLS-TP SHOULD treat all its DP client
identically.  IP as a DP client of MPLS-TP should be no different to any
other layer network in this respect (but please note that IP is a TOS
layer network and this makes it very special but in a different sense -
see Note at end).

The problem here is that MPLS-TP is still trying to align itself with
some of the flawed architectural behaviours of the LDP type of MPLS.  In
particular this is related to the flawed terms 'L3, L2, L1' that have
origins in the old OSI Ref Model.  This model is just plain technically
wrong.

The only classification of networks that has any solid technical basis
is their mode, ie co-cs, co-ps, cl-ps.  These are ALL 'L3' in the flawed
OSI sense.

One can see just haw wrong this is by taking a concrete example like an
SDH VC4 layer network that uses a GMPLS OOB CP/MP network.  Here we have
a *network system* that is comprised of the co-cs VC4 traffic DP and an
adjunct (logically OOB) CP/MP network that is cl-ps and uses IP-based
signalling (RSVP-TE) and routing (OSPF) protocols.....so there are (at
least) 2 layer networks in this network system working in concert.  So
where is the OSI L3 network layer here?

On the MPLS-TP call last week we went through all this in some detail.
My suggestion was that it would be practically unrealistic to go back
and correct all the standards that have been written that use the flawed
OSI Ref Model terms (this is more than IETF), but what we should do is
try and avoid promulgating this mistake in future standards work.  The
best current model of networks can be found in G.800.

Note - Although IP is not special in a OSI RM L3 sense (ie compared to
some other network technology), it is very special in another way...it
is (what I have started to call) Top-of-Stack (TOS), and what I mean by
this is that IP is able to directly support *external*
message/file/stream applications.  Very few layer network technologies
can do this.  Note carefully that all (and I do mean all) networking
cases must have a TOS layer network present....if this was not true then
all lower level layer networks would serve no purpose.

regards, Neil

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 02 Feb 2010 10:48:53 +0000

[email-masked] wrote:
>   o  An MPLS Label (for example carrying a layer 2 VPN [_RFC4664_ 
> <http://tools.ietf.org/html/rfc4664>], a
>      layer 3 VPN [_RFC4364_ <http://tools.ietf.org/html/rfc4364>], or 
> a TE-LSP [_RFC3209_ <http://tools.ietf.org/html/rfc3209>])
>
>   o  An IP packet
>
> Why not merge the MPLS-TP native service type "An IP packet" with "A 
> PW" and treat "IP packet" as one client of PW like Ethernet?
>
> Best Regards,
> Xiao Min 
Xiao

IP was a client of an LSP since day one of MPLS. It would therefore be 
inconsistent with the MPLS architecture to deprecate IP over LSP.

Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 2 Feb 2010 13:27:09 -0500

In addition to Stewart's answer, the semantics of IP over an LSP vs.
an IP Layer 2 Transport PW are different. In particular, see sections
2 and 8 of http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-08 .

Cheers,
Andy

On Tue, Feb 2, 2010 at 5:48 AM, Stewart Bryant <[email-masked]> wrote:
>>     layer 3 VPN [_RFC4364_ <http://tools.ietf.org/html/rfc4364>], or a
>> TE-LSP [_RFC3209_ <http://tools.ietf.org/html/rfc3209>])
>>
>>  o  An IP packet
>>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 2 Feb 2010 22:27:39 +0200

Andy, Stewart and all,
Thinking aloud: 

IMHO and FWIW carrying IP directly over LSPs may pose serious problems in MPLS-TP environments that do not support 
IP in the dataplane (possibly at reduced speed). 

Please notice that classic transport networks (SONET/SDH, OTN) cannot carry IP as their immediate client. 
They require some intermediate data link layer as their immediate client (e.g., POS or Ethernet). 
I believe (but cannot prove) that this fact reflects evolution of these technologies: Originally have been designed just
for certain "preferred", non-packet types of clients. Adding new clients (POS to SONET/SDH, GbE and 10GbE to OTN) 
was non-trivial and painful (e.g., POS has required an additional level of scrambling in order not to damage the server layer). 

MPLS, on the other hand, has been initially designed to carry IP as its preferred client; other clients (PWs) have been
added later.  As a consequence, MPLS has always relied on congruency of its own topology and IP topology, i.e., all MPLS-capable
nodes and links were presumed to  be IP-capable. (Some people on this list call this "LDP type of MPLS", but IMHO 
this is a misnomer). As a consequence, there is no special arrangement for carrying IS-IS,  ARP or, say, InvARP over LSPs. But these arrangements are required for IP PWs (e.g., see http://www.watersprings.org/pub/id/draft-ietf-l2vpn-arp-mediation-12.txt) and IPLS. 

This observation, IMHO and FWIW, indicates the gap between classical transport networks and MPLS.  

Whether it is possible to bridge this gap in MPLS-TP (i.e., to retain the possibility to carry IP directly as the
LSP client without presuming congruency of IP and MPLS topologies) remains not clear to me.

On the other hand, it seems pretty obvious (at least, within IETF) that IP is going to be the dominant client of the next
generation of transport networks. If MPLS-TP cannot handle it as its direct client, its usefulness, IMHO, will be highly problematic.

My 2c,
     Sasha 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andrew G. Malis
> Sent: Tuesday, February 02, 2010 8:27 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp] Comments on draft-ietf-mpls-tp-framework-09
> 
> >>     layer 3 VPN [_RFC4364_ 
> <http://tools.ietf.org/html/rfc4364>], or a

---

From: <[email-masked]>
Date: Tue, 2 Feb 2010 20:39:32 -0000

Sasha...you wrote:
 
> Please notice that classic transport networks (SONET/SDH, 
> OTN) cannot carry IP as their immediate client. 
> They require some intermediate data link layer as their 
> immediate client (e.g., POS or Ethernet).

Have a look at GFP, which is a generic adaptation function for packet-based clients in transport networks.  There are UPI codepoints that allow the direct carriage of IP (v4 and v6).

regards, Neil 

> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Sent: 02 February 2010 20:28
> To: Andrew G. Malis; [email-masked]
> Cc: [email-masked]
> IMHO and FWIW carrying IP directly over LSPs may pose serious 
> problems in MPLS-TP environments that do not support IP in 
> the dataplane (possibly at reduced speed). 
> 
> Please notice that classic transport networks (SONET/SDH, 
> OTN) cannot carry IP as their immediate client. 
> They require some intermediate data link layer as their 
> immediate client (e.g., POS or Ethernet). 
> I believe (but cannot prove) that this fact reflects 
> evolution of these technologies: Originally have been 
> designed just for certain "preferred", non-packet types of 
> clients. Adding new clients (POS to SONET/SDH, GbE and 10GbE 
> to OTN) was non-trivial and painful (e.g., POS has required 
> an additional level of scrambling in order not to damage the 
> server layer). 
> 
> MPLS, on the other hand, has been initially designed to carry 
> IP as its preferred client; other clients (PWs) have been 
> added later.  As a consequence, MPLS has always relied on 
> congruency of its own topology and IP topology, i.e., all 
> MPLS-capable nodes and links were presumed to  be IP-capable. 
> (Some people on this list call this "LDP type of MPLS", but 
> IMHO this is a misnomer). As a consequence, there is no 
> special arrangement for carrying IS-IS,  ARP or, say, InvARP 
> over LSPs. But these arrangements are required for IP PWs 
> (e.g., see 
> http://www.watersprings.org/pub/id/draft-ietf-l2vpn-arp-mediat
ion-12.txt) and IPLS. 

Whether it is possible to bridge this gap in MPLS-TP (i.e., to retain the possibility to carry IP directly as the LSP client without presuming congruency of IP and MPLS topologies) remains not clear to me.

On the other hand, it seems pretty obvious (at least, within IETF) that IP is going to be the dominant client of the next generation of transport networks. If MPLS-TP cannot handle it as its direct client, its usefulness, IMHO, will be highly problematic.

My 2c,
     Sasha

---

From: [email-masked]
Date: Wed, 3 Feb 2010 14:13:08 +0800

I have the same concern as Sasha.
MPLS-TP is just a subset of MPLS with some important enhancements to 
fulfil transport network requirements.
If the division for IP over an LSP vs an IP Layer 2 Transport PW exists, 
IMHO MPLS-TP MUST support IP Layer 2 Transport PW and MAY support IP over 
an LSP, and detailed description for the second one could be outside the 
scope of MPLS-TP because it has been described explicitly by existing MPLS 
RFCs prior to RFC5654.

BRs,
Xiao Min

Alexander Vainshtein <[email-masked]> 
发件人:  [email-masked]
2010-02-03 04:27

收件人
"Andrew G. Malis" <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [mpls-tp] Comments on draft-ietf-mpls-tp-framework-09

Andy, Stewart and all,
Thinking aloud: 

IMHO and FWIW carrying IP directly over LSPs may pose serious problems in 
MPLS-TP environments that do not support 
IP in the dataplane (possibly at reduced speed). 

Please notice that classic transport networks (SONET/SDH, OTN) cannot 
carry IP as their immediate client. 
They require some intermediate data link layer as their immediate client 
(e.g., POS or Ethernet). 
I believe (but cannot prove) that this fact reflects evolution of these 
technologies: Originally have been designed just
for certain "preferred", non-packet types of clients. Adding new clients 
(POS to SONET/SDH, GbE and 10GbE to OTN) 
was non-trivial and painful (e.g., POS has required an additional level of 
scrambling in order not to damage the server layer). 

MPLS, on the other hand, has been initially designed to carry IP as its 
preferred client; other clients (PWs) have been
added later.  As a consequence, MPLS has always relied on congruency of 
its own topology and IP topology, i.e., all MPLS-capable
nodes and links were presumed to  be IP-capable. (Some people on this list 
call this "LDP type of MPLS", but IMHO 
this is a misnomer). As a consequence, there is no special arrangement for 
carrying IS-IS,  ARP or, say, InvARP over LSPs. But these arrangements are 
required for IP PWs (e.g., see 
http://www.watersprings.org/pub/id/draft-ietf-l2vpn-arp-mediation-12.txt) 
and IPLS. 

This observation, IMHO and FWIW, indicates the gap between classical 
transport networks and MPLS. 

Whether it is possible to bridge this gap in MPLS-TP (i.e., to retain the 
possibility to carry IP directly as the
LSP client without presuming congruency of IP and MPLS topologies) remains 
not clear to me.

On the other hand, it seems pretty obvious (at least, within IETF) that IP 
is going to be the dominant client of the next
generation of transport networks. If MPLS-TP cannot handle it as its 
direct client, its usefulness, IMHO, will be highly problematic.

My 2c,
     Sasha

---

From: <[email-masked]>
Date: Wed, 3 Feb 2010 09:07:13 -0000

Some observations on all these comments:
 
1    IP in a CP (or MP) sense for some co-cs or co-ps mode technology X is not the same as IP as a DP client of server layer X.  The original specification of MPLS did not make this distinction.  This issue is at the root of many of the problems that MPLS as-is has when we try and use it as a transport network. 
 
2    A transport network can only realistically be either co-cs or co-ps (CBR-like) if it is to satisfy client transparency and performance isolation requirements.  A transport network should also have a consistent method of client adaptation (MPLS as-is does not have this).  Moreover, because a transport network must be either co-cs or co-ps then it must be clear on the above distinction (ie point 1) of how IP fits here.  If this is unclear then advice should be sought from CCAMPs because this issue has successfully been dealt with already in developing their generic GMPLS CP solution which can be applied to all co-cs and co-ps mode technologies.
 
3    From the above we can state that if MPLS-TP is truly to be regarded as a transport network then it cannot simply be a 'profile' of MPLS as-is..  However, it can use the same traffic unit structure (even ignoring the fact that TTL and S bit sublayering is not required in a transport network) and also re-use functional components of signalling and routing (as in the GMPLS CP sense...subject to observations 1 and 2 above).  
 
regards, Neil

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 03 February 2010 06:13
	To: Alexander Vainshtein
	Cc: [email-masked]; [email-masked]
	Subject: [mpls-tp] 答复: Re: Comments on draft-ietf-mpls-tp-framework-09

	I have the same concern as Sasha. 
	MPLS-TP is just a subset of MPLS with some important enhancements to fulfil transport network requirements. 
	If the division for IP over an LSP vs an IP Layer 2 Transport PW exists, IMHO MPLS-TP MUST support IP Layer 2 Transport PW and MAY support IP over an LSP, and detailed description for the second one could be outside the scope of MPLS-TP because it has been described explicitly by existing MPLS RFCs prior to RFC5654. 
	
	BRs, 
	Xiao Min 

	

2010-02-03 04:27 

收件人
"Andrew G. Malis" <[email-masked]>, "[email-masked]" <[email-masked]> 
抄送
"[email-masked]" <[email-masked]> 
主题
Re: [mpls-tp] Comments on draft-ietf-mpls-tp-framework-09

	Andy, Stewart and all,
	Thinking aloud: 

	

	
	
	My 2c,
	    Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 3 Feb 2010 13:16:10 +0200

Neil,
Lots of thanks for pointing to that.

I know that these code points have been allocated in GFP. However, AFAIK, they are not used.

Did I miss something?

Regards,
     Sasha

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, February 02, 2010 10:40 PM
> To: Alexander Vainshtein; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls-tp] Comments on draft-ietf-mpls-tp-framework-09
> 
> Sasha...you wrote:
>  
> Have a look at GFP, which is a generic adaptation function 
> for packet-based clients in transport networks.  There are 
> UPI codepoints that allow the direct carriage of IP (v4 and v6).
> 
> regards, Neil 
> 
> 
> Whether it is possible to bridge this gap in MPLS-TP (i.e., 
> to retain the possibility to carry IP directly as the LSP 
> client without presuming congruency of IP and MPLS 
> topologies) remains not clear to me.
> 
> On the other hand, it seems pretty obvious (at least, within 
> IETF) that IP is going to be the dominant client of the next 
> generation of transport networks. If MPLS-TP cannot handle it 
> as its direct client, its usefulness, IMHO, will be highly 
> problematic.
> 
> My 2c,
>      Sasha 
>

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 03 Feb 2010 12:24:43 +0100

Sasha,

As long as IP is a client which is visible only in the MPLS-TP UNI-N ports
there should be no issue for an MPLS-TP network. IP in this scenario is just
another client, very similar to e.g. ATM, TCM, PPP, HDLC clients.

As Neil has noted, IP can be carried in the same manner through SDH and OTN
networks; the mapping on the UNI-N port is IP - GFP-F - SDH C-n - SDH VC-n,
or IP - GFP-F - OTN OPUk - OTN ODUk.

If you want to support a mp2mp or rmp IP service ("I-Tree" and "I-LAN"),
then this is possible via a HVPLS. IP is then mapped into an Ethernet VC
(VLAN) and carried as a rmp or mp2mp HVPLS instance through the MPLS-TP
network. This implies that the HVPLS part of a MPLS-TP based packet
transport network will support two clients: (1) Ethernet and (2) IP.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: dinsdag 2 februari 2010 21:28
To: Andrew G. Malis; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Comments on draft-ietf-mpls-tp-framework-09

Andy, Stewart and all,
Thinking aloud: 

IMHO and FWIW carrying IP directly over LSPs may pose serious problems in
MPLS-TP environments that do not support IP in the dataplane (possibly at
reduced speed). 

Please notice that classic transport networks (SONET/SDH, OTN) cannot carry
IP as their immediate client. 
They require some intermediate data link layer as their immediate client
(e.g., POS or Ethernet). 
I believe (but cannot prove) that this fact reflects evolution of these
technologies: Originally have been designed just for certain "preferred",
non-packet types of clients. Adding new clients (POS to SONET/SDH, GbE and
10GbE to OTN) was non-trivial and painful (e.g., POS has required an
additional level of scrambling in order not to damage the server layer). 

MPLS, on the other hand, has been initially designed to carry IP as its
preferred client; other clients (PWs) have been added later.  As a
consequence, MPLS has always relied on congruency of its own topology and IP
topology, i.e., all MPLS-capable nodes and links were presumed to  be
IP-capable. (Some people on this list call this "LDP type of MPLS", but IMHO
this is a misnomer). As a consequence, there is no special arrangement for
carrying IS-IS,  ARP or, say, InvARP over LSPs. But these arrangements are
required for IP PWs (e.g., see
http://www.watersprings.org/pub/id/draft-ietf-l2vpn-arp-mediation-12.txt)
and IPLS. 

Whether it is possible to bridge this gap in MPLS-TP (i.e., to retain the
possibility to carry IP directly as the LSP client without presuming
congruency of IP and MPLS topologies) remains not clear to me.

On the other hand, it seems pretty obvious (at least, within IETF) that IP
is going to be the dominant client of the next generation of transport
networks. If MPLS-TP cannot handle it as its direct client, its usefulness,
IMHO, will be highly problematic.

My 2c,
     Sasha

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Sun, 7 Feb 2010 21:23:10 +0100

Hi Maarten..
Please see in line - [ll]

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Maarten Vissers
> Sent: 03 February 2010 12:25
> To: 'Alexander Vainshtein'; 'Andrew G. Malis'; [email-masked]
> Cc: [email-masked]
 [ll] what you describe is still VLAN based and forwarding is done on MAC address (with or without the VLAN-ID taken into account when forwarding packets). It is not done on an IP address, and hence the actual service is carried in PW for VPLS, or IP packets...
The HVPLS/VPLS are services of the MPLS-TP.
I don't think that talking about VPLS, IPVPN, etc is relevant to this discussion as it sits ontop of the MPLS-TP PW.

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 8 Feb 2010 08:05:54 +0200

Maarten and all,
I apologize for a delayed response.
Please see inline below.

Regards,
     Sasha
> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: Wednesday, February 03, 2010 1:25 PM
> To: Alexander Vainshtein; 'Andrew G. Malis'; [email-masked]
> Cc: [email-masked]
[[Sasha]] Does this mean that IP is carried over PWs? because ATM, PPP,
HDLC and TDM (I assume that TCM is a typo?) are carried over PWs, not
directly over LSPs.  Which is exactly the problem we are discussing.
>
> As Neil has noted, IP can be carried in the same manner 
> through SDH and OTN networks; the mapping on the UNI-N port is 
> IP - GFP-F - SDH > C-n - SDH VC-n, 
[[Sasha]] I've already responded to Neil on this list that, AFAIK, the GFP
code point for IP is not used. And the reason IP people do not use it is 
that a single code point for IP is NOT ENOUGH; you MUST carry some "helper" 
protocol specific to the given data link in a fate-sharing manner. These 
include IPCP for PPP (including POS), ARP for Ethernet, InvARP for FR and ATM.
In addition, if the link is between routers, you must also be able to carry IS-IS.
Of course, adding a couple of new code points to GFP is not difficult; but
we do not discuss GFP here.

IP over MPLS does not need these helper protocols exactly because MPLS
inherently assumes that IP runs natively on all the data links that 
support MPLS. As a consequence, MPLS does not have a dedicated PID
for encapsulating IP (or any other protocol): 
- if the top label is not popped, next protocol is of no importance
- if the label that is popped is not the last one, the next protocol
is MPLS 
- when the last label is popped, the next protocol and the instance
of the forwarding entity handling this protocol are deduced from 
this label.

MPLS-TP explicitly states that it must be able to run on data links
without IP, and this is the root cause of all the problems when it comes 
to carrying IP over MPLS-TP, be it over PWs or over LSPs.

My 2c,
     Sasha

> problems in
> evolution of these
> IP as its
ion-12.txt)
and IPLS. 

My 2c,
     Sasha

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 08 Feb 2010 10:21:58 +0100

Hi Sasha,

You replied:

> code point for IP is not used.

[hvh] it is built into many devices, so support is available.

> And the reason IP people do not use it is 

[hvh] just for clarification: GFP adapts a packet stream into a
CBR stream and is agnostic to any protocol in the packet stream.
So a single code point to distinguish IP from other packet formats
is enough. The code point is used by the termination function to
verify that it is receiving the expected packet format (just like
the signal label in SDH).

Regards, Huub.

-- 

================================================================
Always remember that you are unique...just like everyone else...

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 8 Feb 2010 11:45:56 +0200

Huub,
Lots of thanks for a prompt response.
Please see inline.

Regards,
     Sasha

> [mailto:[email-masked]] On Behalf Of Huub van Helvoort
> Sent: Monday, February 08, 2010 11:22 AM
> To: [email-masked]
[[Sasha]] Can you point to a router that supports IP over GFP ports?
> the signal label in SDH).
[[Sasha]] HDLC (bit- or octet-synchronous) also adapts a packet stream to a CBR stream.
However, the standard way to carry IP over HDLC is by using PPP in HDLC framing and using IPCP to exchange peer 
IP addresses. You can also carry IP over the so-called "Cisco HDLC" together with InvARP for the same purpose.
Similar approaches are used with IP over FR or ATM (using the so-called "multiprotocol encapsulations").
GFP could, in theory, add a code point for one these "helper protocols" and become IP-capable. 
But without such a code point it isn't. 
And the whole story with IP over PW or IP over an MPLS-TP LSP is about carrying suitable helper protocols.
The IPLS draft mentioned by Andy, and the ARP Mediation draft mentioned in one of my earlier emails provide the
necessary details for the IP-over-PW case.

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 08 Feb 2010 11:24:17 +0100

Hi Sasha,

> [[Sasha]] Can you point to a router that supports IP over GFP ports?

[hvh2] I cannot, and you know that, because there is no such
thing as a GFP port. GFP is a mapping function, so you may
find it in SDH ports on routers.

> [[Sasha]] HDLC (bit- or octet-synchronous) also adapts a packet

[hvh2] that is another solution besides GFP, but how is HDLC
transported by SDH/OTN? I would guess by mapping it in a VC/ODU
with GFP.

Regards, Huub.

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Mon, 8 Feb 2010 11:29:58 +0100

Gents this is a strange discussion
It is not because it has been standardized and not being used that it is not there for us to use (and avoid to re-invent the wheel)

./
Lieven

> Huub van Helvoort
> Sent: 08 February 2010 11:24
> To: [email-masked]
> Importance: High

---

From: <[email-masked]>
Date: Mon, 8 Feb 2010 11:27:39 -0000

One important point below:

> Sent: 08 February 2010 10:24
> To: [email-masked]
> through SDH 
> >>>> and OTN networks; the mapping on the UNI-N port is IP - 
> GFP-F - SDH 
> >>>> > C-n - SDH VC-n, or IP - GFP-F - OTN OPUk - OTN ODUk.
> >>>>
> >>> And the reason IP people do not use it is that a single 
> code point 
> >>> for IP is NOT ENOUGH; you MUST
> >> carry some "helper" 
> >> [hvh] just for clarification: GFP adapts a packet stream 
> into a CBR 
> >> stream and is agnostic to any protocol in the packet stream.
> >> So a single code point to distinguish IP from other packet 
> formats is 
> >> enough. The code point is used by the termination function 
> to verify 
> >> that it is receiving the expected packet format (just like 
> the signal 
> >> label in SDH).
> transported by SDH/OTN? I would guess by mapping it in a 
> VC/ODU with GFP.

NH=> HDLC is a not a good solution for adaptation of cl-ps and co-ps
clients into a co-cs server because it can inflate the client traffic
unit up to 2x it's normal size....which is really not a great idea when
one is trying to manage resource as one does not know the inflation
required until the client traffic unit arrives.  Why?  Because HDLC has
to replace any mimic of its framing symbol in the client traffic unit
with 2 escape symbols....these get removed in the downtream trail sink
termination adaptation function. 

GFP was designed to be a consistent adaptation function for all clients
of a transport network, and it has other advantages besides the one I
mentioned above.

regards, neil

---

From: <[email-masked]>
Date: Mon, 8 Feb 2010 11:46:48 -0000

Sasha...snipped to a point you make below:

>From 08 February 2010 09:46

> However, the standard way to carry IP over HDLC is by using 
> PPP in HDLC framing and using IPCP to exchange peer IP 
> addresses. You can also carry IP over the so-called "Cisco 
> HDLC" together with InvARP for the same purpose.
> Similar approaches are used with IP over FR or ATM (using the 
> so-called "multiprotocol encapsulations").
> And the whole story with IP over PW or IP over an MPLS-TP LSP 
> is about carrying suitable helper protocols.
> The IPLS draft mentioned by Andy, and the ARP Mediation draft 
> mentioned in one of my earlier emails provide the necessary 
> details for the IP-over-PW case. 
> > 

NH=> Whether you intend to or not Sasha, you are making a very good case
for MPLS-TP NOT to become a transport network, ie by retaining certain
behaviours we find in MPLS. 

Indeed, the way MPLS-TP is shaping-up tends to confirm this, eg
-	still treats IP and MPLS clients different to all other
clients....and so still looks like retaining the PW layer network
artefact of MPLS, even though this is obviously unnecessary in a co-ps
mode transport network like MPLS-TP is supposed to be (though this also
does clearly destroy the common CP myth)
-	the 'MPLS client' aspect still retains its digital wrapper
sublayering

Does not have to be like this of course..CCAMPs did a pretty good job in
creating an IP-based generic CP for use in any other co-cs and co-ps
layer (transport!) networks.  

regards, Neil