Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

[<[e-mail]>]

Maarten,

I see the same issues here as in SG15 unified modelling wrt what
is/is-not a connection.  Irrespective of how one dresses it up this is
the key observation:
-	we can deterministically control resource assignment in p2p and
p2mp constructs (==connections)
-	we cannot deterministically control resource assignment in mp2p
or mp2mp constructs.
....and a whole raft of issues relating to SLAs, performance
inheritance, OAM, etc flow from this.

Trying to force traditional co OAM behaviour in cl mode technologies is
not a good idea IMO, eg AIS....but I do understand the motivation and
good intentions.  Sure we can overlay a set of N fixed points in a cl
mode network and broadcast a periodic CC+BDI function to them
all.....but you honestly expect me to buy-into a set of up to 8 nested
TCM levels all doing this, of which only the outer (ie access points)
remain invariant across failures/restorations?   And as N->large do
really think this is good idea?

Even Y.1731 recognises there is an issue with piggybacking BDI in
CC....section 7.5 says (in particular see text delimited by **):

7.5	Ethernet Remote Defect Indication (ETH-RDI)
Ethernet Remote Defect Indication function (ETH-RDI) can be used by a
MEP to communicate to its peer MEPs that a defect condition has been
encountered. ETH-RDI is used only when ETH-CC transmission is enabled. 
ETH-RDI has the following two applications:
*	Single-ended fault management: The receiving MEP detects an RDI
defect condition, which gets correlated with other defect conditions in
this MEP and may become a fault cause. The absence of received ETH-RDI
information in a single MEP indicates the absence of defects in the
entire MEG
*	Contribution to far-end performance monitoring: It reflects that
there was a defect condition in the far-end which is used as an input to
the performance monitoring process.

A MEP that is in a defect condition transmits frames with ETH-RDI
information. A MEP, upon receiving frames with ETH-RDI information,
determines that its peer MEP has encountered a defect condition.
**However, for multipoint ETH connectivity, a MEP, upon receiving frames
with ETH-RDI information, cannot determine the associated subset of its
peer MEPs with which the MEP transmitting RDI information encounters
defect conditions, as the transmitting MEP itself does not always have
that information.**
Specific configuration information required by a MEP to support ETH-RDI
function is the following:
*	MEG Level - MEG Level at which the MEP exists
*	ETH-RDI transmission period - application dependent and is
configured to be the same as ETH-CC transmission period.
*	Priority -identifies the priority of frames with ETH-RDI
information. The priority is the same as ETH-CC Priority.
*	Drop Eligibility - Frames with ETH-RDI information are always
marked as drop ineligible. This information is not necessarily
configured.
A MIP is transparent to frames with ETH-RDI information and therefore
does not require any configuration information to support ETH-RDI
functionality.
The PDU used to carry ETH-RDI information is CCM, as described in
sub-clause 9.2. 

7.5.1	CCM with ETH-RDI Transmission
A MEP, upon detecting a defect condition with its peer MEP, sets the RDI
field in the CCM frames for the duration of the defect condition. CCM
frames, as described in sub-clause 7.1.1, are transmitted periodically
based on the CCM transmission period, when the MEP is enabled for CCM
frames transmission. When the defect condition clears, the MEP clears
the RDI field in the CCM frames in subsequent transmissions.

7.5.2	CCM with ETH-RDI Reception
Upon receiving a CCM frame, a MEP examines it to ensure that its MEG
Level corresponds to its configured MEG Level and detects RDI condition
if the RDI field is set. For a point-to-point ETH connection, a MEP can
clear the RDI condition when it receives the first CCM frame from its
peer MEP with the RDI field cleared. **For multipoint ETH connectivity,
a MEP can clear the RDI condition when it receives the CCM frames from
its entire list of peer MEP with the RDI field cleared.**

Regards, neil

