headers
Yaakov Stein | 3 Aug 2008 15:35
Favicon

PWE congestion draft

Stewart / Bruce
 
In order to progress this draft, I would like to break down my comments
into small pieces and see if we can resolve them one at a time.
 
Before raising teleological questions, I would like to get an answer to an ontological one.
 
In the draft you state
  In these environments the operator needs to make a judgement call on
  a fair estimate of the number of equivalent flows that the PW
  represents.
and
   In the PW environment some estimate (measured or configured) of the
   number flows in the PW needs to be applied to the estimate of fair
   throughput as part of the process of determining appropriate
   congestion behavior.
When I first read these sentences, I was relatively sure that I knew what they meant,
but afterwards I realized that there are several possibilities.
Upon discussing the matter with Stewart,
I discovered that perhaps I did not guess correctly which of these possibilities was intended.
 
I can think of at least three possibilities as to the meaning of these sentences:.
 
1) When a packet is lost, the egress PE notifies the ingress PE (similar to TCP),
but rather than the ingress decreasing the (maximum) sending rate to 1/2,
the rate is decreased by 1 / 2N. For example, if N=10, instead of reducing by 50 %,
we reduce by 5%.
(We won't discuss the mechanism for enforcing this rate reduction yet,
as this will be the subject of another email.)
As discussed in previous emails (and in the slides that I didn't get to present in Dublin)
this is what would happen automatically is the PW carries TCP/IP flows with
one TCP/IP packet per PW packet.
This is how I initially understood the draft.
Note that thuis mechanism does not require change to intermediate nodes,
but necessitates a new mechanism for feedback from egress PE to ingress PE.
 
2) When a packet is lost, the ingress is notified, but no rate decrease is enforced.
Only after N packets are lost (within some time span) is the rate decreased to 1/2.
This has the advantage of forestalling the policing of the PW,
but the disadvantage of a rather sudden drop in capacity later on.
From a chat with Stewart, I believe this is what he had in mind.
 
3) When intermediate nodes become congested and need to drop a packet,
they drop a packet belonging to the PW with probability 1/N of that of an individual TCP/IP flow.
Thereafter, the egress informs the ingress, and policing is carried out according to method 1.
 
There are several ways of carrying out the packet dropping :
3a) intermediate nodes maintain state as to PW weightings
3b) ingress PEs encode the value of N in the packet header (no state in intermediate nodes)
3c) ingress PEs indicate drop precedence of every N'th packet (no state in intermediate nodes).
 
I assume that 3a is ruled out due to the memory requirements.
3b requires generating random numbers and performing a comparison per packet
(but only when there is congestion), while 3c is the simplest to implement,
and furthermore leaves the decision on which packets to drop to the ingress PE,
which may be in the best situation to know which packets should be dropped.
 
Can I ask the authors to reply as to which of the proposed possibilities (1, 2, 3a, 3b, 3c)
they intended - or did they intend some option 4 ?
 
Y(J)S
 
 
_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
Permalink | Reply | 501 comments |
headers
Stewart Bryant | 4 Aug 2008 17:04
Picon
Favicon

Please volunteer for nomcom

Forwarded from Nomcom Chair

From: NomCom Chair <nomcom-chair <at> ietf.org>
To: Working Group Chairs
Date: August 3, 2008
Subject: Please ask your WG...

To volunteer for the nomcom.
The nomcom process is (in my opinion) better served by a large pool of
volunteers drawn from a wide spectrum of IETF attendees.
As such, please ask on your individual mailing lists for folks to
volunteer.

Obviously, the exact method for doing so is up to you.
The most recent call for volunteers can be reference here:
    https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1617
Whether you copy that message, or reference is probably up to you and the
habits of your working group mailing list.
If you want to reference or copy the status message I sent out, that can
be found at:
    https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1618

Thank you,
Joel M. Halpern
Nomcom Chair
jmh <at> joelahlpern.com
nomcom-chair <at> ietf.org
Permalink | Reply | 0 comments |
headers
Yaakov Stein | 4 Aug 2008 18:30
Favicon

Re: PWE congestion draft

 > Yaakov,
 >  In our quest to make sure we're on the same page, let me start by trying to decipher the above sentence.  
 >  I assume you mean you want to be sure you understand our meaning before arguing with us about our intentions?
 
