Subject: RE: Connection Verification in PWE3 (was: Comments on draf t-ietf-pwe3-requirements-03.txt)

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 6 Oct 2002 12:30:41 +0200

Mark and all,
I have tried to summarize the discussion on connection
verification (CV), and I have come up with the following:
1. As far as PWE3 is concerned, connection verification 
   (CV) should be considered at two levels:
   * Tunnel verification (TV): verifies integrity of the data
     plane between the two given PE devices
   * Pseudo-wire verification (PWV): verifies integrity of
     the data plane between two ends of the given PW in
     their respective PE devices.
2. The TV mechanisms presumably are be out of scope of the PWE3 WG
   and rely on whatever standard tools are available in the 
   apropriate PSN
3. Tracing is part of the TV, not PVW
4. The PWV mechanisms are within the scope of the PWE3 
   and should be discussed in the requirements document:
   * These mechanisms could be considered as stand-alone or as
     complementing TV
   * The former approach does not scale up well
   * The latter approach reduces the scope of PWV to failures
     of intra-PE connectivity and failures of specific PW 
     end points
5. At least three different approaches to PVW may be mentioned:
   * A control plane-based mechanism for notification of a 
     _recognized_ PW end point failure to its peer
   * A service-specific mechanism (e.g., LMI emulation for FR 
     port mode services, ATM OAM for ATM services etc.)
   * A demuxing layer-specific mechanism (e.g., Y.1711 for PWs 
     that use MPLS for demuxing).
6. Neither of these approaches covers the entire PWE3 scope.

