Subject: Re: [mpls-tp] Discussion of whether to adoptdraft-asm-mpls-tp-bfd-cc-cv as a mplsworking group document

From: Curtis Villamizar <[email-masked]>
Date: Mon, 07 Jun 2010 15:02:56 -0400

Maarten,

A good reason to use BFD rather than Y.1731 for MPLS-TP OAM is so that
there are not two MPLS OAM, one for MPLS for packet networks and one
for MPLS-TP.  In many deployments, particularly core, the two will
very closely coexist and in some case may be managed by the same
entity.  Having one OAM for MPLS and MPLS-TP would be preferable.

The WG should be adding functionality to the existing OAM, not
removing.  If is fine to indicate BFD capabilities which are not
applicable to MPLS-TP.  Some capabilities must remain in BFD and MPLS
ping even though MPLS-TP does not need them.  Likewise, some
capabilites needed for MPLS-TP will not be applicable to packet
networks (as opposed to packet transport networks and TP).

Curtis

In message <[email-masked]>
Maarten Vissers writes:
>  
> Greg,
>  
> Thank you for reminding us to the scope of the MPLS-TP work being "packet
> network' and that 'packet transport network' will use a subset applicable to
> transport networks. 
>  
> In Figure 1 of the latest version (-12) of the framework draft it is
> illustrated that the pre-RFC5654 MPLS is complemented with 
> - "Additional Transport Functions" and with 
> - "Post-RFC5654 non-Transport Functions".
>  
> OAM for **non-transport networks** would be an element in this latter
> "Post-RFC5654 non-Transport Functions" part of MPLS, while OAM for
> **transport networks** would be an element in the former "Additional
> Transport Functions" part of MPLS and be part of MPLS-TP.
>  
> Without doubt, draft-bhh-mpls-tp-oam-y1731 is addressing "Additional
> Transport Functions".
>  
> My question is if BFD/LSP Ping extensions are addressing "Post-RFC5654
> non-Transport Functions"? 
>  
> Regards,
> Maarten
>  
>  
>  
>  
>   |<============================== MPLS ==============================>|
>                                                      { Post-RFC5654    }
>                                                      { non-Transport   }
>                                                      {   Functions     }
>   |<========== Pre-RFC5654 MPLS ===========>|
>   {      ECMP       }
>   { LDP/non-TE LSPs }
>   {     IP fwd      }
>  
>                     |<======== MPLS-TP ============>|
>                                        { Additional }
>                                        {  Transport }
>                                        {  Functions }
>  
>  
>  
>                         Figure 1: Scope of MPLS-TP
>  
>  
> ________________________________
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Greg Mirsky
> Sent: woensdag 19 mei 2010 21:43
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] Discussion of whether to
> adoptdraft-asm-mpls-tp-bfd-cc-cv as a mplsworking group document
>  
>  
> Dear Neil,
> your concerns regarding inclusiveness of MPLS-TP are valid. I just would
> note that as lately MPLS-TP is referred as "packet network", not "packet
> transport network". Last paragraph of Section 3.2 of Framework of MPLS-TP in
> Transport Networks notes that subset of MPLS-TP is applicable to transport
> networks as defined by ITU-T. Those who would use MPLS-TP to build packet
> transport with MPLS-TP will have to carefully select proper tool set.
>  
> Regards,
> Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 7 Jun 2010 19:04:27 -0700

Dear Curtis,
I'm concerned that at moments in the discussion we might forget how far from
original BFD or Y.1731 their use in MPLS-TP OAM might really be. At least
for BFD, as description of its application as MPLS-TP CV/CC/RDI is more
advanced, I see less and less BFD Base functionality in regard to timers
negotiation, discriminators and on what information sessions being
demultiplexed. It looks as BFD-based MPLS-TP OAM is limited to re-using BFD
PDU where we can while we extend its functionality with ACH TLV. It is
certainly sound approach to re-use existing mechanisms and solutions, but I
don't see MPLS OAM as something that firmly established now and to which
we'd like MPLS-TP OAM to be backward compatible. The biggest issue, in my
view, is required use of Unique MEP ID in MPLS-TP OAM whereas MPLS, or
non-MPLS-TP to be more precise, OAM will probably not require this ID and
might use IP UDP encapsulation of BFD control packets.

Regards,
Greg