I couldn't put it better - I need to understand what your are proposing,
before attempting to determine if I agree that it solves the problem at hand.
Once we agree on the meaning of your proposal, we can decide how useful/effective/efficient/etc it is.

>  I think your email actually indicates that you misunderstand the intent of our draft. It is meant to be a *framework* draft (hence the title) 
>  and as such it is not trying to say what mechanism should be deployed. I think you are having trouble understanding what we mean  
>  because you assume that we have a mechanism in mind when we describe only a high level policy.  
>  In fact we are really trying NOT to propose a mechanism here. (Separating policy from mechanism is, I'm sure you know,  
>  an age-old principle in computer science.) To the extent that the current draft talks about mechanisms,  
>  we're mostly trying to illustrate that all mechanisms that we know of have shortcomings,  
>  and hence this is a hard problem space to solve correctly.
 
First, as you admit here, you discuss quite a few mechanisms. You mostly reject them
and propose instead some principles. Even in a framework draft these principles should
be compared to the existing mechanisms, or at least described in sufficient detail that we can understand
possible side-effects. 
I quite understand that you don't want to go into the precise formats of messages, etc. - 
but at least I can't understand what you propose if we do not have at least "some" mechanism in mind.  
>  In fact none of your guesses is correct, because, as I've said, we're not trying to propose a mechanism.  
 
Or, perhaps all of them ?
 
> We're trying to describe a high-level objective for PW congestion.
>  Let me try to put this another way that may be easier to understand.

>  Assume there is a PW running over a network that is congested enough to occasionally experience loss,  
>  and that the loss occasionally affects packets of the PW.  
>  (I think you have argued in some prior emails that such networks should not exist, but I'll ask you to suspend disbelief for a moment).  
 
No, I never said that there will not be congestion for PWs.
I just don't think that the most important case is PWs over the public Internet
or PWs in parallel with individual TCP/IP flows.
 
>  The main objective of this PW congestion work is to ensure that such loss is not ignored,  
>  that is, the PW does not just keep on sending packets into the network at the same rate or, even worse, send more packets.

>  Now there is a well-known equation for the long term throughput of a TCP flow for a given loss rate, RTT, and MSS (packet size).  
>  (See RFC 3448 for a quick summary.)  Call this the "single flow TCP fair rate". If a PW were carrying a single flow,  
>  and experiencing a certain loss rate, and its long term average throughput where much higher than the the single flow TCP fair rate,  
>  we could argue that it is not responding correctly to the fact that packets are getting lost.  
>  However, if the PW happened to be carrying 100 flows, then of course we would expect that the long term average throughput  
>  of the PW should be 100 times the single flow TCP fair rate. 
 
Yes, I understood this reasoning. I just want to delve a bit deeper into how you are proposing
to enforce this importance weighting, and what its effect on the PW and the surrounding will be.

< snip>
 
>  Now I have some mechanisms in mind for how I would build this stuff.  
>  But that is not the job of the framework to describe those mechanisms.  
>  I will say however that anything involving help from the interior nodes is a non-starter,  
>  because we are very much trying to avoid congestion collapse on existing IP networks.  
 
Once again, that is understandable for the PW over the general Internet case.
While a valid case in principle, and perhaps one that the IETF as a whole really wants us to address,
I don't believe that it is the most important one for us to solve.
 
> So we can rule out option 3 as a feasible mechanism. But like I said, the above paragraph is about policy, not mechanism.
 
But you see how fast the difference between policy and mechanism becomes blurred ? 
 
You talk about considering the PW to be equivalent to some number of flows.
I must assume that in addition to yourself, you imagine that some network element is cognizant of this fact,
as otherwise the statement does not lead to the PW being treated operationally as N flows.
That network element takes some action that uses the information (i.e. its knowledge of "N").
I think that which network elements you consider to be relevant and what the kinds of actions you have in mind
are completely relevant to a framework draft - indeed they are part of what you call "high level policy".
 

Y(J)S
 
_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
Permalink | Reply | 1 comment |
headers
Christian Vogt | 6 Aug 2008 16:22

Gen-ART Review of draft-ietf-pwe3-cep-mib-12

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document..........:  draft-ietf-pwe3-cep-mib-12
Reviewer..........:  Christian Vogt
Review date.......:  August 6, 2007

Summary:  This draft is ready for publication as a Proposed Standard
RFC

I have no objections against publishing this document, yet would
suggest considering the following three comments:

- Introductory sections 1 through 4:  References to related documents
   are currently scattered across these sections.  It would in my
   opinion make sense to group all these references in a single
   section, perhaps section 1.  This would make it easier for the
   reader to go back and look them up as it becomes necessary while
   reading the document.

- Security Considerations section:  The vulnerabilities discussed in
   this section do not directly fit into the scope of a Security
   Considerations sections, because they already exist and are not
   introduced by the document at hand:  (i) consequences of
   misconfiguration; (ii) security considerations for MIBs in
   general, such as SET operations in insecure environments, or GET
   operations on confidential data; (iii) security issues in SNMP
   versions older than version 3.  Notwithstanding this, all of these
   vulnerabilities are certainly important for network administrators
   to be aware of.  I therefore suggest adding a paragraph at the
   beginning of the Security Considerations section that explains
   that the document itself does not introduce new vulnerabilities,
   but that the following vulnerabilities of related mechanisms
   should be considered.

- Some nits:

   Abstract:  Packet Switch Network -> Packet Switched Network

   Introduction:  Acronym "PSN" is defined twice.

   Introduction:  Acronym "VT" is not defined.
Permalink | Reply | 0 comments |
headers
Bruce Davie | 4 Aug 2008 17:52
Picon
Favicon

Re: PWE congestion draft


On Aug 3, 2008, at 9:35 AM, Yaakov Stein wrote:

Stewart / Bruce
 
In order to progress this draft, I would like to break down my comments
into small pieces and see if we can resolve them one at a time.
 
Before raising teleological questions, I would like to get an answer to an ontological one.

Yaakov,
 In our quest to make sure we're on the same page, let me start by trying to decipher the above sentence. (What good is a PhD if you can't tell your teleology from your ontology?) I assume you mean you want to be sure you understand our meaning before arguing with us about our intentions?

