Subject: Re: [PWE3] pwe3 Digest, Vol 51, Issue 36

From: Suresh Babu Gajapathy <[email-masked]>
Date: Thu, 7 Aug 2008 09:25:30 +0530

Hi Mustapha,

Thanks for the reply. The second doubt is that the draft-ietf-pwe3-redundancy-bit-00.txt. suggests 2 methods of advertising/resolving Active/Standby state, Indepedant and Master-slave mode.
Should the implementor support both of them, or it needs to exchanged that this specific mode is supported. Is this configurable parameter. How to ensure interoperability in this case.
Is there any MIB being proposed for PW redundancy.

Thanks
suresh

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Tuesday, July 22, 2008 2:46 PM
To: [email-masked]
Subject: pwe3 Digest, Vol 51, Issue 36

Send pwe3 mailing list submissions to
        [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/pwe3
or, via email, send a message with subject or body 'help' to
        [email-masked]

You can reach the person managing the list at
        [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of pwe3 digest..."

Today's Topics:

   1. Re: PWE3 Redundancy (AISSAOUI Mustapha)
   2. Re: Tandem Connection Monitoring in the new PWE3 Chapter
      ([email-masked])

----------------------------------------------------------------------

Message: 1
Date: Mon, 21 Jul 2008 14:29:14 -0500
From: "AISSAOUI Mustapha" <[email-masked]>
Subject: Re: [PWE3] PWE3 Redundancy
To: "Suresh Babu Gajapathy" <[email-masked]>,
        <[email-masked]>
Message-ID:
        <[email-masked]>

Content-Type: text/plain; charset="us-ascii"

Hi Suresh,
the PW redundancy framework and requirements are described in
draft-ietf-pwe3-redundancy-00.txt.

The elements of the solution are described in
draft-ietf-pwe3-redundancy-bit-00.txt.

Regards,
Mustapha.

________________________________

        From: [email-masked] [mailto:[email-masked]] On
Behalf Of Suresh Babu Gajapathy
        Sent: Thursday, July 17, 2008 7:49 AM
        To: [email-masked]
        Subject: [PWE3] PWE3 Redundancy

        Hi all,

        We are planning to implement PWE3 Redundancy as part of Layer 2
VPN features. I would like to know which draft or RFC should we follow
to implement this. Does CISCO and juniper has implemented PWE3
redundancy ? Can any one tell me draft or RFC supported by cisco or
juniper.

        Is there any new draft coming in the near future for PWE3
redundancy.

        with regards
        suresh

________________________________

        "DISCLAIMER: This message is proprietary to Aricent and is
intended solely for the use of the individual to whom it is addressed.
It may contain privileged or confidential information and should not be
circulated or used for any purpose other than for what it is intended.
If you have received this message in error,please notify the originator
immediately. If you are not the intended recipient, you are notified
that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. Aricent accepts no
responsibility forloss or damage arising from the use of the information
transmitted by this email including damage from virus."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ietf.org/mailman/private/pwe3/attachments/20080721/5cf6a81e/attachment-0001.htm>

------------------------------

Message: 2
Date: Tue, 22 Jul 2008 10:17:00 +0100
From: <[email-masked]>
Subject: Re: [PWE3] Tandem Connection Monitoring in the new PWE3
        Chapter
To: <[email-masked]>,     <[email-masked]>
Cc: [email-masked], [email-masked],
        [email-masked],    [email-masked], [email-masked]
Message-ID:
        <[email-masked]>

Content-Type: text/plain;       charset="us-ascii"

Thanks Italo, you asked 21 July 2008 16:23:

> Could you please clarify what are your specific concerns with
> TCM in "the traditional transport case of very long-holding
> co connections"?
>
> I was not able to find any in your mail.

NH=> In my mail I was showing how TCM is not a universally applicable
idea, and specifically why:
-       when not at top-of-network stack (any mode) one can't appeal to
a multi-party ownership driver for TCM;
-       as holding times reduce the notion of constructing/destructing
nested sublayers becomes less viable.....in the limit one has the cl-ps
mode (IP say) and here I'd regard TCM as not valid at all.

Indeed I did say the most sympathetic case for TCM is long-holding
connections....traditionally what one would associate with
bottom-of-stack transport networks such as SDH, WDM, and this is where
TCM has it's origin a decade or more ago.  The reason this is the most
sympathetic case is that it is the least dynamic wrt set-up/tear-down of
connections.  However, we have same TCM construction/destruction
implications and concerns here, they just happen at a lower rate.

Also remember what I said should be the guiding principles of OAM:
-       as simple/sparse as possible for the mode considered (noting
that OAM requirements are NOT the same for all the network modes)
because the defect detection/handling OAM must be significantly more
reliable than the network/connection it is monitoring;
-       a corollary of the above is minimum things to configure;
-       OAM also has a config/processing/collection cost...OPs folks
will happily turn-off as much OAM as they can...so its better not to
provide them with OAM features we would not consider as adding important
value.

There are secondary considerations such as knowing where traffic is to
be moved to wrt the destruction-of-old/construction-of-new TCM points
and MP/CP co-ordination, and how things like the synchronisation of any
performance measurements are to be handled across routing changes.  I've
never really understood how all this would work, or indeed where it is
all written down/standardised...are all these things documented anywhere
(even if only in patents)?

Having dispensed with the multi-party argument for TCM, one is left with
the single party ownership case. And given the same party owns the
connection end to end then the overwhelmingly more important requirement
is monitoring of the end-end OAM flow.

I also checked out the history of TCM and SDH with Andy Reid who was
intimately involved in all the key SDH standards at the time.  Here is
what Andy had to say on the matter:

" Non-intrusive monitoring was never a "work-around". It came first and
was the only requirement identified in all the main standards
development. It is fully baked into the standards and the standards were
created to support it. It was always understood that non-intrusive
monitoring would be the mainstay OAM mechanism.

TCM came along as a later proposal and it was mainly at the instigation
of one particular operator who was at the time concerned with putting
cross connects into an essentially PDH network. Even they were not sure
exactly how they wanted to use it but their timescales were tight and
money didn't seem to be a major problem. In order to get all the
standards fixed, we agreed that what is in the current SDH TCM was an
optional extra. It was also agreeable because we'd worked out that if
you XORed the new TCM byte value with the old TCM byte value and then
XORed the BIP with the answer, you could 'update' the BIP without
changing its check sum properties with the payload. If there was an
error in the frame, the BIP would stay errored even after the TCM
calculation. Had this trick not been possible, TCM for SDH would not
have been agreed.

As I'm aware, it is still the originally designed e2e monitor including
non-intrusive monitoring that is the overwhelmingly used monitor in SDH
and it has proven very reliable and fits well with operational
processes."

This hopefully helps flesh-out better why TCM has never found much
favour with us, even where it is most applicable, ie long-holding
bottom-of-stack transport network connections.  Perhaps other operators
have different views but I have not heard them so far.

regards, Neil

>
> Thanks, Italo
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Thursday, July 17, 2008 3:15 PM
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: RE: [PWE3] Tandem Connection Monitoring in the new
> > PWE3 Chapter
> >
> > Well put Sasha,
> >
> > We seem to get either feast or famine wrt OAM...neither is required.
> > The other, and in some ways more worrying trend, is an
> attempt to try
> > and treat all 3 network modes as though they are the
> same.....and of
> > course, OAM is only one component in this respect.
> >
> > But I must come back to a key principle here.  If a network
> > technology/mode:
> > -   is used inappropriately for a given service need
> > -   has been specified in way that makes it complex to operate with
> > many potential defects....and one key area here is the
> management of
> > resource, especially when (for certain services) this must be
> > deterministic
> > -   has an intrinsically high defect rate
> > then it is these issues that need to be addressed, not
> overloading the
> > network with lots of OAM.
> >
> > When the 3 modes are each properly functionally specified
> > (over-specification is as bad as under-specification) and used
> > correctly in concert then many otherwise very hard problems become
> > easy, eg if we could have simple mode selection of message/file =>
> > cl-ps and stream => co-ps (co-cs emulation) the we would
> not need any
> > QoS classes per technology/mode at all (this is NOT the same as a
> > survivability importance semantic).  However, I don't
> really want to
> > get into this bigger picture problem here, but I hope most
> folks can
> > sort-of see what I am hinting at wrt attacking complexity
> by thinking
> > outside the 'one mode/technology can do-it-all' traditional box.
> >
> > At the end of the day our biggest enemy is indeed complexity...and
> > this metric is not reducing.
> >
> > But now let me come back to the TCM issue.  It sounds wonderful on
> > paper.  And it usually comes with an argument that
> different parties
> > want to peer their networks.  However, this is NOT generally true
> > except for well defined *top-of-stack* public service networks, eg
> > Internet, PSTN.  Let me do a quick aside to illustrate why peering
> > when we are NOT at the top-of-stack is a bad idea and unnecessary
> > anyway.
> >
> > Start aside=>
> >
> > If we want to peer-interwork 2 network technologies then
> its generally
> > a very good idea if they belong to the same network mode.  If they
> > don't there will be a significant functional mismatch in
> many DP and
> > CP components, which is some cases will not be resolvable
> (noting that
> > we usually do not peer the MP components for security
> reasons, and we
> > similarly restrict the scope of CP components at key interworking
> > points, ie UNIs and ENNIs).  In particular it is NOT sufficient to
> > consider only the OAM component of the DP as I have seen some folks
> > focus on.
> >
> > But let's assume we have excellent alignment of all the DP/CP
> > components in 2 same-mode technologies such that we can
> interwork them
> > as peers.  A key question we should now pose is 'what is
> the DP client
> > component that is passed transparently between the 2 network
> > partitions?'
> >
> > If we in are in a top-of-stack public network situation
> there are (by
> > definition) no higher layer networks...so we must be
> dealing directly
> > with applications....or more accurately their message/file/stream
> > end-system application adaptation functions, eg UDP/TCP/RTP
> in IP, the
> > AALs in ATM, the u/A-law encoding of (voice/stream only) in
> > PSTN.   But
> > many technologies simply don't have such end-system application
> > adaptation functions, eg PDH, SDH, Ethernet, MPLS....or at
> least they
> > don't have them right now.  However, if you REALLY want to peer 2
> > technologies this is the issue you must ultimately
> confront...and one
> > will have either (i) a end-system application adaptation function
> > protocol conversion (if not the same) issue or (ii) force the 2
> > technologies to use the same end-system application adaptation
> > functions.  {Further aside=> check out FRF8 for dealing with ATM/FR
> > interworking, esp in the case of stream applications which
> essentially
> > resorts to handwaving here.}
> >
> > So that is one scenario.....but what if we are NOT at the
> > top-of-stack?
> > Well, we must have a higher layer network in that case and
> we are not
> > dealing directly with end-system application adaptation functions.
> > Indeed, we now realise that it is the higher layer network
> (and all of
> > it's 3 DP/CP/MP components) that is the thing that must be passed
> > transparently between the 2 server layer peer partitions.
> > But hang on a
> > moment...if this is the case then the ONLY practical way of dealing
> > with this is to terminate all DP/CP/MP components of each of the
> > server layer partitions at the interworking function.  In
> other words
> > we have the classical client/server layer network relationship case
> > when we are NOT at the top-of-stack.  And of course this is what we
> > see in practice, eg if I want to build an IP network then I
> can choose
> > to support the link connections in that IP layer network using
> > SDH_VC4, PDH_E1, ATM, Ethernet, etc server layer network
> connections
> > (ie end-end in the server
> > layer) which are fully terminated at the IP layer network nodes and
> > operate completely independent and functionally disjoint from one
> > another.
> >
> > In other words, when we are NOT at the top-of-stack there
> is NO peer
> > interworking requirement at all between the server layer
> technologies
> > that support a higher layer network!
> >
> > So folks need think very carefully about what they really mean when
> > they advocate 'peer interworking' of different or even the
> same mode
> > technologies.
> >
> > <= End Aside
> >
> > Having dispensed with the argument for TCM between
> different parties
> > if we are NOT in a top-of-stack public network service
> case, let's now
> > have look at some of it's other consequences.
> >
> > A network (any mode/technology) has a set of fixed access points
> > (let's put mobile networks to one side here). Communication takes
> > place between such access points.  To get between 2 access points A
> > and B say we require to calculate a route in a graph of
> nodes and link
> > connections.
> > In co mode networks we create a connection (which MUST have the
> > property of single source if we want to also define resource
> > determinism) and this persists for the lifetime of a
> communication, ie
> > all traffic units from A to B always follow the same path.
> We don't
> > create connections in a cl-ps technology and traffic units
> from A to B
> > can follow different paths, in principle on a traffic unit
> by traffic
> > unit basis.
> >
> > In all cases we can quite sensibly define MEPs for these A/B
> > end-points and monitor this for connectivity/performance.  But what
> > about all the intermediate points the path from A to B goes through?
> >
> > Let's take the traditional transport case of very long-holding co
> > connections first as this is most sympathetic to TCM and
> where it had
> > its origins. Because the route is pinned we can sensibly
> define nested
> > sublayer segments of the path and create MEPs here.  (And of course
> > this would be a single party doing this in a non
> top-of-stack case for
> > the reasons I outlined earlier wrt why we usually don't
> want/need-to
> > peer-partition networks when not in public service context).  Works
> > fine.  Now what happens if we want to change the route of the path
> > from A to B, eg planned works or a failure/restoration event?
> > Well, A and B
> > stay in the same place so those MEPs don't alter and we can indeed
> > accurately measure any outage/performance impact of changing the
> > routing.  But what about all the intermediate points?  We need to
> > deconfigure/deactivate the old ones and configure/activate some new
> > ones...assuming we *know* where the new path is going to be and we
> > have all the CP/MP/OSS tools to do this.
> >
> > So there is config cost here (and indeed it is also a
> potential source
> > of unreliability) but it is doable I suppose.  We will have some
> > rather tricky issues wrt accurate performance metric
> accounting across
> > such changes at the nested intermediate points.
> >
> > Now consider the co mode SVC case...or more generally,
> let's assume we
> > are starting to shrink the holding times of the connections of the
> > previous case.  The end-points A and B stay the same...so
> no problems
> > there.  But we now have the question 'at what holding time
> would one
> > not consider it worth the bother/cost of
> configuring/deconfiguring all
> > the intermediate points?'.
> >
> > And I suppose we also should be asking the question 'do we have the
> > CP/MP/OSS tools to do this config/deconfig anyway AND at
> the required
> > construct/destruct rates involved?'  Seems like a law of
> diminishing
> > returns to me even assuming we had such tools and we
> thought TCM was a
> > good idea as the holding times shrink.
> >
> > Now consider the cl-ps mode case.  Here the theoretical
> holding time
> > is a rather small single traffic unit....and we also will
> not usually
> > know where the traffic will be directed, eg post failures.  Hmmm,
> > seems to be a real problem.  Well, we could create a set of
> > pinch-points in the network topology (essentially reduce the graph
> > connectivity to 1 here) so that the nested intermediate points must
> > persist across changes in routing.  But this is hardly a
> good idea as
> > we are now penalising our ability to provide resilience
> just so we can
> > watch these TCM points do their thing.
> >
> > We might, alternatively, overlay a fixed set of nested TCM
> levels in
> > the cl-ps network and pretend it's a co mode network...essentially
> > what is in Y.1731.  I suppose at this point we also have to observe
> > that Ethernet is unusual as a cl-ps mode technology as it
> always must
> > force a connectivity of one per VLAN...so it is most tempting to
> > believe TCM is viable here, just like the long-holding co mode case
> > which I started with.  But this thinking cannot be applied to cl-ps
> > mode networks which have a directed routing function like
> IP and can
> > have a rich/arbitrary meshing with traffic units taking any
> route they
> > like (in
> > principle) and
> > not being forced through a fixed network path.
> >
> > Think I've said enough here for folks to mull over....but
> I'll leave
> > you with 2 final thoughts:
> > -   if TCM was that great don't you think we'd done loads of it by
> > now even where most appropriate?
> > -   if TCM is that universally great, can we see it implemented in
> > IP first please before applying it elsewhere ;-)
> >
> > Regards, Neil
> >
> >
> > > -----Original Message-----
> > > From: Alexander Vainshtein
> > [mailto:[email-masked]]
> > > Sent: 17 July 2008 09:00
> > > To: Italo Busi
> > > Cc: Harrison,N,Neil,CXM R; [email-masked]; Jeremy Brayley; 'Danny
> > > McPherson'; Alik Shimelmits; [email-masked]
> > > Subject: RE: [PWE3] Tandem Connection Monitoring in the new
> > > PWE3 Chapter
> > >
> > > Italo,
> > > Lots of thanks for a detailed clarification.
> > >
> > > I defer to your statement that LO TCM in SDH was not well
> designed
> > > and, in fact, could not be nested.
> > >
> > > I think that that the following example clarifies my position
> > > regarding TCM:
> > >
> > > ANSI has partially followed ITU-T and defined STS TCM (the
> > > equivalent of HO TCM) for SONET networks. It did not
> define VT TCM.
> > > However, the latest available version of GR-253 I could
> put my hands
> > > on does not specify ANY TCM-related requirements that the
> SONET NEs
> > > must match (just mentions  that this functionality has been
> > > defined).
> > >
> > > To me this is a good indication that the SONET operators somehow
> > > manage reasonably well without TCM.
> > >
> > > In a more generic way, I think that there are two
> mindsets when it
> > > comes to defining the  OAM functions:
> > >
> > > Approach 1: "What else potentially useful (including
> useful in some
> > > bizarre scenarios) can be squeezed into the given amount
> of bits and
> > > bytes?"
> > >
> > > Approach 2: "What is the minimum that the operators
> really cannot do
> > > without?"
> > >
> > > IMHO (and FWIW),  Approach 2 is preferable, especially if
> augmented
> > > with some extension potential, while Approach 1 may easily result
> > > not just in "bloated" (I quote Neil)  specs but also in more
> > > expensive equipment.
> > >
> > > My 2c.
> > >         Sasha
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Italo Busi [mailto:[email-masked]]
> > > > Sent: Wednesday, July 16, 2008 3:56 PM
> > > > To: Alexander Vainshtein; [email-masked]
> > > > Cc: [email-masked]; [email-masked]; Jeremy
> Brayley; 'Danny
> > > > McPherson'; Alik Shimelmits
> > > > Subject: RE: [PWE3] Tandem Connection Monitoring in the new
> > > > PWE3 Chapter
> > > >
> > > > Sasha,
> > > >
> > > > I agree with Stewart that we can judge the complexity of Tandem
> > > > Connection Monitoring (TCM) only after we have a
> > description of the
> > > > solution.
> > > >
> > > > Regarding the argument about the usefulness due to the TCM
> > > > implementation for SDH LO (Lower Order) I would highlight that:
> > > >
> > > > - some implementations of LO TCM actually exist
> > > >
> > > > - TCM in SDH was not well-designed (in fact SDH TCM cannot be
> > > > nested): as a
> > > > consequence non-intrusive monitoring has been used as a
> > > work-around to
> > > > "emulate"
> > > > the TCM capabilities (thus supporting nesting)
> > > >
> > > > - this work-around has the disadvantage that the monitoring
> > > > capabilities of an operator depends on the OAM features
> that are
> > > > enabled on the e2e path
> > > >
> > > > - this work-around worked in SDH networks also because
> segmented
> > > > protections are usually based on a 1+1 mechanisms. In
> > > packet networks
> > > > where
> > > > 1:1 mechanisms are
> > > > expected to be used more extensively than 1+1 mechanisms, the
> > > > work-around used in SDH does not work any more and TCM are
> > > required to
> > > > monitor the working and protectino sub-paths
> > > >
> > > > - the limitations of SDH TCM are well known within
> ITU-T and as a
> > > > consequence the requirement to support nested TCM has
> > since then be
> > > > considered very important in all the subsequent OAM
> > designs within
> > > > ITU-T (OTN, Ethernet as well as T-MPLS)
> > > >
> > > > Italo
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf
> > > > > Of Alexander Vainshtein
> > > > > Sent: Thursday, July 10, 2008 1:30 PM
> > > > > To: [email-masked]
> > > > > Cc: [email-masked]; [email-masked]; Jeremy
> > Brayley; Danny
> > > > > McPherson; Alik Shimelmits
> > > > > Subject: Re: [PWE3] Tandem Connection Monitoring in the new
> > > > > PWE3 Chapter
> > > > >
> > > > > Stewart,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Stewart Bryant [mailto:[email-masked]]
> > > > > > Sent: Thursday, July 10, 2008 1:51 PM
> > > > > > To: Alexander Vainshtein
> > > > > > Cc: Danny McPherson; [email-masked];
> > > [email-masked]; Alik
> > > > > > Shimelmits; Jeremy Brayley; Moshe Aharon
> > > > > > Subject: Re: Tandem Connection Monitoring in the new
> > > PWE3 Chapter
> > > > > ... snipped ...
> > > > > > Sasha
> > > > > >
> > > > > > TCM for PWs is in the JWT report:
> > > > > > draft-bryant-mpls-tp-jwt-report-00.pdf
> > > > > >
> > > > > [Sasha] Suspected that. And, BTW, it is not in the draft
> > > itself, it
> > > > > is in the JWT report
> > > > > (http://www.ietf.org/MPLS-TP_overview-22.pdf) referenced by
> > > > the draft.
> > > > > The report also explains that SDH/OTN TCM is a
> special case of
> > > > > "segment OAM", so maybe we should use a more appropriate term.
> > > > > >
> > > > > > It was added when we were asked to flesh out deliverables
> > > > to support
> > > > > > MPLS-TP.
> > > > > >
> > > > > [Sasha] A pity it has not ever been raised explicitly
> > on the list.
> > > > > And, as I read it, the JWT report does not distinguish
> > > between LSPs
> > > > > and PWs with regard to segment OAM (a.k.a. TCM). On the
> > > contrary, it
> > > > > mentions "nested"
> > > > > segment OAM" (see Slide 16 Bullet 2, and the last
> > bullet on Slide
> > > > > 35); and AFAIK, PWs are not nested. So maybe the proper
> > home for
> > > > > this work is the MPLS WG?
> > > > > >
> > > > > > If as you and Neil suggest it's hard to make work, then
> > > > that will be
> > > > > > clear if/when we see drafts defining it, and we can proceed
> > > > > accordingly.
> > > > > >
> > > > > [Sasha] Neil and I have raised not just the complexity
> > issue, but
> > > > > also questioned the usefulness of this feature.
> > > > >
> > > > > > - Stewart
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > _______________________________________________
> > > > > pwe3 mailing list
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/pwe3
> > > > >
> > > >
> > > >
> > >
> >
>
>

------------------------------

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

End of pwe3 Digest, Vol 51, Issue 36
************************************

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility forloss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3