> -----Original Message-----
> From: Maarten Vissers [mailto:[e-mail]] 
> Sent: 14 July 2008 10:02
> To: Harrison,N,Neil,CXM R; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt 
> as WG draft
> 
> Neil,
> 
> > 2	I note that the BDI (or RDI) function has been 
> piggy-backed in CC
> messages in both Y.1731 and 802.1ag.
> > In the case of co-cs or co-ps mode layer networks this only 
> works for
> symmetrical bidirectional connections,
> > ie p2p constructs only.  It does not work for p2mp connection 
> > constructs
> (as these cannot be bidirectionally symmetric)
> > and so a CC message and a BDI message need to be 
> distinct/independent 
> > OAM
> messages here. 
> 
> You make a mistake here. First you have to specify what a 
> bidirectional p2mp connection looks like and how the traffic 
> flows, then you can address the CC and RDI/BDI OAM mechanism.
> 
> 1) A n-port bidirectional p2mp connection consists of either
>   - one unidirectional p2mp connection from A to Z1..Zn-1 and
>   - n-1 unidirectional p2p connections from Zi to A (i=1, .., n-1), or
>   - one unidirectional p2mp connection from A to Z1..Zn-1 and
>   - one unidirectional mp2p connection from Z1..Zn-1 to A.
> 
> Traffic flows from A to Zi.
> OAM flows from A to Zi and from Zi to A.
> 
> Question: is there also traffic from Zi to A? 
> 
> The second case (p2mp + mp2p) connection can be supported in 
> a transport tunnel layer. This p2mp/mp2p connection carries 
> transport service layer unidirectional and bidirectional p2p 
> connections and/or unidirectional p2mp connections, which 
> have unique label values within the p2mp/mp2p tunnel 
> connection. Example: MPLS p2mp/mp2p tunnel with bidir p2p PWs 
> and unidir p2mp PWs, Ethernet asymmetric VLAN without MAC learning.
> 
> The first case can be supported in a transport service layer 
> and transport tunnel layer. 
> 
> 2) For the first case when there is no traffic from Zi to A, 
> the CC function checks the A to Zi (i=1, .., n-1) maintenance 
> entities and the signal fail status at the Zi ends is 
> reported via RDI/BDI function from Zi to A. The CC fucntion 
> between Zi and A checks if the Zi to A connection is 
> operational and thus able to carry RDI/BDI from Zi.
> There is as such no problem to combine CC and RDI/BDI OAM in 
> a single OAM message.
> 
> For the second case (p2mp/mp2p tunnel connection) CC function 
> checks the A to Zi Maintenance Entities and the signal fail 
> status at the Zi ends is reported via RDI/BDI function from 
> Zi to A. The CC fucntion between Zi and A checks if the Zi to 
> A maintenance entity is operational and carries the RDI/BDI 
> from Zi. At A, the status of the mp2p unidir 'transport 
> entity' is computed from the status of the individual p2p 
> maintenance entities; the result is reported from A to Zi via 
> the RDI/BDI inside the CC from A to Zi.
> There is as such no problem to combine CC and RDI/BDI OAM in 
> a single OAM message.
> 
> Regards,
> Maarten
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of [e-mail]
> Sent: 09 July 2008 21:18
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt 
> as WG draft
> 
> Hi Dinesh and Ali,
> 
> A few observations on the draft and the subject of OAM in 
> general that you might like to take into account:
> 
> 1	Despite what some folks having been trying to do in ITU the OAM
> required for each of the 3 network modes (cl-ps, co-ps and 
> co-cs) is not the same.  For example, AIS is mentioned in the 
> draft.  AIS has its roots in co-cs mode PDH/TDM networks.  
> AIS is about alarm suppression (in co mode clients *above* a 
> server failure) not generating alarms.  It was a direct 
> consequence of old TTL logic when, on failure, the logic 
> 'floated' to +5V (ie binary 1).....so a binary all 1s signal 
> was the natural indication of failure here.  Note in 
> particular it is a passive signal....in the sense that we 
> don't have to actively create special traffic units to mimic 
> it as we would in any packet network.  Further, since the 
> co-cs mode is characterised by a constant bit rate signal AIS 
> is naturally a constant stream of binary all 1s (when 
> replacing the traffic signal).
> 
> AIS is however not a natural signal in packet networks.  And 
> whilst it is understandable to want to have an AIS/FDI OAM 
> function in co-ps mode layer networks (on the assumption they 
> have proper single source connections, ie p2p or p2mp 
> constructs only) it has no meaning in cl-ps mode networks, eg 
> IP, Ethernet.  And this, of course, is why IEEE saw fit to 
> deprecate AIS in 802.1ag for Ethernet OAM.
> 
> My view is that IETF should align its position with that of 
> the IEEE standards when dealing with Ethernet OAM.
> 
> 
> 
> 2	I note that the BDI (or RDI) function has been piggy-backed in
> CC messages in both Y.1731 and 802.1ag.  In the case of co-cs 
> or co-ps mode layer networks this only works for symmetrical 
> bidirectional connections, ie p2p constructs only.  It does 
> not work for p2mp connection constructs (as these cannot be 
> bidirectionally symmetric) and so a CC message and a BDI 
> message need to be distinct/independent OAM messages here.  
> This is something to bear in mind for GMPLS (controlled co-cs 
> mode layer network connections), MPLS and PWs (assuming the 
> case of both these supporting proper single source co-ps connections).
> 
> Now of course Ethernet is a cl-ps mode technology so we don't 
> have connections. However, if we make the OAM CC message a 
> broadcast function between MEPs then we force a condition of 
> symmetry here and so one can, in principle, piggyback BDI in 
> CC messages.....the traffic of course can be, and usually is, 
> unicast (once SA MAC learning has taken place).  So the first 
> observation here is that the OAM is not exercising exactly 
> the same processing path as the traffic.  Further, the 
> indiscriminate broadcasting of BDI to N far-ends wrt to an 
> unknown number of incoming failures is hardly good practice 
> (see section 7.5 in Y.1731).
> 
> However, the key point I am making here is the former one, ie 
> when we are dealing with proper co-cs or co-ps mode p2mp 
> connections we cannot piggyback BDI in CC messages.
> 
> 
> 3	It is a very, very bad idea to have client layer defects
> reflected in a server layer network (be this DP/CP/MP).  I 
> just noted Yaakov also allude to this point in his mail 09 
> July 2008 17:31, viz:
> 
> "However, I would like to reiterate what I said in Philadelphia.
> I am not a great fan of OAM mapping at all, and wouldn't care 
> if the present oam-msg-map draft died a natural death.
> Ethernet to Ethernet PW OAM interworking is an evil, but 
> frequently a necessary one.
> Work on it needs to be expedited."
> 
> Quite.....need to start getting these things right (here a 
> transparent client/server layer network relationship).
> 
> 
> 4	Final, and far more general, point....OAM needs to be uber
> reliable...far more so than the intrinsic failure rate of the 
> network it resides in.  So defect detection/handling OAM 
> needs to be as simple/sparse as possible.  Collecting OAM 
> (esp Perf Mon OAM) information also has a real opex cost.  
> Ops folks will turn-off as much OAM as they can...esp 
> bloated/bad OAM (Y.1731 is bloated IMO).  I've just noticed 
> TCM (Tandem Connection Monitoring) has been added to the
> PWE3 charter.  I would strongly advise IETF *not* to go here 
> just because others have included this in their standards.  
> This idea has been around for many years in ITU and there are 
> very good reasons why very little of it is used in practice 
> (I can spell this out if not obvious).
> 
> Regards, Neil
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] 
> On Behalf 
> > Of Dinesh Mohan
> > Sent: 08 July 2008 16:08
> > To: [e-mail]; pwe3
> > Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt
> > as WG draft
> > 
> > Stewart, of course as an author I support this as a WG draft :-)
> > 
> > FYI...an updated version of the document is also available based on 
> > feedback during the meeting and some further offline
> > discussions:
> > http://www.ietf.org/internet-drafts/draft-mohan-pwe3-mpls-eth-
> > oam-iwk-01
> > .txt
> > 
> > If we agree, this could be the version that can be accepted for 
> > working group draft.
> > 
> > ---
> > Dinesh
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] 
> On Behalf 
> > Of Stewart Bryant
> > Sent: Tuesday, July 08, 2008 7:35 AM
> > To: pwe3
> > Subject: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft
> > 
> > We have a request to accept MPLS and Ethernet OAM Interworking
> > 
> > http://tools.ietf.org/id/draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt
> > 
> > as a working group draft.
> > 
> > The authors thought that PWE3 had already agreed to this, but the 
> > minutes of the last meeting do not say that, and in any case we did 
> > not do a list poll.
> > 
> > Please can we have views on whether to accept as WG draft 
> by COB 15th 
> > July.
> > 
> > Thanks
> > 
> > Stewart/Danny
> > 
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pwe3
> > _______________________________________________
> > pwe3 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pwe3
> > 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
> 
> 
> 
_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3