I think your email actually indicates that you misunderstand the intent of our draft. It is meant to be a *framework* draft (hence the title) and as such it is not trying to say what mechanism should be deployed. I think you are having trouble understanding what we mean because you assume that we have a mechanism in mind when we describe only a high level policy. In fact we are really trying NOT to propose a mechanism here. (Separating policy from mechanism is, I'm sure you know, an age-old principle in computer science.) To the extent that the current draft talks about mechanisms, we're mostly trying to illustrate that all mechanisms that we know of have shortcomings, and hence this is a hard problem space to solve correctly.

 
In the draft you state
  In these environments the operator needs to make a judgement call on
  a fair estimate of the number of equivalent flows that the PW
  represents.
and
   In the PW environment some estimate (measured or configured) of the
   number flows in the PW needs to be applied to the estimate of fair
   throughput as part of the process of determining appropriate
   congestion behavior.
When I first read these sentences, I was relatively sure that I knew what they meant,
but afterwards I realized that there are several possibilities.
Upon discussing the matter with Stewart,
I discovered that perhaps I did not guess correctly which of these possibilities was intended.
 

In fact none of your guesses is correct, because, as I've said, we're not trying to propose a mechanism. We're trying to describe a high-level objective for PW congestion. If the Wg ever gets to the point of designing a mechanism or set of mechanisms, then they will need to meet this high level objective.

So, the short answer to your question is "none of the above".

Let me try to put this another way that may be easier to understand.

Assume there is a PW running over a network that is congested enough to occasionally experience loss, and that the loss occasionally affects packets of the PW. (I think you have argued in some prior emails that such networks should not exist, but I'll ask you to suspend disbelief for a moment). The main objective of this PW congestion work is to ensure that such loss is not ignored, that is, the PW does not just keep on sending packets into the network at the same rate or, even worse, send more packets.

Now there is a well-known equation for the long term throughput of a TCP flow for a given loss rate, RTT, and MSS (packet size). (See RFC 3448 for a quick summary.)  Call this the "single flow TCP fair rate". If a PW were carrying a single flow, and experiencing a certain loss rate, and its long term average throughput where much higher than the the single flow TCP fair rate, we could argue that it is not responding correctly to the fact that packets are getting lost. However, if the PW happened to be carrying 100 flows, then of course we would expect that the long term average throughput of the PW should be 100 times the single flow TCP fair rate. 

So what we are trying to say here is this:
 - A PW should not keep sending traffic at an arbitrary rate in the presence of loss
 - To understand if a PW is sending more traffic than is reasonable in the presence of loss, we want to see if it is sending a lot more than would be sent if the PW traffic were actually TCP, or TCP-friendly as per the definition in RFC 3448
 - to calculate what it means to be TCP-friendly for a PW, you need some estimate of the number of flows, which, in the para you quoted, we suggested might be something that the operator configures.

Note that if you get the number of flows wrong, you will cause the PW to either send more traffic or less traffic than is strictly "fair" during congestion. But at least the PW won't be completely unresponsive to congestion in either case.  And of course in the absence of congestion (the regime that you and many others consider the norm) the TCP fair rate is infinitely high, so there will be nothing to do to ensure that the PW does not exceed the TCP fair rate.

Now I have some mechanisms in mind for how I would build this stuff. But that is not the job of the framework to describe those mechanisms. I will say however that anything involving help from the interior nodes is a non-starter, because we are very much trying to avoid congestion collapse on existing IP networks. So we can rule out option 3 as a feasible mechanism. But like I said, the above paragraph is about policy, not mechanism.

Bruce


I can think of at least three possibilities as to the meaning of these sentences:.
 
1) When a packet is lost, the egress PE notifies the ingress PE (similar to TCP),
but rather than the ingress decreasing the (maximum) sending rate to 1/2,
the rate is decreased by 1 / 2N. For example, if N=10, instead of reducing by 50 %,
we reduce by 5%.
(We won't discuss the mechanism for enforcing this rate reduction yet,
as this will be the subject of another email.)
As discussed in previous emails (and in the slides that I didn't get to present in Dublin)
this is what would happen automatically is the PW carries TCP/IP flows with
one TCP/IP packet per PW packet.
This is how I initially understood the draft.
Note that thuis mechanism does not require change to intermediate nodes,
but necessitates a new mechanism for feedback from egress PE to ingress PE.
 
2) When a packet is lost, the ingress is notified, but no rate decrease is enforced.
Only after N packets are lost (within some time span) is the rate decreased to 1/2.
This has the advantage of forestalling the policing of the PW,
but the disadvantage of a rather sudden drop in capacity later on.
From a chat with Stewart, I believe this is what he had in mind.
 
3) When intermediate nodes become congested and need to drop a packet,
they drop a packet belonging to the PW with probability 1/N of that of an individual TCP/IP flow.
Thereafter, the egress informs the ingress, and policing is carried out according to method 1.
 
