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

[Alexander Vainshtein <[e-mail]>]

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

Regards,
     Sasha
> -----Original Message-----
> From: Maarten Vissers [mailto:[e-mail]] 
> Sent: Wednesday, February 03, 2010 1:25 PM
> To: Alexander Vainshtein; 'Andrew G. Malis'; [e-mail]
> Cc: [e-mail]
> Subject: RE: [mpls-tp] Comments on draft-ietf-mpls-tp-framework-09
> 
> 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.
>
[[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, 
> or IP - GFP-F - OTN OPUk - OTN ODUk.
>
[[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


> 
> 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: [e-mail] 
> [mailto:[e-mail]] On Behalf
> Of Alexander Vainshtein
> Sent: dinsdag 2 februari 2010 21: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