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

[<[e-mail]>]

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 


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Alexander Vainshtein
> Sent: 02 February 2010 20:28
> To: Andrew G. Malis; [e-mail]
> Cc: [e-mail]
> 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-mediat
ion-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: [e-mail]
> [mailto:[e-mail]] On Behalf Of Andrew G. Malis
> Sent: Tuesday, February 02, 2010 8:27 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [mpls-tp] Comments on draft-ietf-mpls-tp-framework-09
> 
> 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 <[e-mail]> 
> wrote:
> > [e-mail] wrote:
> >>
> >> 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_ 
> >> <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
> >
> > 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
> > _______________________________________________
> > mpls-tp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 
_______________________________________________
mpls-tp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-tp