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

[Alexander Vainshtein <[e-mail]>]

 
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


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Tuesday, February 02, 2010 10:40 PM
> To: Alexander Vainshtein; [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: [mpls-tp] Comments on draft-ietf-mpls-tp-framework-09
> 
> 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
>