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

From: [email-masked]
Date: Sun, 6 Oct 2002 13:15:06 +0100

Sasha,  I know there are arguments for covering all PSNs, and that
'emulation' does not equal 'faithful replication of behaviour'.....but I'd
urge some caution here because (speaking as an operator, and wearing my CTO
hat) I feel we ought to have some regard for longer-term convergence issues.
This will be of increasing importance to all operators.  For example,
consider these factors:
-	traditional operators have loads of deployed
SDH/Sonet/ATM/FR.....they are not going to abandon this stuff (esp give
current climate) and so any solutions that ignore factoring these
technologies in (wrt to evolution/migration considerations) will not be seen
as useful.
-	there are 3 network classes:  cnls, co pkt-sw and co cct-sw.  All
technologies fit into one of these. We need *all* 3 of these to cover all
network service requirements.  This should not be a debateable issue (nor
should any technology religion cloud the logic here).....this is just a
fact.
-	The co cct-sw L1 technologies have well-sorted data-plane fault
management.....its second nature to define this as part of the framing
structure when the stds are being defined.  Their control-planes are not
just logically disjoint but can also be physically disjoint, ie they have
their own data-plane/network.  And there are extremely sound technical and
commercial reasons why running a distributed routing protocol here will not
be used by many operators.....signalling yes though.
-	The co pkt-sw technologies are where the major near-term functional
convergence challenges lie.  Most vendors and operators show MPLS as the key
convergence technology here.  So it is vitally important to get the
behaviour of this technology right...and if this requires different
treatment to the general PSN case then I believe that is the right thing to
do.

I won't go further than the above here, but I do hope you can see what I am
saying and why its important.  I have some further remarks in-line below.

regards, Neil

> -----Original Message-----
> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: 06 October 2002 11:31
> To: 'W. Mark Townsley'
> Cc: [email-masked]; Peter Willis; [email-masked]; 
> [email-masked]
> Subject: RE: [PWE3] Connection Verification in PWE3 (was: 
> Comments on draf t-ietf-pwe3-requirements-03.txt)
> 
> 
> 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.
NH=> I agree.  But I would go further than this and say that each layer
network must have its own  (data-plane) fault-handling that is (i)
independent of either client or server layer network technologies and (ii)
independent of the control-plane (inc case of 'none', ie statically
provisioned data-plane trails).  These should be obvious requirements IMO as
the point here is ensuring protocol/layer independence, thereby allowing
independent protocol/layer development (inc removal/replacement) and
avoiding any issues of layer/protocol violation.  If one agrees with this,
then a key factor to take into account is the mapping (adaptation in a G.805
sense) between client/server layer networks wrt fault-handling.  So its not
simply CV considerations (ie detect defects) its also 'consequent actions'
of how the defects are handled, and the correct indications need to be given
to client layers, else one gets alarm storms in those clients.

> 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
NH=> I'd agree with this.  And by making this statement (the way you have)
you are implicitly requiring layer independence for the TV function....which
is of course a correct requirement.  Further, TV (and tools like this) are
'diagnostic' in function, and are used in an ad hoc/on-demand manner.  This
is a very different functional behaviour requirement to
distributed/always-active defect detection/handling mechanisms.  This
distinction is important and such tools should not be unecessarily
combined....they have different functions to fulfil.

> 3. Tracing is part of the TV, not PVW
NH=> Again you are reinforcing the point of layer independence...which is
correct.

> 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
NH=> This is not a good general solution IMO.  In cnls there is only a
single data-plane for everything, but not in co pkt/cct-sw
technologies....but then one does not require (general) signalling in cnls
networks anyway so this is a non-issue here.  The (traffic) data-plane and
the control-plane's sig/routing protocols (which may have a totally disjoint
data-plane of its own) need independent fault-management functions.
Further, the ordering is that data-plane detected defects inform the
control-plane (eg to invoke prot-sw say) and not the other way round.
Similarly, failures of the control-plane should not necessarily cause *any*
changes to the data-plane, eg in VPNs, which have long-holding data-plane
topologies, control-plane failures must not disrupt the data-plane.
>    * A service-specific mechanism (e.g., LMI emulation for FR 
>      port mode services, ATM OAM for ATM services etc.)
NH=> Not quite sure what 'service-specific' is meant to imply....I'd read
this as 'layer independent', which is correct.
>    * A demuxing layer-specific mechanism (e.g., Y.1711 for PWs 
>      that use MPLS for demuxing).
NH=> Not sure I understand what 'demuxing' is meant to imply here....as
above I'd regard this as 'layer independent'.
> 6. Neither of these approaches covers the entire PWE3 scope.
NH=> I'd encourage people to read Y.1710.  Although written as
'requirements' for fault-management of MPLS, it should be obvious to the
reader that the principles given are applicable to all co pkt-sw
technologies.  Y.1711 is simply a minimalist solution for the data-plane in
the p2p case, and is particularly important when looking ahead to
convergence solutions.....which is how I started this response.
> 
> 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
> > 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>