Hopefully these considerations could be useful.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 7:07 PM
> To: [email-masked]
> Cc: [email-masked]; Peter Willis; [email-masked]
> Subject: Re: [PWE3] Comments on draft-ietf-pwe3-requirements-03.txt
> 
> 
> 
> Vach Kompella wrote:
> > Mark,
> > 
> > We are talking about PWs over a GRE encap.  The PWs carry a 
> "key", the inner
> > label, already.  We are just using the MPLS in GRE encap.  
> So there's no tunnel
> > session.
> > 
> > Suppose I want to use L2TP as the transport tunnel between 
> A and B, are you
> > suggesting a completely different encap, i.e., not the
> > draft-ietf-pwe3-ethernet/fr/atm/etc encap?  (I haven't 
> really been keeping up
> > with the L2TP discussions, so forgive the question.)
> 
> L2TP has its own pseudowire identifier -- it does not use the 
> MPLS label format 
> for this (and why should it?).
> 
> > 
> > But I was assuming that the encap for the PW would be the 
> same, and the inner
> 
> The L2 framing would be the same, e.g. carrying the ethernet 
> header in its 
> entirety and such. But from the PW identification down, it's 
> different. Since 
> L2TP's roots are not in MPLS, it doesn't look like MPLS. Please read 
> draft-townsley-pwe3-l2tpv3-00.txt if you would like an overview.
> 
> > label would be the discriminator.  If that is the case, 
> then what I said stands:
> > just because you can get IP-wise from A to B doesn't mean 
> you can get there
> > through an L2TP tunnel.
> 
> As I said before, a PWE3 tunnel in L2TP is just a pair of PE 
> IP addresses. The 
> L2TP sessions are the individual PWs, much like the MPLS 
> label and associated 
> directed LDP sessions are for MPLS over GRE. So, if you are 
> just concerned about 
> the "health" of the tunnel, you can use IP tools to determine 
> that. If you are 
> concerned about the health of the PW (session), you need L2TP 
> tools. Our 
> experience with L2TPv2 tells us that the control plane and 
> associated Hello 
> mechanism covers some of the bases here (I think enough to 
> satisfy the text 
> proposed by Thomas yesterday), though there could naturally 
> be room for 
> improvement as we deploy in different environments.
> 
> So, if ping/traceroute is good enough for MPLS over GRE to 
> test the status of 
> the GRE tunnel, it certainly is for testing the status of the 
> L2TP tunnel. They 
> are, after all, the same thing. Just a pair of PE IP addresses.
> 
> - Mark
> 
>  > So I suppose what I was really talking about is CV not
> > traceroute.
> > 
> > -Vach
> > 
> > 
> >>-----Original Message-----
> >>From: W. Mark Townsley [mailto:[email-masked]]
> >>Sent: Thursday, October 03, 2002 1:39 PM
> >>To: [email-masked]
> >>Cc: [email-masked]; Peter Willis; [email-masked]
> >>Subject: Re: [PWE3] Comments on draft-ietf-pwe3-requirements-03.txt
> >>
> >>
> >>
> >>
> >>Vach Kompella wrote:
> >>
> >>>I guess I don't know enough about L2TP, so I may be wrong, 
> but I don't think
> >>>that just saying that a UDP packet can get from A to B 
> implies that an L2TP
> >>>session (tunnel) can get packets from A to B.  I thought there was
> >>
> >>more to an
> >>
> >>>L2TP "session" than simple IP connectivity?
> >>>
> >>>GRE tunnels don't presume anything more than IP connectivity.
> >>
> >>GRE presumes IP reachability _and_ proper, deliberate, configuration
> >>of two PEs.
> >>This PE configuration must either be entered by a human or a network
> >>management
> >>system of some kind in order for the GRE tunnel to "exist". You need
> >>even more
> >>configuration (e.g. a Key) entered at each PE if you use 
> GRE for L2VPNs, as I
> >>would suspect that you would want some ability to carry 
> more than a single
> >>pseudowire between two like IP addresses.
> >>
> >>Similarly, L2TPv3 presumes IP reachability and proper configuration
> >>at both PEs.
> >>That configuration may be tediously entered manually as it 
> would with GRE, or
> >>ephemeral portions generated and exchanged via a PE to PE 
> signaling protocol.
> >>
> >>Referring to the PWE3 architecture, the "Tunnel" in L2TPv3 refers
> >>literally to a
> >>simple pair of PE IP addresses. Pseudowires then reside within this
> >>"tunnel" as
> >>L2TP sessions.
> >>
> >>Aside, perhaps, of generic per-hop IP load-balancing that 
> may or may not be
> >>present in a given network, all data for L2TP sessions 
> (together with the
> >>control protocol for setting up the sessions) take the same IP path
> >>as that of
> >>the underlying tunnel. Thus, ping and traceroute can be 
> used as effective
> >>measures of L2TPv3 tunnel integrity inasmuch as they are relied upon
> >>today for
> >>reachability of any two nodes or path through an IP network.
> >>
> >>- Mark
> >>
> >>
> >>>-Vach
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: W. Mark Townsley [mailto:[email-masked]]
> >>>>Sent: Thursday, October 03, 2002 12:29 PM
> >>>>To: [email-masked]
> >>>>Cc: [email-masked]; Peter Willis; [email-masked]
> >>>>Subject: Re: [PWE3] Comments on 
> draft-ietf-pwe3-requirements-03.txt
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>Vach Kompella wrote:
> >>>>
> >>>>
> >>>>>Once a packet belonging to a PW is handed to a tunnel, 
> it becomes the
> >>>>>responsibility of the tunnel to get it to the VC 
> endpoint.  Now, a
> >>>>
> >>>>tunnel may
> >>>>
> >>>>
> >>>>>not be nailed down (e.g., GRE).  So it is possible that 
> the "actual
> >>>>
> >>>>path of the
> >>>>
> >>>>
> >>>>>packets" is variable.  So I would say that finding the 
> actual path of the
> >>>>>packets itself can't be a MUST.
> >>>>>
> >>>>>On the other hand, can we say that there MUST be a mechanism for
> >>>>
> >>>>determining the
> >>>>
> >>>>
> >>>>>path a packet takes?  To a large extent, it depends on what the
> >>>>
> >>>>tunnel itself is
> >>>>
> >>>>
> >>>>>that carries the PW's packets.  Is there a traceroute for every
> >>
> >>tunnel type?
> >>
> >>>>>For p2p PWs:
> >>>>>GRE -> traceroute
> >>>>>MPLS -> lsp-ping's traceroute
> >>>>>L2TP -> traceroute (but not good enough)
> >>>>>L2TPv3 (aka UTI) -> traceroute (but not good enough)
> >>>>
> >>>>What specific deficiencies in traceroute are you referring to that
> >>
> >>exist with
> >>
> >>>>L2TP and L2TPv3 (and thus being labeled as "not good 
> enough") that do
> >>>>not exist
> >>>>with GRE (which somehow avoids this title)?
> >>>>
> >>>>
> >>>>
> >>>>>For hierarchical VPLS, there's a traceroute that hops across the
> >>>>
> >>>>PWs that are
> >>>>
> >>>>
> >>>>>stitched together to determine the path.  The tunnels for the
> >>
> >>individual PWs
> >>
> >>>>>also can be tracerouted as in the p2p PWs.
> >>>>>
> >>>>>So except for being unable to foresee what other tunnel types may
> >>>>
> >>>>exist (which
> >>>>
> >>>>
> >>>>>may not have traceroute capability), and that the 
> dependence on the tunnel
> >>>>>having a traceroute capability may be out of scope for PWE3, what
> >>>>
> >>>>is the problem
> >>>>
> >>>>
> >>>>>with saying MUST?
> >>>>>
> >>>>>-Vach
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Eric
> >>>>>>Rosen
> >>>>>>Sent: Thursday, October 03, 2002 10:12 AM
> >>>>>>To: Peter Willis
> >>>>>>Cc: [email-masked]
> >>>>>>Subject: Re: [PWE3] Comments on 
> draft-ietf-pwe3-requirements-03.txt
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>Peter> "there MUST  be a mechanism  for an operator  to find out
> >>
> >>the actual
> >>
> >>>>>>Peter> path  of the  packets  carrying the  PW and  the  path of
> >>
> >>the PW  as
> >>
> >>>>>>Peter> determined by the control plane"
> >>>>>>
> >>>>>>I think that's too  strong, as it is not clear that  this
> >>
> >>requirement can be
> >>
> >>>>>>met in any feasible manner.
> >>>>>>_______________________________________________
> >>>>>>pwe3 mailing list
> >>>>>>[email-masked]
> >>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
> >>>>>
> >>>>>
> >>>>>_______________________________________________
> >>>>>pwe3 mailing list
> >>>>>[email-masked]
> >>>>>https://www1.ietf.org/mailman/listinfo/pwe3
> >>>>>
> >>>>
> >>>
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>