There are several ways of carrying out the packet dropping :
3a) intermediate nodes maintain state as to PW weightings
3b) ingress PEs encode the value of N in the packet header (no state in intermediate nodes)
3c) ingress PEs indicate drop precedence of every N'th packet (no state in intermediate nodes).
 
I assume that 3a is ruled out due to the memory requirements.
3b requires generating random numbers and performing a comparison per packet
(but only when there is congestion), while 3c is the simplest to implement,
and furthermore leaves the decision on which packets to drop to the ingress PE,
which may be in the best situation to know which packets should be dropped.
 
Can I ask the authors to reply as to which of the proposed possibilities (1, 2, 3a, 3b, 3c)
they intended - or did they intend some option 4 ?
 
Y(J)S
 
 

_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
Permalink | Reply | 502 comments |
headers
Bruce Davie | 5 Aug 2008 21:40
Picon
Favicon

Re: PWE congestion draft


On Aug 4, 2008, at 12:30 PM, Yaakov Stein wrote:

 
> We're trying to describe a high-level objective for PW congestion.
>  Let me try to put this another way that may be easier to understand.

>  Assume there is a PW running over a network that is congested enough to occasionally experience loss,  
>  and that the loss occasionally affects packets of the PW.  
>  (I think you have argued in some prior emails that such networks should not exist, but I'll ask you to suspend disbelief for a moment).  
 
No, I never said that there will not be congestion for PWs.
I just don't think that the most important case is PWs over the public Internet
or PWs in parallel with individual TCP/IP flows.

Well, you're certainly entitled to your opinion, but I think the case of PWs interacting with non-PW traffic is the main area of concern from the Transport area, and the main thing we're trying to do here is meet the requests of the Transport folks to avoid unleashing a non-congestion-controlled form of traffic into the wild. FWIW, most deployments of PWs that I am aware of run on networks that carry lots of TCP-IP traffic that is not inside PWs (e.g. combined L3VPN and L2VPN networks). 

The case of PWs running in networks that only support PWs is definitely NOT the focus of this draft, and I guess we should try to make that point more clearly in the next rev (if there is one.)



< snip>
 
>  Now I have some mechanisms in mind for how I would build this stuff.  
>  But that is not the job of the framework to describe those mechanisms.  
>  I will say however that anything involving help from the interior nodes is a non-starter,  
>  because we are very much trying to avoid congestion collapse on existing IP networks.  
 
Once again, that is understandable for the PW over the general Internet case.
While a valid case in principle, and perhaps one that the IETF as a whole really wants us to address,
I don't believe that it is the most important one for us to solve.

See above. Feel free to go and work on the problem that you think is important, but I don't think this framework needs to tackle it.
Note however that I am not just talking about the "general Internet" but any network where there is a mix of PW and non-PW traffic.

 
> So we can rule out option 3 as a feasible mechanism. But like I said, the above paragraph is about policy, not mechanism.
 
But you see how fast the difference between policy and mechanism becomes blurred ? 

Only because I have graciously decided to comment on your mechanisms.

 
You talk about considering the PW to be equivalent to some number of flows.
I must assume that in addition to yourself, you imagine that some network element is cognizant of this fact,
as otherwise the statement does not lead to the PW being treated operationally as N flows.
That network element takes some action that uses the information (i.e. its knowledge of "N").
I think that which network elements you consider to be relevant and what the kinds of actions you have in mind
are completely relevant to a framework draft - indeed they are part of what you call "high level policy".

We clearly have somewhat different ideas about where the line lies between policy and mechanism. 

However, to satisfy your curiosity about the mechanisms I have in mind, I will say that I think TFRC enforced at the ingress PE by using a shaper (not a dropping policer) is the best combination of mechanisms I have thought of so far. The use of both these mechanisms is discussed in Section 7 of the draft.

Bruce


 

Y(J)S
 

_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
Permalink | Reply | 0 comments |
headers
rfc-editor | 7 Aug 2008 01:27
Favicon

RFC 5287 on Time-Division Multiplexing (TDM) Pseudowires in MPLS NetworksControl Protocol Extensions for the Setup of


A new Request for Comments is now available in online RFC libraries.

        
        RFC 5287

        Title:      Time-Division Multiplexing (TDM) Pseudowires in 
                    MPLS NetworksControl Protocol Extensions for the 
                    Setup of 
        Author:     A. Vainshtein, Y(J). Stein
        Status:     Standards Track
        Date:       August 2008
        Mailbox:    Alexander.Vainshtein <at> ecitele.com, 
                    yaakov_s <at> rad.com
        Pages:      16
        Characters: 33070
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-pwe3-tdm-control-protocol-extensi-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5287.txt

This document defines extension to the Pseudowire Emulation
Edge-to-Edge (PWE3) control protocol RFC 4447 and PWE3 IANA
allocations RFC 4446 required for the setup of Time-Division
Multiplexing (TDM) pseudowires in MPLS networks.  [STANDARDS TRACK]

This document is a product of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor <at> rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute
Permalink | Reply | 6 comments |
headers
Suresh Babu Gajapathy | 7 Aug 2008 05:55
Favicon

Query regarding Multisegment PW

Hi everyone.
 
I have few queries on Multi Segmented Pseudowire.
 
 
1. How to identify that the entire MS-PW is up.
    The draft says that "A MS-PW is declared UP when all the constituent SS-PWs are UP." in page no -9.
    since 2 independant SS-PW's are created as the Figure (3) in the draft, how does T-PE-1 comes to know that the complete MS-PW is up.
    Does S-PE send some indication on this, or should we explicitly indentify using VCCV Ping.
 
thanks
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."
_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
Permalink | Reply | 2 comments |
headers
Suresh Babu Gajapathy | 7 Aug 2008 05:55
Favicon

Re: pwe3 Digest, Vol 51, Issue 36

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: pwe3-bounces <at> ietf.org [pwe3-bounces <at> ietf.org] On Behalf Of pwe3-request <at> ietf.org [pwe3-request <at> ietf.org]
Sent: Tuesday, July 22, 2008 2:46 PM
To: pwe3 <at> ietf.org
Subject: pwe3 Digest, Vol 51, Issue 36

Send pwe3 mailing list submissions to
        pwe3 <at> ietf.org

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
        pwe3-request <at> ietf.org

You can reach the person managing the list at
        pwe3-owner <at> ietf.org

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
      (neil.2.harrison <at> bt.com)

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

Message: 1
Date: Mon, 21 Jul 2008 14:29:14 -0500
From: "AISSAOUI Mustapha" <Mustapha.Aissaoui <at> alcatel-lucent.com>
Subject: Re: [PWE3] PWE3 Redundancy
To: "Suresh Babu Gajapathy" <Sureshbabu.Gajapathy <at> aricent.com>,
        <pwe3 <at> ietf.org>
Message-ID:
        <4A5028372622294A99B8FFF6BD06EB7B0470532A <at> USDALSMBS03.ad3.ad.alcatel.com>

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: pwe3-bounces <at> ietf.org [mailto:pwe3-bounces <at> ietf.org] On
Behalf Of Suresh Babu Gajapathy
        Sent: Thursday, July 17, 2008 7:49 AM
        To: pwe3 <at> ietf.org
        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: <neil.2.harrison <at> bt.com>
Subject: Re: [PWE3] Tandem Connection Monitoring in the new PWE3
        Chapter
To: <Italo.Busi <at> alcatel-lucent.it>,     <Alexander.Vainshtein <at> ecitele.com>
Cc: Jeremy.Brayley <at> ecitele.com, pwe3 <at> ietf.org,
        Alik.Shimelmits <at> ecitele.com,    danny <at> tcb.net, stbryant <at> cisco.com
Message-ID:
        <2ECAA42C79676B42AEBAC11229CA7D0C02D73789 <at> E03MVB2-UKBR.domain1.systemhost.net>

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: neil.2.harrison <at> bt.com [mailto:neil.2.harrison <at> bt.com]
> > Sent: Thursday, July 17, 2008 3:15 PM
> > To: Alexander.Vainshtein <at> ecitele.com; Italo.Busi <at> alcatel-lucent.it
> > Cc: pwe3 <at> ietf.org; Jeremy.Brayley <at> ecitele.com; danny <at> tcb.net;
> > Alik.Shimelmits <at> ecitele.com; stbryant <at> cisco.com
> > 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:Alexander.Vainshtein <at> ecitele.com]
> > > Sent: 17 July 2008 09:00
> > > To: Italo Busi
> > > Cc: Harrison,N,Neil,CXM R; pwe3 <at> ietf.org; Jeremy Brayley; 'Danny
> > > McPherson'; Alik Shimelmits; stbryant <at> cisco.com
> > > 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:Italo.Busi <at> alcatel-lucent.it]
> > > > Sent: Wednesday, July 16, 2008 3:56 PM
> > > > To: Alexander Vainshtein; stbryant <at> cisco.com
> > > > Cc: neil.2.harrison <at> bt.com; pwe3 <at> ietf.org; 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: pwe3-bounces <at> ietf.org
> > > [mailto:pwe3-bounces <at> ietf.org] On Behalf
> > > > > Of Alexander Vainshtein
> > > > > Sent: Thursday, July 10, 2008 1:30 PM
> > > > > To: stbryant <at> cisco.com
> > > > > Cc: neil.2.harrison <at> bt.com; pwe3 <at> ietf.org; Jeremy
> > Brayley; Danny
> > > > > McPherson; Alik Shimelmits
> > > > > Subject: Re: [PWE3] Tandem Connection Monitoring in the new
> > > > > PWE3 Chapter
> > > > >
> > > > > Stewart,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Stewart Bryant [mailto:stbryant <at> cisco.com]
> > > > > > Sent: Thursday, July 10, 2008 1:51 PM
> > > > > > To: Alexander Vainshtein
> > > > > > Cc: Danny McPherson; pwe3 <at> ietf.org;
> > > neil.2.harrison <at> bt.com; 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
> > > > > pwe3 <at> ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/pwe3
> > > > >
> > > >
> > > >
> > >
> >
>
>

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

_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
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."
Permalink | Reply | 0 comments |
headers
manikandan ramanathan | 7 Aug 2008 11:48
Picon
Favicon

draft-ietf-pwe3-oam-msg-map-06 related MIB

Hi ,
 
Pls let me know whether do we have any drafts for MIBs related to draft-ietf-pwe3-oam-msg-map-06.
 
Pls let me know at the earliest.
 
Regards,
Manikandan RM

Did you know? You can CHAT without downloading messenger. Click here 
_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
Permalink | Reply | 0 comments |

Gmane