From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Ali Sajassi <sajassi@cisco.com>
Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention
Date: Mon, 01 Dec 2003 00:12:38 -0800
Lines: 101
Sender: pwe3-admin@ietf.org
References: <0536FC9B908BEC4597EE721BE6A3538904EF2ECC@i2km07-ukbr.domai
 n1.systemhost.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: <Maarten.Vissers@alcatel.de>
X-From: pwe3-admin@ietf.org Mon Dec 01 09:22:12 2003
Return-path: <pwe3-admin@ietf.org>
X-Sender: sajassi@airborne.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: <neil.2.harrison@bt.com>, <sajassi@cisco.com>, <stds-802-1@ieee.org>,
        <pwe3@ietf.org>
In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2ECC@i2km07-ukbr.domai
 n1.systemhost.net>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Neil,

Please refer to the comments in line ...

At 08:53 PM 11/26/2003 +0000, neil.2.harrison@bt.com wrote:
>Hi Ali,
>
>Ali Sajassi wrote 26 November 2003 20:10
><snip>
> >
> > >-       the lesson that I take away from the above
> > observations is that
> > >architecturally it makes more sense to have 2 different
> > CRCs, (i) one
> > >protecting only the CI that goes between trail term points
> > transparently
> > >(ie never changes on link-connections) and (ii) one
> > protecting only the
> > >link-connection specific part of the client traffic unit
> > that can change
> > >on link-connections (so this needs a linear update per link
> > connection).
> >
> > So in the context of our discussions, given that the PEs are
> > intended to
> > provide transport functionality with respect to Ethernet
> > services and not
> > interworking, then it means any FCS to be added for the CI
> > portion is the
> > job of the CE and not the PE - this is analogous to ATM and
> > FR transport
> > where you don't expect the ATM switch or FR switch to add a
> > CRC for the
> > payload.
>NH=> I tend to think in terms of G.805 func arch and not boxes, ie it is 
>the func arch (eg where layer networks start and end) that is most 
>important, not a 'CE' or 'PE' badge.  I look at this stuff very 
>simply:  The FCS of eth belongs to the traffic unit of the eth layer 
>network....not any other layer network.

Based on your previous suggestion, there should be two FCS - one for the CI 
data and the other for link layer. Well, bridges take care of the FCS for 
the link layer and that makes sense since VLANs can be manipulated by the 
bridges (add/deleted) and they can serve as service delimiter. So any FCS 
that needs to be added for CI portion should be done by the client-layer 
application similar to 1483/1490 encap.

>   Where the eth client gets encapsulated (let's say in MPLS) is where the 
> LSP trail starts (this can be any box)....and there is an LSP trail term 
> point where they get decapsulated. (Yes I know folks also add a PW header 
> but this is not a layer network, simply an adaptation function).  This is 
> simply client/server encapulation and well defined in G.805.  If we carry 
> the eth clinet over any server layer, you mentioned ATM or FR (but I 
> could also add PDH, SDH, etc), then exactly the same applies.

No PDH and SDH are different. These are port-based Ethernet service; 
whereas, I was talking about vlan-based services (e.g., each VLAN is a VC) 
and making analogy between VLAN-id in Ethernet and DLCI in FR or VPI/VCI in 
ATM.

>NH=> This, I think, is the key issue of contention Ali (and why various 
>people see the situation differently).  If we take the LLC/MAC split then 
>you have a valid point.  It's also pretty similar (if you think about it) 
>to the ATM_cell/AAL_X split.  However, I would tend to look at the LLC/MAC 
>as 'joined at the hip' sub-layers, ie they must go together...and I don't 
>know of any std which allows the LLC part to sent on anything without its 
>MAC part (but please correct me if you know otherwise).

LLC is basically used for management and control traffic (e.g., xSTP, GxRP, 
LLDP, etc.) and NOT for data traffic. The data traffic that gets switched 
in a bridge doesn't go through LLC sub-layer. Given that the customer data 
only gets switched through the bridge and doesn't get terminated by the 
bridge, hence my point of a bridge only being responsible at the MAC layer 
for the customer data.

>  There is not the same binding IMO between the ATM_cell and the 
> AAL_X.....I can easily imagine AAL_X being carried over some other server 
> layer network....and in fact Yaakov S has considered this for AAL1 (TDM) 
> over MPLS for example.

All I am trying to point out is that there is a difference between FCS for 
CI and FCS for the link layer. In case of FR, you can have these two FCSs 
and the FCS for the CI portion is responsibility of the application that 
does the encapsulation and not the FR switch that does the switching.


>The fact folks are now proposing to send the eth frames over WAN 
>technologies is a problem of our making, not the orgins of eth with how it 
>viewed what would be the MAC layer.....so these aspects were never clearly 
>diveroced or considered before AFAIK.  And which is why on balance, I 
>still err of the side of caution with the view that the FCS should be 
>carried as the default behaviour.

Which FCS :-)

Regards,
Ali


>regards, Neil
><snipped to end>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention
Date: Mon, 01 Dec 2003 09:52:07 +0000
Organization: Cisco Systems, Inc.
Lines: 110
Sender: pwe3-admin@ietf.org
References: <0536FC9B908BEC4597EE721BE6A3538904EF2E8C@i2km07-ukbr.domain1.systemhost.net> <3FC14FF9.5070709@cisco.com> <3FC20CED.8080100@yahoo.com>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: neil.2.harrison@bt.com, kgk@igs.net, jmessenger@advaoptical.com,
        nfinn@cisco.com, mark@interflect.com, stds-802-1@ieee.org,
        pwe3@ietf.org, Maarten.Vissers@alcatel.de, alan.mcguire@bt.com
X-From: pwe3-admin@ietf.org Mon Dec 01 10:53:12 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: m_seery@yahoo.com
In-Reply-To: <3FC20CED.8080100@yahoo.com>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



mark seery wrote:
> Stewart Bryant wrote:
> 
>>
>>>> If you assume a PW to be a sort of bridge,
>>>
>>>
>>>
>>> NH=> A PW is for sure not a bridge!  A PW is an adaptation funtion 
>>> that lies between a client layer network and a server layer network 
>>> of MPLS or IP.  
>>
>>
>>
>> Neil
>>
>> Surely that is just one way to model the PW? Can't a PW also be
>> modelled as a repeater with certain internal delay and error
>> characteristics.
>>
>> Stewart
>>
>> _____________________________________________
>> pwe3 mailing list
>> pwe3@ietf.org
>> https://www1.ietf.org/mailman/listinfo/pwe3
> 
> 
> Stewart,
> 
> I have worked on equipment that transported Ethernet over a tunnel, 
> without doing bridging, and the Ethernet testers have commented to me 
> "this is a repeater". So I think the analogy you make is intuitive for 
> Ethernet people. It is not technically correct because of the formal 
> definition of repeaters (IMO), but in spirit it is. 

Remember PWE3 never set out to provide perfect emulation. Our charter
was to provide adequate emulation, and describe in an applicability
statement the issues associated with the approximation.

> The more difficult 
> issue is that repeaters have 802 on ingress and egress, so if we are to 
> extend this analogy, then a PW is an internal connection within the 
> "virtual repeater" that is not part of a formal 802 model, other than it 
> should not introduce errors greater than some prescription.

The PW does have the same interface on both ends (even if the wire
ends in a virtual interface).

> 
> All Neil is suggesting is that the internal connection is "transporting" 
> the ethernet layer, and he is further arguing for a principle of layer 
> encapsulation (similar to object encapsulation in software) which is 
> very similar in spirit to the principle of minimum intervention sited in 
> the PW architecture document (3.3.5). All that is left is to argue about 
> whether the FCS belongs to the layer being transported.
> 

The original reason that FCS was stripped off was because PW was conceived
as a method of carrying minority traffic over the Internet, and many
equipments earmarked to provide this service (from a number of vendors)
were thought to be incapable of re-configuration to carry FCS. Now you
can question whether newer higher volume demands have emerged since PWE3
started, and the response from the WG has been that we should baseline
what we have and then consider the new requirements.

> I would assume a real 802 repeater would not strip the FCS, so if we 
> were to take the analogy to the extreme, we would not strip the FCS here 
> either, but of course as this is not a real repeater function, so we are 
> left with balancing the models and requirements of at multiple views: 
> IEEE, IP, IP-MPLS, ITU, carrier operations/engineering.
> 

Indeed, and after several years of design, discussion between the
vendors and the SPs, and early deployment experience, all that has
emerged in the way of practical problems is one single bridge
failing in a lab environment. I do not know the specifics of the
problem but I would suspect that if that failure had happened
in a production environment, the IGP would have recovered the
situation and the NMS would have pointed the finger.

So now lets turn back to the matter in hand.

1) Under what circumstances is the approximation inadequate (Please
    can we have this answer in the form of text for our applicability
    statements).

2) What is the best engineering solution to those shortcomings, and
    why?


> In a later email you say:
> 
> "For the PW to be an adaptation function, one would have to assert hat 
> the contents of the PW had some meaning within the PSN.  I don't beleive 
> it has, because we never communicate any context information to any 
> object in the PSN (either by signalling or  self description) which it 
> can use to interpret the contents of the PW."
> 
> If we were to assert that the contents of the PW had some meaning within 
> the PSN, I would suggest that would be an interworking function, not an 
> adaptation function.
> 

You are correct, it is an adaptation, not an interworking, but remember
we only ever set out to approximate the adaptation.

Stewart


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention
Date: Mon, 01 Dec 2003 09:56:38 +0000
Organization: Cisco Systems, Inc.
Lines: 19
Sender: pwe3-admin@ietf.org
References: <AF5018AC03D1D411ABB70002A5091326D3191F@TLV1>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stds-802-1@ieee.org, pwe3@ietf.org, mick_seaman@ieee.org
X-From: pwe3-admin@ietf.org Mon Dec 01 10:58:04 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: Sasha Vainshtein <Sasha@AXERRA.com>
In-Reply-To: <AF5018AC03D1D411ABB70002A5091326D3191F@TLV1>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Sasha

>>Perhaps the best way for a customer to validate the PW is
>>with an OAM protocol that runs between the CEs, rather than
>>trying to discover the problem implicitly through the FCS?
>>
> 
> [Sasha] I am not sure this is the correct approach since it would mean
> that the customer is aware of the fact that connection between CE devices
> passes through a PW and has to modify CEs accordingly.  
> 

The customer is of course aware of the connection, because they
are buying a CE to CE link. One of the purposes of an OAM is to
audit and diagnose a link, and that is what it would be doing.
The difference is that with an OAM they would be diagnosing the
problem explicitly, and not implicitly.

Stewart


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: FCS retention in PWE3
Date: Mon, 01 Dec 2003 10:31:02 +0000
Organization: Cisco Systems, Inc.
Lines: 60
Sender: pwe3-admin@ietf.org
References: <0536FC9B908BEC4597EE721BE6A3538904EF2EA5@i2km07-ukbr.domain1.systemhost.net>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Dec 01 11:32:03 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: neil.2.harrison@bt.com
In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2EA5@i2km07-ukbr.domain1.systemhost.net>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



neil.2.harrison@bt.com wrote:

> Stwart,
> 
> In general I agree with you.  But what you are actually saying 
> here is that we want independent OAM in each layer network (simply
> has to be independent....one reason being that we want the *same*
> OAM solution in the server irrespective of its client).  

Independent yes. Same depends on whether there are any differences
in the requirement that suggest otherwise, but I agree same would
be a good thing.

> But please note this:
> -	a PW is not a layer network, ie we do not network/switch PW entities;

I am not sure about this. Logically what we are doing is to recurse
back to a lower layer, over which we could run for example a new IGP.
In as much as we network/switch wires, we network/switch PWs.

> -	an LSP is a layer network, ie we do network/switch LSP entities;
> -	why can't we use Y.1711 OAM on the top level p2p LSP?

VCCV is the only method that has been formally accepted bt the PWE3
WG for further study. If you think that Y.1711 is more appropriate,
please write a draft explaining how this works in the PWE3 context and
why it is better. The WG will then decide the way forward through
our normal process.

> -	Y.1711 is sparse/simple/complete, ie all defects are defined 
         with entry-exit criteria and consequent actions.....it even
         defines availability and does so in order it can be used a
         single-ended way, ie behaviour of both directions can be
         observed from 1 end.

> -	MPLS and ATM OAM layer I/W is already defined in Y.1712.....
         and again its really simple.

         I thought that we were talking about Ethernet here?
> 
> None of this is done (and in some cases is not appropriate) for 
> the VCCV approach.    

I which case the VCCV team need to either provide these or explain
why they are not needed.

> 
> So what is wrong with this solution?

There is no WG draft describing the applicability of Y.1711 to PWE3.
If you want that solution, then you have to run the normal IETF
process to get it adopted, which will involve writing a draft,
getting it accepted by the WG, and going through a point by point
analysis of the advantages and disadvantages of Y.1711 and VCCV.

Regards

Stewart


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: neil.2.harrison@bt.com
Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention
Date: Mon, 1 Dec 2003 11:59:23 -0000
Lines: 36
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: <Maarten.Vissers@alcatel.de>
X-From: pwe3-admin@ietf.org Mon Dec 01 13:00:08 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
Thread-Topic: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
Thread-Index: AcO34ujitPMC0J43SyWbYpjoD3hu8wAHfQPw
To: <sajassi@cisco.com>, <stds-802-1@ieee.org>, <pwe3@ietf.org>
X-OriginalArrivalTime: 01 Dec 2003 11:59:23.0770 (UTC) FILETIME=[8FC05DA0:01C3B802]
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Hi Ali.....just a small remark.  regards, Neil

Ali Sajassi wrote 01 December 2003 08:13
<snipped>
> >   Where the eth client gets encapsulated (let's say in=20
> MPLS) is where the=20
> > LSP trail starts (this can be any box)....and there is an=20
> LSP trail term=20
> > point where they get decapsulated. (Yes I know folks also=20
> add a PW header=20
> > but this is not a layer network, simply an adaptation=20
> function).  This is=20
> > simply client/server encapulation and well defined in=20
> G.805.  If we carry=20
> > the eth clinet over any server layer, you mentioned ATM or=20
> FR (but I=20
> > could also add PDH, SDH, etc), then exactly the same applies.
>=20
> No PDH and SDH are different. These are port-based Ethernet service;=20
> whereas, I was talking about vlan-based services (e.g., each=20
> VLAN is a VC)=20
> and making analogy between VLAN-id in Ethernet and DLCI in FR=20
> or VPI/VCI in=20
> ATM.
NH=3D> I don't think this analogy is valid.  A VPI/VCI (ATM), DLCI (FR) =
or a 'label' (MPLS) are all examples of link-connection identifiers.  =
These entities have no network currency until/unless they are associated =
with some parent trail entity (no matter how that is created).  A VLAN =
ID is not a link-connection identifier.  It is more like a 'name', in =
that it subdivides the total MAC address population into contained =
sub-spaces of MAC addresses (that belong to a given VLAN).  I suppose it =
could be used in other ways, but that is my understanding of its native =
architectural significance.

regards, Neil
<snipped


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention
Date: Mon, 01 Dec 2003 13:37:18 +0000
Organization: Cisco Systems, Inc.
Lines: 58
Sender: pwe3-admin@ietf.org
References: <0536FC9B908BEC4597EE721BE6A3538904EF2EF2@i2km07-ukbr.domain1.systemhost.net>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: sajassi@cisco.com, stds-802-1@ieee.org, pwe3@ietf.org,
        Maarten.Vissers@alcatel.de
X-From: pwe3-admin@ietf.org Mon Dec 01 14:38:07 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: neil.2.harrison@bt.com
In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2EF2@i2km07-ukbr.domain1.systemhost.net>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



neil.2.harrison@bt.com wrote:
> Hi Ali.....just a small remark.  regards, Neil
> 
> Ali Sajassi wrote 01 December 2003 08:13
> <snipped>
> 
>>>  Where the eth client gets encapsulated (let's say in 
>>
>>MPLS) is where the 
>>
>>>LSP trail starts (this can be any box)....and there is an 
>>
>>LSP trail term 
>>
>>>point where they get decapsulated. (Yes I know folks also 
>>
>>add a PW header 
>>
>>>but this is not a layer network, simply an adaptation 
>>
>>function).  This is 
>>
>>>simply client/server encapulation and well defined in 
>>
>>G.805.  If we carry 
>>
>>>the eth clinet over any server layer, you mentioned ATM or 
>>
>>FR (but I 
>>
>>>could also add PDH, SDH, etc), then exactly the same applies.
>>
>>No PDH and SDH are different. These are port-based Ethernet service; 
>>whereas, I was talking about vlan-based services (e.g., each 
>>VLAN is a VC) 
>>and making analogy between VLAN-id in Ethernet and DLCI in FR 
>>or VPI/VCI in 
>>ATM.
> 
> NH=> I don't think this analogy is valid.  A VPI/VCI (ATM), 
> DLCI (FR) or a 'label' (MPLS) are all examples of link-connection 
> identifiers.  These entities have no network currency until/unless 
> they are associated with some parent trail entity (no matter 
> how that is created).  

Here you are talking about the inner label. The outer label
would normally be an abbreviation for an IP address.

> A VLAN ID is not a link-connection 
> identifier.  It is more like a 'name', in that it 
> subdivides the total MAC address population into contained 
> sub-spaces of MAC addresses (that belong to a given VLAN).  

Isn't it a virtual network identifier.

Stewart


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: neil.2.harrison@bt.com
Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention
Date: Mon, 1 Dec 2003 15:08:55 -0000
Lines: 65
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: <sajassi@cisco.com>, <stds-802-1@ieee.org>, <pwe3@ietf.org>,
        <Maarten.Vissers@alcatel.de>
X-From: pwe3-admin@ietf.org Mon Dec 01 16:10:12 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
Thread-Topic: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
Thread-Index: AcO4EERn5ZZ8ID77Rhq6LZEfPpDYEAACDp7Q
To: <stbryant@cisco.com>
X-OriginalArrivalTime: 01 Dec 2003 15:08:56.0180 (UTC) FILETIME=[0A3C6B40:01C3B81D]
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Stewart,

Stewart wrote 01 December 2003 13:37
<snipped>
> >>No PDH and SDH are different. These are port-based Ethernet=20
> service;=20
> >>whereas, I was talking about vlan-based services (e.g., each=20
> >>VLAN is a VC)=20
> >>and making analogy between VLAN-id in Ethernet and DLCI in FR=20
> >>or VPI/VCI in=20
> >>ATM.
> >=20
> > NH=3D> I don't think this analogy is valid.  A VPI/VCI (ATM),=20
> > DLCI (FR) or a 'label' (MPLS) are all examples of link-connection=20
> > identifiers.  These entities have no network currency until/unless=20
> > they are associated with some parent trail entity (no matter=20
> > how that is created). =20
>=20
> Here you are talking about the inner label. The outer label
> would normally be an abbreviation for an IP address.
NH=3D> I think we need a better explantion as to what is actually going =
on here.  All co-ps/cs technologies work in essentially the same way.  =
If we take the largest subnetwork (G.805 sense) then the network access =
points are where it's addresses are located.  These are also =
intrinsically bound to trail termination functions.  The =
link-connections in co-ps/cs networks use labels that only have local =
(link) signficance.  When a trail is established between the network =
addressed access points than a series of concatenated link-connections =
and subnetworks (the smallest subnetwork being a node/switch in the =
technology of relevance) is created.....the link-connection IDs have no =
network currency before this, ie they sit in a pool waiting to be =
allocated (and are reuturned to the pool when the trail is torn-down).  =
So in all co-ps/cs technologies then 'yes' one could say a label points =
to some distant access point address.....and since the labels are a =
series of related/concatenated links then this pointing to a distant =
destination address carries all the way to the access point at the trail =
source.

This is also why mp2p is a deprecated topology in the co-ps/cs =
modes.....though in the co-cs mode you simply can't physically create =
this violation, but you can force it in the co-ps mode.  Merging means =
we have lost transparency and integrity of the CI, ie we no longer =
uniquely know the source.  Which is why we are forced to run an extra =
p2p LSP above the mp2p construct to recover from the arch violation of =
this mode.  So the fact that the semantics of the label (ie inner vs =
outer) is now altered is simply a consequence of this arch violation.  =
Also note that IP belongs to the cnls mode and never has this =
problem....that is, the cnls mode always muxes and never =
merges....why?...because each traffic unit carries the full network =
DA/SA pair.....and that is indeed the signature of the cnls mode.
>=20
> > A VLAN ID is not a link-connection=20
> > identifier.  It is more like a 'name', in that it=20
> > subdivides the total MAC address population into contained=20
> > sub-spaces of MAC addresses (that belong to a given VLAN). =20
>=20
> Isn't it a virtual network identifier.
NH=3D> Yes, that was my point above saying it is a more like a =
'name'....its not a link-connection ID in the same sense as VPI/VCI, =
DLCIs and MPLS labels are.

Stewart....I think we are wandering off topic now....so if this is to =
continue I suggest we change the title.

regards, Neil


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: mark seery <mark@interflect.com>
Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention
Date: Mon, 01 Dec 2003 08:38:23 -0800
Lines: 149
Sender: pwe3-admin@ietf.org
References: <0536FC9B908BEC4597EE721BE6A3538904EF2E8C@i2km07-ukbr.domain1.systemhost.net> <3FC14FF9.5070709@cisco.com> <3FC20CED.8080100@yahoo.com> <3FCB0F47.10107@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: neil.2.harrison@bt.com, kgk@igs.net, jmessenger@advaoptical.com,
        nfinn@cisco.com, stds-802-1@ieee.org, pwe3@ietf.org,
        Maarten.Vissers@alcatel.de, alan.mcguire@bt.com
X-From: pwe3-admin@ietf.org Mon Dec 01 17:59:07 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
To: stbryant@cisco.com
In-Reply-To: <3FCB0F47.10107@cisco.com>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Stewart,

Thanks for the constructive and informative response.

Some comments inline.

mark


Stewart Bryant wrote:

>
>
> mark seery wrote:
>
>> Stewart Bryant wrote:
>>
>>>
>>>>> If you assume a PW to be a sort of bridge,
>>>>
>>>>
>>>>
>>>>
>>>> NH=> A PW is for sure not a bridge!  A PW is an adaptation funtion 
>>>> that lies between a client layer network and a server layer network 
>>>> of MPLS or IP.  
>>>
>>>
>>>
>>>
>>> Neil
>>>
>>> Surely that is just one way to model the PW? Can't a PW also be
>>> modelled as a repeater with certain internal delay and error
>>> characteristics.
>>>
>>> Stewart
>>>
>>> _____________________________________________
>>> pwe3 mailing list
>>> pwe3@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/pwe3
>>
>>
>>
>> Stewart,
>>
>> I have worked on equipment that transported Ethernet over a tunnel, 
>> without doing bridging, and the Ethernet testers have commented to me 
>> "this is a repeater". So I think the analogy you make is intuitive 
>> for Ethernet people. It is not technically correct because of the 
>> formal definition of repeaters (IMO), but in spirit it is. 
>
>
> Remember PWE3 never set out to provide perfect emulation. Our charter
> was to provide adequate emulation, and describe in an applicability
> statement the issues associated with the approximation. 

mark==> I have no problem with this in principle - I believe a market 
place works best when there are clear alternatives; and certainly 
respect the right of the IETF community to inform its working groups. 
The only problem in practice is that if some constituency sees a 
deficiency there is no effective means to address it because of the 
sensitivity about who owns what standard (in this case PWE/MPLS/IP), 
which is not insummountable obviously. This is where 
optional/informational RFCs can help if we recognise the different needs 
and address them (which at least for the end-to-end integrity issue we 
are, Malis et etl.).

In addition, we are obviously engaged in the rather complex issue of 
wanting to see an end to end solution of which we only have partial 
responsibility (the PW portion of the end-to-end Ethernet service). This 
complexity just adds to the consensus issue from a wider community. We 
are naturally pulled in to the end-to-end issue because the same people 
in the IETF that support a PW facility for Ethernet have a vested 
interest in seeing and end-to-end solution that is acceptable to a wider 
community.

>> The more difficult issue is that repeaters have 802 on ingress and 
>> egress, so if we are to extend this analogy, then a PW is an internal 
>> connection within the "virtual repeater" that is not part of a formal 
>> 802 model, other than it should not introduce errors greater than 
>> some prescription.
>
>
> The PW does have the same interface on both ends (even if the wire
> ends in a virtual interface).
>
>>
>> All Neil is suggesting is that the internal connection is 
>> "transporting" the ethernet layer, and he is further arguing for a 
>> principle of layer encapsulation (similar to object encapsulation in 
>> software) which is very similar in spirit to the principle of minimum 
>> intervention sited in the PW architecture document (3.3.5). All that 
>> is left is to argue about whether the FCS belongs to the layer being 
>> transported.
>>
>
> The original reason that FCS was stripped off was because PW was 
> conceived
> as a method of carrying minority traffic over the Internet, and many
> equipments earmarked to provide this service (from a number of vendors)
> were thought to be incapable of re-configuration to carry FCS. Now you
> can question whether newer higher volume demands have emerged since PWE3
> started, and the response from the WG has been that we should baseline
> what we have and then consider the new requirements.
>
>> I would assume a real 802 repeater would not strip the FCS, so if we 
>> were to take the analogy to the extreme, we would not strip the FCS 
>> here either, but of course as this is not a real repeater function, 
>> so we are left with balancing the models and requirements of at 
>> multiple views: IEEE, IP, IP-MPLS, ITU, carrier operations/engineering.
>>
>
> Indeed, and after several years of design, discussion between the
> vendors and the SPs, and early deployment experience, all that has
> emerged in the way of practical problems is one single bridge
> failing in a lab environment. I do not know the specifics of the
> problem but I would suspect that if that failure had happened
> in a production environment, the IGP would have recovered the
> situation and the NMS would have pointed the finger. 

mark ==> It is not clear to me this particular problem would necessarily 
have caused the IGP to make a change, unless the error was impacting 
control plane PDUs, which it may not have been if it was located on the 
service facing line cards. Of course I know less about the reported 
incident than you ;-). I accept your testimony that there have been few 
problems in practice. The issue I believe is the sensitivity to 
supporting services on a large scale (which you state below was not an 
anticipation of the WG - worth noting), and the approach that some 
constituencies take to fault detection & diagnosis; remembering that due 
to historical issues, the Internet community by design focused on 
Internet layer management techniques while other memebers of the 
industry did not.

>
>
> So now lets turn back to the matter in hand.
>
> 1) Under what circumstances is the approximation inadequate (Please
>    can we have this answer in the form of text for our applicability
>    statements).
>
> 2) What is the best engineering solution to those shortcomings, and
>    why? 

mark==> I have no complaints about the FCS retention draft from Malis et el.

<snipped to the end>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: mark seery <mark@interflect.com>
Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention
Date: Mon, 01 Dec 2003 12:38:55 -0500 (EST)
Lines: 36
Sender: pwe3-admin@ietf.org
References: <0536FC9B908BEC4597EE721BE6A3538904EF2EF2@i2km07-ukbr.domain1.systemhost.net>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: <Maarten.Vissers@alcatel.de>, <sajassi@cisco.com>, <stds-802-1@ieee.org>,
        <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Mon Dec 01 18:40:12 2003
Return-path: <pwe3-admin@ietf.org>
To: <neil.2.harrison@bt.com>
In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2EF2@i2km07-ukbr.domain1.systemhost.net> from neil.2.harrison@bt.com on Mon, 1 Dec 2003 11:59:23 -0000
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Hi Neil,

comment below,
mark

---- neil.2.harrison@bt.com wrote:
> Hi Ali.....just a small remark.  regards, Neil
> 
> Ali Sajassi wrote 01 December 2003 08:13
> <snipped>
> > >   Where the eth client gets encapsulated (let's say in 
> > MPLS) is where the 
> > > LSP trail starts (this can be any box)....and there is an 
> > LSP trail term 
> > > point where they get decapsulated. (Yes I know folks also 
> > add a PW header 
> > > but this is not a layer network, simply an adaptation 
> > function).  This is 
> > > simply client/server encapulation and well defined in 
> > G.805.  If we carry 
> > > the eth clinet over any server layer, you mentioned ATM or 
> > FR (but I 
> > > could also add PDH, SDH, etc), then exactly the same applies.
> > 
> > No PDH and SDH are different. These are port-based Ethernet service; 
> > whereas, I was talking about vlan-based services (e.g., each 
> > VLAN is a VC) 
> > and making analogy between VLAN-id in Ethernet and DLCI in FR 
> > or VPI/VCI in 
> > ATM.
> NH=> I don't think this analogy is valid.  A VPI/VCI (ATM), DLCI (FR) or a 'label' (MPLS) are all examples of link-connection identifiers.  These entities have no network currency until/unless they are associated with some parent trail entity (no matter how that is created).  A VLAN ID is not a link-connection identifier.  It is more like a 'name', in that it subdivides the total MAC address population into contained sub-spaces of MAC addresses (that belong to a given VLAN).  I suppose it could be used in other ways, but that is my understanding of its native architectural significance.
> 
> regards, Neil
> <snipped

mark==> I think you have a reasonable grip on the intent of VLANs. From my own experience in defining products, it is clear though that a VLAN can have a membership of one, and can be used much like a link identifier. That use may not take in to account all the trail requirements you might see, but it is clearly possible including support for VLAN swapping/translation; and such solutions are already been marketed by vendors. There are some problems on the aggregation side, but am hopeful the formal definition of VLAN stacking might address these (not clear to me that all proprietary versions do).


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Ali Sajassi <sajassi@cisco.com>
Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention
Date: Mon, 01 Dec 2003 11:33:54 -0800
Lines: 54
Sender: pwe3-admin@ietf.org
References: <0536FC9B908BEC4597EE721BE6A3538904EF2EF2@i2km07-ukbr.domai
 n1.systemhost.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: <Maarten.Vissers@alcatel.de>
X-From: pwe3-admin@ietf.org Mon Dec 01 20:35:07 2003
Return-path: <pwe3-admin@ietf.org>
X-Sender: sajassi@airborne.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: <neil.2.harrison@bt.com>, <sajassi@cisco.com>, <stds-802-1@ieee.org>,
        <pwe3@ietf.org>
In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2EF2@i2km07-ukbr.domai
 n1.systemhost.net>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Hi Neil, Hopefully my last comment on this subject :-) regards,Ali

At 11:59 AM 12/1/2003 +0000, neil.2.harrison@bt.com wrote:
>Hi Ali.....just a small remark.  regards, Neil
>
>Ali Sajassi wrote 01 December 2003 08:13
><snipped>
> > >   Where the eth client gets encapsulated (let's say in
> > MPLS) is where the
> > > LSP trail starts (this can be any box)....and there is an
> > LSP trail term
> > > point where they get decapsulated. (Yes I know folks also
> > add a PW header
> > > but this is not a layer network, simply an adaptation
> > function).  This is
> > > simply client/server encapulation and well defined in
> > G.805.  If we carry
> > > the eth clinet over any server layer, you mentioned ATM or
> > FR (but I
> > > could also add PDH, SDH, etc), then exactly the same applies.
> >
> > No PDH and SDH are different. These are port-based Ethernet service;
> > whereas, I was talking about vlan-based services (e.g., each
> > VLAN is a VC)
> > and making analogy between VLAN-id in Ethernet and DLCI in FR
> > or VPI/VCI in
> > ATM.
>NH=> I don't think this analogy is valid.  A VPI/VCI (ATM), DLCI (FR) or a 
>'label' (MPLS) are all examples of link-connection identifiers.  These 
>entities have no network currency until/unless they are associated with 
>some parent trail entity (no matter how that is created).  A VLAN ID is 
>not a link-connection identifier.

Maybe we should first reach agreement on the type of Ethernet services 
before discussing the mechanisms to take care of these services. Both EVPL 
and EVPLAN services (based on MEF and ITU documents) use VLAN as service 
delimiter (connection identifier) to support muxed UNI just like FR and ATM.


>  It is more like a 'name', in that it subdivides the total MAC address 
> population into contained sub-spaces of MAC addresses (that belong to a 
> given VLAN).  I suppose it could be used in other ways, but that is my 
> understanding of its native architectural significance.

Not really. VLAN-id doesn't necessary divide the MAC address space.  Each 
VLAN-id can make use of the entire MAC address space in the IVL mode and 
IVL mode is the one that to be used to guarantee the independent operations 
of different services multiplexed over the  same UNI.

-Ali


>regards, Neil
><snipped


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Rahul Aggarwal <rahul@juniper.net>
Subject: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Mon, 1 Dec 2003 12:31:05 -0800 (PST)
Lines: 138
Sender: pwe3-admin@ietf.org
References: <20031125141941.K43991@sapphire.juniper.net> <3FC4E7A6.3010207@cisco.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Kireeti Kompella <kireeti@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, "" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Mon Dec 01 21:33:58 2003
Return-path: <pwe3-admin@ietf.org>
X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs
To: Luca Martini <lmartini@cisco.com>
In-Reply-To: <3FC4E7A6.3010207@cisco.com>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


Hi Luca,

How about:

1. >From the current draft-ietf-pwe3-control-protocol-:

   In the protocol specified herein, the pseudowire demultiplexor field
   is an MPLS label.  Thus the packets which are transmitted from one
   end of the pseudowire to the other are MPLS packets.  Unless the
   pseudowire endpoints are immediately adjacent, these MPLS packets
   must be transmitted through a PSN tunnel.  Any sort of PSN tunnel can
   be used, as long as it is possible to transmit MPLS packets through
   it.  The PSN tunnel can itself be an LSP, but it could equally well
   be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
   tunnel which can carry MPLS packets. Procedures for setting up and
   maintaining the PSN tunnels are outside the scope of this document.

Can we replace the last sentence in the above with the following:

   Procedures for setting up and maintaining the PSN tunnels with GRE
   or IP are specified in [MPLS-OVER-IP-GRE].

This will clarify that the intention is to use the existing MPLS WG
design for PWs over IP/GRE.

2. draft-raggarwa-pwe3-pw-over-ip-00.txt will be respun to describe
procedures for MPLS PWs over IPsec, only.

Thanks,
rahul


On Wed, 26 Nov 2003, Luca Martini wrote:

> Rahul,
>
> This is a significant change , which is past the last call of the
> document. In addition to that, this design competes with other work
> already submitted to MPLS WG. The pwe3 control draft already states :
> " The PSN tunnel can itself be an LSP, but it could equally well
>    be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
>    tunnel which can carry MPLS packets."
>
> it is not in the scope of this document, or WG charter, to specify how
> to carry MPLS in GRE,Ipsec etc.
> I believe that we should take this work   to the MPLS wg as standrads
> track draft.
>
> Tks.
> Luca
>
>
>
> Rahul Aggarwal wrote:
>
> >Hi Luca,
> >
> >Following up on the discussion on MPLS PWs over IP at the last IETF, here
> >is suggested text for draft-ietf-pwe3-control-protocol-04.txt. It applies
> >to section 3. Please let me know what you think.
> >
> >Thanks,
> >rahul
> >
> >-------------------------------------------------------------------------------
> >3. The Pseudowire Label
> >
> >.....
> >
> >So when PE1 sends a layer 2 PDU to PE2, it first pushes a PW label on
> >   its label stack, thereby creating an MPLS packet.  It then (if PE1 is
> >   not adjacent to PE2) encapsulates that MPLS packet in a PSN tunnel
> >   header.  (If the PSN tunnel is an LSP, this is just a matter of
> >   pushing on a second label.)  The PW label is not visible again until
> >   the MPLS packet reaches PE2. PE2's disposition of the packet is based
> >   on the PW label.
> >
> ><Delete : (If the PSN tunnel is.....second label) >
> >
> >Note that the PW label must always be at the bottom of the packet's
> >label stack and labels MUST be allocated from the per-platform label
> >space
> >
> ><Inserted Text Begin>
> >
> >If the PSN tunnel is an MPLS LSP, then putting on a PSN tunnel encapsulation
> >is a matter of pushing an additional MPLS label on the packet. This
> >upper MPLS label is the MPLS LSP label that causes the packet to be
> >delivered to the egress of the PW i.e PE2.
> >
> >In order to enable MPLS PWs to be deployed when there are non-MPLS routers
> >along the path between ingress and egress PE routers, it may be desirable
> >to use an IP or GRE PSN tunnel. In this case MPLS-in-IP or MPLS-in-GRE
> >[MPLS-OVER-IP-GRE] encapsulation is used to turn the MPLS PW packet into
> >an IP packet. The IP source address will be the address of the PW ingress
> >and the IP destination address will be the address of the PW egress. The
> >net effect is that a MPLS PW packet gets sent through a dynamically
> >created IP or GRE PSN tunnel. The egress PE decapsulates the MPLS-in-IP
> >or MPLS-in-GRE packets as in [MPLS-OVER-IP-GRE] and processes the
> >resulting MPLS PW packets.
> >
> >It may also be desirable to use an IPsec PSN tunnel [RFC2402, RFC2406] to
> >enable MPLS PW packets to be carried securely over non-MPLS networks.
> >One possible mechanism to achieve this is that the ingress PE creates an
> >MPLS-in-IP or MPLS-in-GRE encapsulated packet, as above. If required the
> >ingress PE then sets up a IPsec Security Association to the egress PE.
> >Appropriate IPsec procedures are then applied generating a packet with an
> >IP header followed by an IPsec header followed by MPLS-in-IP or MPLS-in-GRE
> >encapsulated MPLS PW packet. The egress PE applies the necessary IPsec
> >procedures to the arriving IPsec packets and recovers the contained
> >MPLS-in-IP or MPLS-in-GRE packets, which are then appropriately processed.
> >
> ><Inserted Text End>
> >
> >
> >[MPLS-OVER-IP-GRE] "Encapsulating MPLS in IP or GRE", T. Worster,
> >                   Rekhter Y., Rosen E., draft-ietf-mpls-in-ip-or-gre-03.txt
> >[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
> >          2402, November 1998.
> >
> >[RFC2406] Kent,S. and R. Atkinson, "IP Encapsulating Security Payload
> >          (ESP)", RFC 2406, November 1998.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Eric Rosen <erosen@cisco.com>
Subject: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Mon, 01 Dec 2003 16:02:15 -0500
Lines: 21
Sender: pwe3-admin@ietf.org
References: <20031201122130.S94082@sapphire.juniper.net>
Reply-To: erosen@cisco.com
Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Cc: Luca Martini <lmartini@cisco.com>, Kireeti Kompella <kireeti@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>, "" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Mon Dec 01 22:03:05 2003
Return-path: <pwe3-admin@ietf.org>
To: Rahul Aggarwal <rahul@juniper.net>
In-reply-to: Your message of Mon, 01 Dec 2003 12:31:05 -0800.
             <20031201122130.S94082@sapphire.juniper.net> 
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3
 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


draft> Any sort  of PSN tunnel can  be used, as  long as it is  possible to
draft> transmit MPLS packets  through it.  The PSN tunnel  can itself be an
draft> LSP, but  it could equally  well be an  IP tunnel, a GRE  tunnel, an
draft> IPsec  tunnel, or  any other  sort of  tunnel which  can  carry MPLS
draft> packets. Procedures  for setting up and maintaining  the PSN tunnels
draft> are outside the scope of this document. 

Rahul> Can we replace the last sentence in the above with the following:

Rahul>    Procedures for setting up and maintaining the PSN tunnels with GRE
Rahul>    or IP are specified in [MPLS-OVER-IP-GRE].

Since this change is not needed for technical correctness, I would prefer to
leave the draft as is.

Rahul> This will clarify that the intention is to use the existing MPLS WG
Rahul> design for PWs over IP/GRE.

How to carry  MPLS through a non-MPLS  network is out of scope;  I don't see
what intention needs to be clarified. 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: pat_thaler@agilent.com
Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention
Date: Mon, 1 Dec 2003 10:49:49 -0700
Lines: 300
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: <Maarten.Vissers@alcatel.de>
X-From: pwe3-admin@ietf.org Tue Dec 02 13:02:07 2003
Return-path: <pwe3-admin@ietf.org>
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Thread-Topic: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
Thread-Index: AcO1llEu5XIlzRgCSgSGTywBxO+l7QCkrFbA
To: <sajassi@cisco.com>, <neil.2.harrison@bt.com>, <stds-802-1@ieee.org>,
        <pwe3@ietf.org>
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Most traffic already has two levels of protection - though one is a =
checksum rather than a CRC. While VLAN tags weren't contemplated in the =
initial development of Ethernet, routers were. The appropriate layer for =
end-to-end protection is the network layer (or higher such as iSCSI's =
CRC or TCP checksum) and not the link layer. Even if one had a second =
CRC, I doubt that one could guarantee over time that there would be no =
other changes made to the packet. For example, there could be cases =
where the MAC address is translated or layer 3 funcionality could change =
MAC address and IP fields.

The MAC isn't the right place to add the protection being asked for. =
With the stated concern being checking for equipment malfunction rather =
than extreme high confidence of detecting every altered packet, =
checksums are good enough.

Pat

-----Original Message-----
From: owner-stds-802-1@majordomo.ieee.org
[mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Ali Sajassi
Sent: Wednesday, November 26, 2003 12:11 PM
To: neil.2.harrison@bt.com; sajassi@cisco.com; stds-802-1@ieee.org;
pwe3@ietf.org
Cc: Maarten.Vissers@alcatel.de
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention



Hi Neil,

At 10:26 AM 11/26/2003 +0000, neil.2.harrison@bt.com wrote:
>Hi Ali,
>
>The way I would answer (some of) your questions is as follows:
>
>-       according to the func arch draft Rec (G.8010) being developed =
for=20
>ethernet, the eth FCS belongs to the link-connection adaptation=20
>function.....not the end-end (ie between eth flow trail term points)=20
>characteristic information.  You may recall Juergen corrected me on =
this a=20
>couple of days ago.
>
>-       this means if any of the traffic unit that is covered by the =
FCS=20
>changes at a link-level then the FCS will need to be updated to reflect =

>the changes.  CRCs are linear functions, and it can shown =
mathematically=20
>that a known change to specific bits in the traffic unit can be =
corrected=20
>by an update of the FCS and only the FCS, ie there is no need to=20
>recalculate the FCS over the entire traffic unit.  This is no different =
in=20
>principle to the HEC function that protects the ATM header (but only =
the=20
>ATM header) since the VPI/VCI label usually changes on=20
>link-connections.  One can consider the eth VLAN field in a similar=20
>manner, ie known changes to the VLAN field can be reflected as updates =
of=20
>the FCS.

Yes and this is the intended mechanism for bridges and it is reflected =
in=20
Appendix F of 802.1D as I mentioned in one of my previous emails.


>-       the lesson that I take away from the above observations is that =

>architecturally it makes more sense to have 2 different CRCs, (i) one=20
>protecting only the CI that goes between trail term points =
transparently=20
>(ie never changes on link-connections) and (ii) one protecting only the =

>link-connection specific part of the client traffic unit that can =
change=20
>on link-connections (so this needs a linear update per link =
connection).

So in the context of our discussions, given that the PEs are intended to =

provide transport functionality with respect to Ethernet services and =
not=20
interworking, then it means any FCS to be added for the CI portion is =
the=20
job of the CE and not the PE - this is analogous to ATM and FR transport =

where you don't expect the ATM switch or FR switch to add a CRC for the=20
payload.


>-       When ethernet was first designed the above issues were never=20
>considered....and in particular there was no VLAN field.  We cannot now =
go=20
>back and change this IMO.  However, the FCS does still belong to the =
eth=20
>client and IMO it should never be discarded in some arbitrary manner by =
a=20
>server layer.  I use the word 'arbitrary' here since I have noted=20
>different behaviours specified in G.8010 which I don't think is a good=20
>idea, eg for all co-cs server technologies the carriage of the eth FCS =
is=20
>a 'must', for an ATM co-ps server layer the carriage of the FCS is=20
>'optional', and for an MPLS co-ps server it currently says it can be=20
>'removed'.  A client and server layer network should be =
independent.....so=20
>having different behaviours dependent on the server layer mode and/or=20
>specific technology is not a logical behaviour to me.  IMO the default=20
>behaviour of the server layer should always be to carry the client =
layer=20
>traffic unit transparently.

And in terms of bridge applications, the client layer (user data) =
doesn't=20
have FCS (the FCS belongs to the server layer - the MAC layer) and the=20
client layer FCS (if needed) is the responsibility of the application =
and=20
not the bridge. So if you want to have a new encapsulation on the CE =
side=20
(similar to 1483/1490 that can have FCS for client data), then that a=20
separate issue but we shouldn't impose such requirement on the bridges.

Regards,
Ali


>regards, Neil
>
>
> > -----Original Message-----
> > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of =
Ali
> > Sajassi
> > Sent: 26 November 2003 02:24
> > To: mick_seaman@ieee.org; 'Scott Kotrla'; stds-802-1@ieee.org;
> > pwe3@ietf.org
> > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
> >
> >
> > I ask the question of service applicability for FCS retention
> > some time ago
> > and I didn't get a clear answer so let me ask again. When
> > talking about FCS
> > retention, which I of the following four Ethernet services do
> > you have in
> > mind ?
> >
> > 1) port-based point-to-point Ethernet service
> > 2) vlan-based point-to-point Ethernet service
> > 3) port-based Ethernet bridge service (multipoint)
> > 4) vlan-based Ethernet bridge service (multipoint)
> >
> > In vlan-based service, the customer vlan is used as service
> > delimiter and
> > is NOT the same at the two ends of the service - e.g., just
> > like frame
> > relay or ATM where DLCI or VPI/VCI are not the same at two
> > ends. Requiring
> > that the VLANs be the same at the two ends, imposes
> > unnecessary restriction
> > in customer provisioning model. Therefore, FCS retention is
> > not viable for
> > applications where customer VLAN is used as service delimiter.
> >
> > Also any bridge service (port-based or vlan-based) doesn't
> > require FCS
> > retention by the definition of the bridge service itself.
> >
> > So, the only applicable service for this FCS retention stuff
> > (and I doubt
> > viability of it), is for port-based point-to-point service.
> > However, I
> > would like to ask the following question:
> >
> > How do you catch the errors introduced by the switches for the other
> > services ??? Given that the same set of networking gears is
> > to support all
> > four Ethernet services, are you suggesting that we only need
> > to solve the
> > problem for a single service and not to worry about other
> > service type !!!
> > Or are you suggesting that you only offer a single service
> > and thus you
> > don't have to worry about other services !!!
> >
> > As I mentioned previously, a better approach is to solve the
> > problem for
> > all the Ethernet services - whether it is through OAM
> > mechanisms or through
> > internal switch check-sum or a combination of two or
> > whatever. But the
> > point is we should try to address the issue for ALL service types.
> >
> > -Ali
> >
> > At 12:01 PM 11/25/2003 -0800, Mick Seaman wrote:
> >
> > >If you are not concerned about protecting the customer but
> > merely locating
> > >repetitively failed switch then OAM-like operations and test
> > should be
> > >sufficient. It remains the case that placing exactly the
> > same error check
> > >algorithm on the outer CRC as the inner does not extend your
> > fault coverage
> > >for the customer much. Switch faults will still be capable
> > of bringing the
> > >entire network to a halt and sending the wrong packets to the wrong
> > >customers. Anyone who buys a network service from a provider
> > with poor
> > >internals on the grounds that the outer CRC will protect him
> > is being simply
> > >naive. I'll go further than that, if a salesman tries to
> > sell me a service
> > >with an outer CRC I will know that I can't trust the network
> > and simply
> > >should not buy.
> > >
> > >Moreover as I have pointed out it is perfectly in the spirit
> > of the 802.1
> > >standards that the switch recalculate both the inner and the
> > outer CRC, and
> > >indeed where the format of the frame delievered to the
> > custoomer changes
> > >through the network it will have to recalculate both.
> > >
> > >Mick
> > >
> > >-----Original Message-----
> > >From: owner-stds-802-1@majordomo.ieee.org
> > >[mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott =
Kotrla
> > >Sent: Tuesday, November 25, 2003 8:36 AM
> > >To: mick_seaman@ieee.org; stds-802-1@ieee.org; pwe3@ietf.org
> > >Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
> > >
> > >
> > >
> > >So are you suggesting because a CRC-32 will miss 1 in 4
> > billion frames
> > >it is not useful to know?  I don't need to catch every frame to =
know
> > >there is a problem.
> > >
> > >The standard Ethernet CRC protects the link and not the
> > internal switch,
> > >and it is very difficult to put requirements on the internal
> > working of
> > >a switch.  As stated in a previous message:
> > >
> > >"The model of operation is simply a basis for describing the
> > >functionality of the MAC Bridge. It is in no way intended to
> > constrain
> > >real implementations of a MAC Bridge; these may adopt any
> > internal model
> > >of operation compatible with the externally visible behavior
> > that this
> > >standard specifies. Conformance of equipment to this
> > standard is purely
> > >in respect of observable protocol."
> > >
> > >I am not worried about link errors.  I am worried about corruption
> > >within switches.  If switches have unknown failure modes that add
> > >unknown corruption, what besides a Path FCS will be able to =
determine
> > >that there is a problem.  Once again, detection is at least
> > 10 times as
> > >important as diagnosis.  If we can come up with a better way
> > to detect
> > >when (not if) switches are corrupting packets, I would be very
> > >interested in understanding the benefits of this approach.
> > >
> > >The service provider requirement can be succinctly stated as:
> > >
> > >The network shall be able to detect when (not if) switches are
> > >corrupting packets.  Suggesting that switches will never =
unknowingly
> > >corrupt packets is wishing the problem away and is not an =
acceptable
> > >answer.  Never is a very long time.  Besides, out of the 100 or so
> > >switches I have worked with, I have already seen it happen.  And I =
am
> > >not all that lucky.
> > >
> > >Thanks,
> > >
> > >Scott
> >
> >
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >


_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Tue, 02 Dec 2003 13:15:29 +0000
Organization: Cisco Systems, Inc.
Lines: 30
Sender: pwe3-admin@ietf.org
References: <20031125141941.K43991@sapphire.juniper.net> <3FC4E7A6.3010207@cisco.com> <20031201122130.S94082@sapphire.juniper.net>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Luca Martini <lmartini@cisco.com>, Kireeti Kompella <kireeti@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 02 14:17:12 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: Rahul Aggarwal <rahul@juniper.net>
In-Reply-To: <20031201122130.S94082@sapphire.juniper.net>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



Rahul Aggarwal wrote:

> Hi Luca,
> 
> How about:
> 
> 1. >From the current draft-ietf-pwe3-control-protocol-:
> 
>    In the protocol specified herein, the pseudowire demultiplexor field
>    is an MPLS label.  Thus the packets which are transmitted from one
>    end of the pseudowire to the other are MPLS packets.  Unless the
>    pseudowire endpoints are immediately adjacent, these MPLS packets
>    must be transmitted through a PSN tunnel.  Any sort of PSN tunnel can
>    be used, as long as it is possible to transmit MPLS packets through
>    it.  The PSN tunnel can itself be an LSP, but it could equally well
>    be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
>    tunnel which can carry MPLS packets. Procedures for setting up and
>    maintaining the PSN tunnels are outside the scope of this document.
> 
> Can we replace the last sentence in the above with the following:
> 
>    Procedures for setting up and maintaining the PSN tunnels with GRE
>    or IP are specified in [MPLS-OVER-IP-GRE].

The new text is prescriptive about MPLS-OVER-IP-GRE being THE method.
Do we have WG concensus for that?

Stewart


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Dan Tappan <tappan@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for
  draft-ietf-pwe3-control-protocol-04.txt
Date: Tue, 02 Dec 2003 08:36:27 -0500
Lines: 30
Sender: pwe3-admin@ietf.org
References: <20031201122130.S94082@sapphire.juniper.net>
 <20031125141941.K43991@sapphire.juniper.net>
 <3FC4E7A6.3010207@cisco.com>
 <20031201122130.S94082@sapphire.juniper.net> <3FCC9071.9020404@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Rahul Aggarwal <rahul@juniper.net>, Luca Martini <lmartini@cisco.com>,
        Kireeti Kompella <kireeti@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 02 14:38:04 2003
Return-path: <pwe3-admin@ietf.org>
X-Sender: tappan@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: stbryant@cisco.com
In-Reply-To: <3FCC9071.9020404@cisco.com>
References: <20031201122130.S94082@sapphire.juniper.net>
 <20031125141941.K43991@sapphire.juniper.net>
 <3FC4E7A6.3010207@cisco.com>
 <20031201122130.S94082@sapphire.juniper.net>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

At 01:15 PM 12/2/2003 +0000, Stewart Bryant wrote:



>Rahul Aggarwal wrote:
>
>>Hi Luca,
>>How about:
>>1. >From the current draft-ietf-pwe3-control-protocol-:
>>    In the protocol specified herein, the pseudowire demultiplexor field
>>    is an MPLS label.  Thus the packets which are transmitted from one
>>    end of the pseudowire to the other are MPLS packets.  Unless the
>>    pseudowire endpoints are immediately adjacent, these MPLS packets
>>    must be transmitted through a PSN tunnel.  Any sort of PSN tunnel can
>>    be used, as long as it is possible to transmit MPLS packets through
>>    it.  The PSN tunnel can itself be an LSP, but it could equally well
>>    be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
>>    tunnel which can carry MPLS packets. Procedures for setting up and
>>    maintaining the PSN tunnels are outside the scope of this document.
>>Can we replace the last sentence in the above with the following:
>>    Procedures for setting up and maintaining the PSN tunnels with GRE
>>    or IP are specified in [MPLS-OVER-IP-GRE].
>
>The new text is prescriptive about MPLS-OVER-IP-GRE being THE method.
>Do we have WG concensus for that?

All other issues aside: if [MPLS-OVER-IP-GRE] means 
http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-ip-or-gre-03.txt, 
that draft does not contain any procedures for setting up or maintaining 
PSN tunnels with GRE or IP. It describes encapsulation procedures.


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Andrew G. Malis" <andy.malis@tellabs.com>
Subject: Re: Re: MPLS PWs over IP: Text for
  draft-ietf-pwe3-control-protocol-04.txt
Date: Tue, 02 Dec 2003 09:14:32 -0500
Lines: 23
Sender: pwe3-admin@ietf.org
References: <20031201122130.S94082@sapphire.juniper.net>
 <20031125141941.K43991@sapphire.juniper.net>
 <3FC4E7A6.3010207@cisco.com>
 <20031201122130.S94082@sapphire.juniper.net>
 <4.3.2.7.2.20031202082956.040cf578@flask.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Rahul Aggarwal <rahul@juniper.net>, Luca Martini <lmartini@cisco.com>,
        Kireeti Kompella <kireeti@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 02 15:17:04 2003
Return-path: <pwe3-admin@ietf.org>
X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1
To: stbryant@cisco.com, Dan Tappan <tappan@cisco.com>
In-Reply-To: <4.3.2.7.2.20031202082956.040cf578@flask.cisco.com>
References: <20031201122130.S94082@sapphire.juniper.net>
 <20031125141941.K43991@sapphire.juniper.net>
 <3FC4E7A6.3010207@cisco.com>
 <20031201122130.S94082@sapphire.juniper.net>
 <4.3.2.7.2.20031202082956.040cf578@flask.cisco.com>
X-OriginalArrivalTime: 02 Dec 2003 14:15:31.0125 (UTC) FILETIME=[BE499650:01C3B8DE]
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Stewart and Dan,

>>The new text is prescriptive about MPLS-OVER-IP-GRE being THE method.
>>Do we have WG concensus for that?

Yes, that was the whole point of the discussion in Minneapolis, and the 
continuation on the list.  draft-ietf-mpls-in-ip-or-gre-03.txt is the MPLS 
WG draft for transporting MPLS packets through non-MPLS IP 
networks.  There's no need for the PWE3 WG to either redefine what's in 
this draft, or even worse, define something else entirely.

>All other issues aside: if [MPLS-OVER-IP-GRE] means 
>http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-ip-or-gre-03.txt, 
>that draft does not contain any procedures for setting up or maintaining 
>PSN tunnels with GRE or IP. It describes encapsulation procedures.

Well, encapsulation is all that's really needed to "set up or maintain PSN 
tunnels with GRE or IP".  Plus the draft discusses the relationship between 
the tunnel header and the outer MPLS label.  So it's really all that's 
needed for PWE3 purposes.

Cheers,
Andy


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "W. Mark Townsley" <townsley@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for  draft-ietf-pwe3-control-protocol-04.txt
Date: Tue, 02 Dec 2003 16:18:27 +0100
Lines: 45
Sender: pwe3-admin@ietf.org
References: <20031201122130.S94082@sapphire.juniper.net> <20031125141941.K43991@sapphire.juniper.net> <3FC4E7A6.3010207@cisco.com> <20031201122130.S94082@sapphire.juniper.net> <4.3.2.7.2.20031202082956.040cf578@flask.cisco.com> <6.0.1.1.2.20031202090558.033b7af0@mail.comcast.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stbryant@cisco.com, Dan Tappan <tappan@cisco.com>,
        Rahul Aggarwal <rahul@juniper.net>, Luca Martini <lmartini@cisco.com>,
        Kireeti Kompella <kireeti@juniper.net>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 02 16:20:10 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
To: "Andrew G. Malis" <andy.malis@tellabs.com>
In-Reply-To: <6.0.1.1.2.20031202090558.033b7af0@mail.comcast.net>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


Andrew G. Malis wrote:
> Stewart and Dan,
> 
>>> The new text is prescriptive about MPLS-OVER-IP-GRE being THE method.
>>> Do we have WG concensus for that?
> 
> 
> Yes, that was the whole point of the discussion in Minneapolis, and the 
> continuation on the list.  draft-ietf-mpls-in-ip-or-gre-03.txt is the 
> MPLS WG draft for transporting MPLS packets through non-MPLS IP 
> networks.  There's no need for the PWE3 WG to either redefine what's in 
> this draft, or even worse, define something else entirely.

Further, there is no reason for the PWE3 WG to make special reference to this or 
any other specific tunneling draft. Currently, the text in this paragraph reads 
that "Any sort of PSN tunnel can be used, as long as it is possible to transmit 
MPLS packets through it." and lists MPLS, GRE, IP, IPsec, all simply as 
examples. The paragraph goes to to say that any tunnel setup mechanisms 
(including an MPLS LSP or any other tunnel type, listed as an example or not) 
are simply out of scope in this WG. This is perfectly inline with the charter. 
Calling out a reference to a given specific document for GRE and IP seems 
arbitrary, changes the scope of this document, and if done as suggested leaves 
other tunnel methods dangling.

- Mark

> 
>> All other issues aside: if [MPLS-OVER-IP-GRE] means 
>> http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-ip-or-gre-03.txt, 
>> that draft does not contain any procedures for setting up or 
>> maintaining PSN tunnels with GRE or IP. It describes encapsulation 
>> procedures.
> 
> 
> Well, encapsulation is all that's really needed to "set up or maintain 
> PSN tunnels with GRE or IP".  
 > Plus the draft discusses the relationship
> between the tunnel header and the outer MPLS label.  So it's really all 
> that's needed for PWE3 purposes.
> 
> Cheers,
> Andy
> 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for  draft-ietf-pwe3-control-protocol-04.txt
Date: Tue, 02 Dec 2003 16:32:31 +0000
Organization: Cisco Systems, Inc.
Lines: 38
Sender: pwe3-admin@ietf.org
References: <20031201122130.S94082@sapphire.juniper.net> <20031125141941.K43991@sapphire.juniper.net> <3FC4E7A6.3010207@cisco.com> <20031201122130.S94082@sapphire.juniper.net> <4.3.2.7.2.20031202082956.040cf578@flask.cisco.com> <6.0.1.1.2.20031202090558.033b7af0@mail.comcast.net>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Dan Tappan <tappan@cisco.com>, Rahul Aggarwal <rahul@juniper.net>,
        Luca Martini <lmartini@cisco.com>,
        Kireeti Kompella <kireeti@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 02 17:34:10 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: "Andrew G. Malis" <andy.malis@tellabs.com>
In-Reply-To: <6.0.1.1.2.20031202090558.033b7af0@mail.comcast.net>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



Andrew G. Malis wrote:
> Stewart and Dan,
> 
>>> The new text is prescriptive about MPLS-OVER-IP-GRE being THE method.
>>> Do we have WG concensus for that?
> 
> 
> Yes, that was the whole point of the discussion in Minneapolis, and the 
> continuation on the list.  draft-ietf-mpls-in-ip-or-gre-03.txt is the 
> MPLS WG draft for transporting MPLS packets through non-MPLS IP 
> networks.  There's no need for the PWE3 WG to either redefine what's in 
> this draft, or even worse, define something else entirely.
> 

... and Luca's original text said that the method of encapsulation was out
or PWE3 scope (and by implication in MPLS scope), so it sounds as if
his text should stand unchanged.

>> All other issues aside: if [MPLS-OVER-IP-GRE] means 
>> http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-ip-or-gre-03.txt, 
>> that draft does not contain any procedures for setting up or 
>> maintaining PSN tunnels with GRE or IP. It describes encapsulation 
>> procedures.
> 
> 
> Well, encapsulation is all that's really needed to "set up or maintain 
> PSN tunnels with GRE or IP".  Plus the draft discusses the relationship 
> between the tunnel header and the outer MPLS label.  So it's really all 
> that's needed for PWE3 purposes.
> 

... but do we really need to add the reference? Surely it is adequate to
leave the text, or PERHAPS to say something like "such methods as are
aproved by the MPLS WG"?

Stewart


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "W. Mark Townsley" <townsley@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for  draft-ietf-pwe3-control-protocol-04.txt
Date: Tue, 02 Dec 2003 18:04:52 +0100
Lines: 51
Sender: pwe3-admin@ietf.org
References: <20031201122130.S94082@sapphire.juniper.net> <20031125141941.K43991@sapphire.juniper.net> <3FC4E7A6.3010207@cisco.com> <20031201122130.S94082@sapphire.juniper.net> <4.3.2.7.2.20031202082956.040cf578@flask.cisco.com> <6.0.1.1.2.20031202090558.033b7af0@mail.comcast.net> <3FCCBE9F.4020801@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "Andrew G. Malis" <andy.malis@tellabs.com>, Dan Tappan <tappan@cisco.com>,
        Rahul Aggarwal <rahul@juniper.net>, Luca Martini <lmartini@cisco.com>,
        Kireeti Kompella <kireeti@juniper.net>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 02 18:06:22 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
To: stbryant@cisco.com
In-Reply-To: <3FCCBE9F.4020801@cisco.com>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



Stewart Bryant wrote:
> 
> 
> Andrew G. Malis wrote:
> 
>> Stewart and Dan,
>>
>>>> The new text is prescriptive about MPLS-OVER-IP-GRE being THE method.
>>>> Do we have WG concensus for that?
>>
>>
>>
>> Yes, that was the whole point of the discussion in Minneapolis, and 
>> the continuation on the list.  draft-ietf-mpls-in-ip-or-gre-03.txt is 
>> the MPLS WG draft for transporting MPLS packets through non-MPLS IP 
>> networks.  There's no need for the PWE3 WG to either redefine what's 
>> in this draft, or even worse, define something else entirely.
>>
> 
> ... and Luca's original text said that the method of encapsulation was out
> or PWE3 scope (and by implication in MPLS scope), so it sounds as if
> his text should stand unchanged.
> 
>>> All other issues aside: if [MPLS-OVER-IP-GRE] means 
>>> http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-ip-or-gre-03.txt, 
>>> that draft does not contain any procedures for setting up or 
>>> maintaining PSN tunnels with GRE or IP. It describes encapsulation 
>>> procedures.
>>
>>
>>
>> Well, encapsulation is all that's really needed to "set up or maintain 
>> PSN tunnels with GRE or IP".  Plus the draft discusses the 
>> relationship between the tunnel header and the outer MPLS label.  So 
>> it's really all that's needed for PWE3 purposes.
>>
> 
> ... but do we really need to add the reference? Surely it is adequate to
> leave the text, or PERHAPS to say something like "such methods as are
> aproved by the MPLS WG"?

Isn't that simply stating the obvious?

> 
> Stewart
> 
> 
> 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Andrew G. Malis" <andy.malis@tellabs.com>
Subject: Re: Re: MPLS PWs over IP: Text for 
  draft-ietf-pwe3-control-protocol-04.txt
Date: Tue, 02 Dec 2003 13:29:27 -0500
Lines: 49
Sender: pwe3-admin@ietf.org
References: <20031201122130.S94082@sapphire.juniper.net>
 <20031125141941.K43991@sapphire.juniper.net>
 <3FC4E7A6.3010207@cisco.com>
 <20031201122130.S94082@sapphire.juniper.net>
 <4.3.2.7.2.20031202082956.040cf578@flask.cisco.com>
 <6.0.1.1.2.20031202090558.033b7af0@mail.comcast.net>
 <3FCCBE9F.4020801@cisco.com>
 <3FCCC634.1090603@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: stbryant@cisco.com, "Andrew G. Malis" <andy.malis@tellabs.com>,
        Dan Tappan <tappan@cisco.com>, Rahul Aggarwal <rahul@juniper.net>,
        Luca Martini <lmartini@cisco.com>,
        Kireeti Kompella <kireeti@juniper.net>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 02 19:31:07 2003
Return-path: <pwe3-admin@ietf.org>
X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1
To: "W. Mark Townsley" <townsley@cisco.com>
In-Reply-To: <3FCCC634.1090603@cisco.com>
References: <20031201122130.S94082@sapphire.juniper.net>
 <20031125141941.K43991@sapphire.juniper.net>
 <3FC4E7A6.3010207@cisco.com>
 <20031201122130.S94082@sapphire.juniper.net>
 <4.3.2.7.2.20031202082956.040cf578@flask.cisco.com>
 <6.0.1.1.2.20031202090558.033b7af0@mail.comcast.net>
 <3FCCBE9F.4020801@cisco.com>
 <3FCCC634.1090603@cisco.com>
X-OriginalArrivalTime: 02 Dec 2003 18:29:33.0120 (UTC) FILETIME=[3B397400:01C3B902]
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

I agree fully with Mark's two messages.  The text should stand as is.

Cheers,
Andy

----------

At 12/2/2003 06:04 PM +0100, W. Mark Townsley wrote:


>Stewart Bryant wrote:
>>
>>Andrew G. Malis wrote:
>>
>>>Stewart and Dan,
>>>
>>>>>The new text is prescriptive about MPLS-OVER-IP-GRE being THE method.
>>>>>Do we have WG concensus for that?
>>>
>>>
>>>
>>>Yes, that was the whole point of the discussion in Minneapolis, and the 
>>>continuation on the list.  draft-ietf-mpls-in-ip-or-gre-03.txt is the 
>>>MPLS WG draft for transporting MPLS packets through non-MPLS IP 
>>>networks.  There's no need for the PWE3 WG to either redefine what's in 
>>>this draft, or even worse, define something else entirely.
>>... and Luca's original text said that the method of encapsulation was out
>>or PWE3 scope (and by implication in MPLS scope), so it sounds as if
>>his text should stand unchanged.
>>
>>>>All other issues aside: if [MPLS-OVER-IP-GRE] means 
>>>>http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-ip-or-gre-03.txt, 
>>>>  that draft does not contain any procedures for setting up or 
>>>>maintaining PSN tunnels with GRE or IP. It describes encapsulation procedures.
>>>
>>>
>>>
>>>Well, encapsulation is all that's really needed to "set up or maintain 
>>>PSN tunnels with GRE or IP".  Plus the draft discusses the relationship 
>>>between the tunnel header and the outer MPLS label.  So it's really all 
>>>that's needed for PWE3 purposes.
>>... but do we really need to add the reference? Surely it is adequate to
>>leave the text, or PERHAPS to say something like "such methods as are
>>aproved by the MPLS WG"?
>
>Isn't that simply stating the obvious?
>
>>Stewart
>>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Ron Cohen" <ronc@lyciumnetworks.com>
Subject: Sequence number text in Fragmentation draft
Date: Tue, 2 Dec 2003 12:03:35 -0800
Lines: 40
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: "Sasha Vainshtein" <Sasha@AXERRA.com>
X-From: pwe3-admin@ietf.org Tue Dec 02 21:05:23 2003
Return-path: <pwe3-admin@ietf.org>
To: "PWE3 \(IETF\)" <pwe3@ietf.org>, "Andy Malis" <Andy.malis@tellabs.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Hi,

I have a small remark regarding the text on sequence number in
draft-ietf-pwe3-fragmentation-03 

The current text reads (section 4.1):

    The Sequence Number is used as already specified in the above 
    protocol specifications.  Specifically, since the value 0 indicates 
    that the sequence number is not in use, its use for fragmentation 
    must follow this same rule - as the sequence number is incremented, 
    it skips zero and wraps from 65535 to 1.

I suggest to modify this text to reflect the fact that there are
services (SATOP) that use the entire range of sequence numbers
(including zero) in the control word. This remark is only editorial but
clarifies that the FRG bits and control word can be used in these cases
as well.

Thanks
Ron



Ron Cohen
CTO
Lycium Networks 
Mobile: 650.823.7672
Mobile:  +972.55.245.104
Tel:  650.234.4010
Fax:  650.854.8183

===================================================== 
This email message and any files transmitted with it contain
confidential information intended only for its addressee(s). If you are
not the addressee of this message, any reading, disclosure, copying,
printing, distribution or forwarding by you of this message or its
content or attachments is strictly forbidden. In such case, please
notify us immediately by replying to this message or by calling
650.234.4010 and delete the message from your computer. Thank you.


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Yakov Rekhter <yakov@juniper.net>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Tue, 02 Dec 2003 13:29:18 -0800
Lines: 45
Sender: pwe3-admin@ietf.org
References: <3FCC9071.9020404@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Rahul Aggarwal <rahul@juniper.net>, Luca Martini <lmartini@cisco.com>,
        Kireeti Kompella <kireeti@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 02 22:31:13 2003
Return-path: <pwe3-admin@ietf.org>
To: stbryant@cisco.com
In-Reply-To: Your message of "Tue, 02 Dec 2003 13:15:29 GMT."
             <3FCC9071.9020404@cisco.com> 
Content-ID: <36536.1070400558.1@juniper.net>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Stewart,

> Rahul Aggarwal wrote:
> 
> > Hi Luca,
> > 
> > How about:
> > 
> > 1. >From the current draft-ietf-pwe3-control-protocol-:
> > 
> >    In the protocol specified herein, the pseudowire demultiplexor field
> >    is an MPLS label.  Thus the packets which are transmitted from one
> >    end of the pseudowire to the other are MPLS packets.  Unless the
> >    pseudowire endpoints are immediately adjacent, these MPLS packets
> >    must be transmitted through a PSN tunnel.  Any sort of PSN tunnel can
> >    be used, as long as it is possible to transmit MPLS packets through
> >    it.  The PSN tunnel can itself be an LSP, but it could equally well
> >    be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
> >    tunnel which can carry MPLS packets. Procedures for setting up and
> >    maintaining the PSN tunnels are outside the scope of this document.
> > 
> > Can we replace the last sentence in the above with the following:
> > 
> >    Procedures for setting up and maintaining the PSN tunnels with GRE
> >    or IP are specified in [MPLS-OVER-IP-GRE].
> 
> The new text is prescriptive about MPLS-OVER-IP-GRE being THE method.

Let's look at the proposed text again:

     Procedures for setting up and maintaining the PSN tunnels with GRE
     or IP are specified in [MPLS-OVER-IP-GRE].

The new text is prescriptive about MPLS-OVER-IP-GRE being THE method,
*but only* when the tunnel is GRE or IP.

On the other hand, the new text is *not* prescriptive about MPLS-OVER-IP-GRE
being the only way to carry MPLS packets through non-MPLS IP networks.

> Do we have WG concensus for that?

In view of the above could you please be more specific about what
do you mean by "that".

Yakov.


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Rahul Aggarwal <rahul@juniper.net>
Subject: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Tue, 2 Dec 2003 14:00:33 -0800 (PST)
Lines: 41
Sender: pwe3-admin@ietf.org
References: <200312012102.hB1L2FDM002287@rtp-core-2.cisco.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Luca Martini <lmartini@cisco.com>, Kireeti Kompella <kireeti@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>, "" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Tue Dec 02 23:02:13 2003
Return-path: <pwe3-admin@ietf.org>
X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs
To: Eric Rosen <erosen@cisco.com>
In-Reply-To: <200312012102.hB1L2FDM002287@rtp-core-2.cisco.com>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


Hi Eric,

On Mon, 1 Dec 2003, Eric Rosen wrote:

>
> draft> Any sort  of PSN tunnel can  be used, as  long as it is  possible to
> draft> transmit MPLS packets  through it.  The PSN tunnel  can itself be an
> draft> LSP, but  it could equally  well be an  IP tunnel, a GRE  tunnel, an
> draft> IPsec  tunnel, or  any other  sort of  tunnel which  can  carry MPLS
> draft> packets. Procedures  for setting up and maintaining  the PSN tunnels
> draft> are outside the scope of this document.
>
> Rahul> Can we replace the last sentence in the above with the following:
>
> Rahul>    Procedures for setting up and maintaining the PSN tunnels with GRE
> Rahul>    or IP are specified in [MPLS-OVER-IP-GRE].
>
> Since this change is not needed for technical correctness, I would prefer to
> leave the draft as is.
>

>From the WG minutes:

<minutes> Luca Martini - Said that it is contained in control document
<minutes> Rahul - will follow up, but not sure that it is in control
           document
<minutes> Luca - send me a paragraph

Luca had said that there is merit in the approach and asked me to send
any suggested clarification. I agree that the earlier proposed text was
verbose and included procedures for IPsec which is not in scope of the
control document.

However the above proposed change is needed for *completeness* as
in the case where MPLS PWs are carried over IP or GRE tunnels
the proposed change points to a specific existing IETF document
that specifies how to encapsulate MPLS over IP/GRE.

thanks,
rahul


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Andy Malis" <Andy.Malis@tellabs.com>
Subject: RE: Sequence number text in Fragmentation draft
Date: Tue, 2 Dec 2003 15:25:32 -0800
Lines: 34
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
Cc: "Sasha Vainshtein" <Sasha@AXERRA.com>
X-From: pwe3-admin@ietf.org Wed Dec 03 00:27:05 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
Thread-Topic: Sequence number text in Fragmentation draft
Thread-Index: AcO5ECk+SfWSzZ1ERSKKHkPhM4gucwAGwkk+
To: "Ron Cohen" <ronc@lyciumnetworks.com>, "PWE3 (IETF)" <pwe3@ietf.org>
Content-Transfer-Encoding: base64
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Um9uLA0KIA0KVGhhbmtzLCBJJ2xsIHB1dCB0aGF0IGludG8gdGhlIG5leHQgcmV2aXNpb24gZm9s
bG93aW5nIFdHIGxhc3QgY2FsbCAoSSdsbCBjb25zaWRlciB0aGlzIGFzIGEgbGFzdCBjYWxsIGNv
bW1lbnQpLiAgQlRXLCB0aGF0J3MgYSBoaW50IGZvciBEYW5ueSBhbmQgU3Rld2FydCAuLi4gOi0p
DQogDQpDaGVlcnMsDQpBbmR5DQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9t
OiBSb24gQ29oZW4gW21haWx0bzpyb25jQGx5Y2l1bW5ldHdvcmtzLmNvbV0gDQoJU2VudDogVHVl
IDEyLzIvMjAwMyAzOjAzIFBNIA0KCVRvOiBQV0UzIChJRVRGKTsgQW5keSBNYWxpcyANCglDYzog
U2FzaGEgVmFpbnNodGVpbiANCglTdWJqZWN0OiBTZXF1ZW5jZSBudW1iZXIgdGV4dCBpbiBGcmFn
bWVudGF0aW9uIGRyYWZ0DQoJDQoJDQoNCglIaSwNCgkNCglJIGhhdmUgYSBzbWFsbCByZW1hcmsg
cmVnYXJkaW5nIHRoZSB0ZXh0IG9uIHNlcXVlbmNlIG51bWJlciBpbg0KCWRyYWZ0LWlldGYtcHdl
My1mcmFnbWVudGF0aW9uLTAzDQoJDQoJVGhlIGN1cnJlbnQgdGV4dCByZWFkcyAoc2VjdGlvbiA0
LjEpOg0KCQ0KCSAgICBUaGUgU2VxdWVuY2UgTnVtYmVyIGlzIHVzZWQgYXMgYWxyZWFkeSBzcGVj
aWZpZWQgaW4gdGhlIGFib3ZlDQoJICAgIHByb3RvY29sIHNwZWNpZmljYXRpb25zLiAgU3BlY2lm
aWNhbGx5LCBzaW5jZSB0aGUgdmFsdWUgMCBpbmRpY2F0ZXMNCgkgICAgdGhhdCB0aGUgc2VxdWVu
Y2UgbnVtYmVyIGlzIG5vdCBpbiB1c2UsIGl0cyB1c2UgZm9yIGZyYWdtZW50YXRpb24NCgkgICAg
bXVzdCBmb2xsb3cgdGhpcyBzYW1lIHJ1bGUgLSBhcyB0aGUgc2VxdWVuY2UgbnVtYmVyIGlzIGlu
Y3JlbWVudGVkLA0KCSAgICBpdCBza2lwcyB6ZXJvIGFuZCB3cmFwcyBmcm9tIDY1NTM1IHRvIDEu
DQoJDQoJSSBzdWdnZXN0IHRvIG1vZGlmeSB0aGlzIHRleHQgdG8gcmVmbGVjdCB0aGUgZmFjdCB0
aGF0IHRoZXJlIGFyZQ0KCXNlcnZpY2VzIChTQVRPUCkgdGhhdCB1c2UgdGhlIGVudGlyZSByYW5n
ZSBvZiBzZXF1ZW5jZSBudW1iZXJzDQoJKGluY2x1ZGluZyB6ZXJvKSBpbiB0aGUgY29udHJvbCB3
b3JkLiBUaGlzIHJlbWFyayBpcyBvbmx5IGVkaXRvcmlhbCBidXQNCgljbGFyaWZpZXMgdGhhdCB0
aGUgRlJHIGJpdHMgYW5kIGNvbnRyb2wgd29yZCBjYW4gYmUgdXNlZCBpbiB0aGVzZSBjYXNlcw0K
CWFzIHdlbGwuDQoJDQoJVGhhbmtzDQoJUm9uDQoJDQoJDQoJDQoJUm9uIENvaGVuDQoJQ1RPDQoJ
THljaXVtIE5ldHdvcmtzDQoJTW9iaWxlOiA2NTAuODIzLjc2NzINCglNb2JpbGU6ICArOTcyLjU1
LjI0NS4xMDQNCglUZWw6ICA2NTAuMjM0LjQwMTANCglGYXg6ICA2NTAuODU0LjgxODMNCgkNCgk9
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KCVRo
aXMgZW1haWwgbWVzc2FnZSBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgY29udGFp
bg0KCWNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciBpdHMgYWRkcmVz
c2VlKHMpLiBJZiB5b3UgYXJlDQoJbm90IHRoZSBhZGRyZXNzZWUgb2YgdGhpcyBtZXNzYWdlLCBh
bnkgcmVhZGluZywgZGlzY2xvc3VyZSwgY29weWluZywNCglwcmludGluZywgZGlzdHJpYnV0aW9u
IG9yIGZvcndhcmRpbmcgYnkgeW91IG9mIHRoaXMgbWVzc2FnZSBvciBpdHMNCgljb250ZW50IG9y
IGF0dGFjaG1lbnRzIGlzIHN0cmljdGx5IGZvcmJpZGRlbi4gSW4gc3VjaCBjYXNlLCBwbGVhc2UN
Cglub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkgcmVwbHlpbmcgdG8gdGhpcyBtZXNzYWdlIG9yIGJ5
IGNhbGxpbmcNCgk2NTAuMjM0LjQwMTAgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBmcm9tIHlvdXIg
Y29tcHV0ZXIuIFRoYW5rIHlvdS4NCgkNCgkNCgkNCg0K


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Yaakov Stein" <yaakov_s@rad.com>
Subject: confusing text in fragmentation draft
Date: Wed, 3 Dec 2003 08:45:38 +0200
Lines: 19
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64
X-From: pwe3-admin@ietf.org Wed Dec 03 07:47:05 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
Thread-Topic: Sequence number text in Fragmentation draft
Thread-Index: AcO5ECk+SfWSzZ1ERSKKHkPhM4gucwAGwkk+AA73CWA=
To: "Andy Malis" <Andy.Malis@tellabs.com>, "PWE3 \(IETF\)" <pwe3@ietf.org>
Content-Transfer-Encoding: base64
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

QW5keSwgDQoNCkkgZmluZCB0aGUgdGV4dCBpbiBkcmFmdC1pZXRmLXB3ZTMtZnJhZ21lbnRhdGlv
bi0wMw0KZGVzY3JpYmluZyB0aGUgc2V0dGluZyBvZiB0aGUgZnJhZ21lbnRhdGlvbiBpbmRpY2F0
aW9uIGJpdHMgDQp0byBiZSBleHRyZW1lbHkgY29uZnVzaW5nLg0KDQpUaGUgYXJjaGl0ZWN0dXJl
IGRyYWZ0IHN0YXRlcyB0aGF0IHRoZSBjb250cm9sIHdvcmQNCnBvdGVudGlhbGx5IGNvbnRhaW5z
IGEgdHdvLWJpdCBmaWVsZCBjYWxsZWQgRlJHLg0KDQpUaGUgZnJhZ21lbnRhdGlvbiBkcmFmdCB0
YWxrcyBhYm91dCB0d28gb25lLWJpdCBmaWVsZHMuDQpGdXJ0aGVybW9yZSwgaXQgZmlyc3QgZXhw
bGFpbnMgdGhlIFJGQyAxOTkwIGNvbnZlbnRpb25zLCANCmJ1dCB0aGVuIGdvZXMgb24gdG8gc2F5
IHdlIGFyZSBpbnZlcnRpbmcgdGhlbS4NCg0KSXQgbmV2ZXIgZXhwbGljaXRseSBzcGVsbHMgb3V0
IHRoZSBtZWFuaW5nIHRoYXQgSVMgdXNlZC4NCg0KQWx0aG91Z2ggSSBhZ3JlZSB0aGF0IHNlbnRp
ZW50IGJlaW5ncyBjb3VsZCBkZWN5cGhlciB0aGlzLA0KYW5kIG1ha2UgdGhlIGNvbm5lY3Rpb24g
YmV0d2VlbiB0aGUgdHdvIDEtYml0IGZpZWxkcw0KYW5kIHRoZSBvbmUgMi1iaXQgZmllbGQgaW4g
YSBmaW5pdGUgYW1vdW50IG9mIHRpbWUsDQpJIHdvdWxkIHByZWZlciBzb21ldGhpbmcgbGlrZSB0
aGlzOg0KDQpGUkcNCjAwCWluZGljYXRlcyB0aGF0IHRoZSBlbnRpcmUgKHVuLWZyYWdtZW50ZWQp
IHBheWxvYWQgaXMgY2FycmllZCBpbiBhIHNpbmdsZSBwYWNrZXQgDQowMQlpbmRpY2F0ZXMgdGhl
IHBhY2tldCBjYXJyeWluZyB0aGUgZmlyc3QgZnJhZ21lbnQNCjEwCWluZGljYXRlcyB0aGUgcGFj
a2V0IGNhcnJ5aW5nIHRoZSBsYXN0IGZyYWdtZW50IA0KMTEJaW5kaWNhdGVzIGEgcGFja2V0IGNh
cnJ5aW5nIGFuIGludGVybWVkaWF0ZSBmcmFnbWVudC4NCg0KDQpZb3UgY291bGQsIG9mIGNvdXJz
ZSwga2VlcCB0aGUgZXhwbGFuYXRvcnkgdGV4dCBhcyB0byB3aHkNCndlIHVzZSB0aGVzZSBwYXJ0
aWN1bGFyIGNvbWJpbmF0aW9ucy4NCg0KWShKKVMNCg==


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Andrew G. Malis" <andy.malis@tellabs.com>
Subject: Re: confusing text in fragmentation draft
Date: Wed, 03 Dec 2003 06:44:48 -0500
Lines: 48
Sender: pwe3-admin@ietf.org
References: <27A0F290348F8E45AEF79889DDE65A5201700E5B@exrad2.ad.rad.co.il> <27A0F290348F8E45AEF79889DDE65A5201700E5B@exrad2.ad.rad.co.
 il>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: "Andy Malis" <Andy.Malis@tellabs.com>, "PWE3 \(IETF\)" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Wed Dec 03 12:46:14 2003
Return-path: <pwe3-admin@ietf.org>
X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1
To: "Yaakov Stein" <yaakov_s@rad.com>
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5201700E5B@exrad2.ad.rad.co.
 il>
References: <27A0F290348F8E45AEF79889DDE65A5201700E5B@exrad2.ad.rad.co.il>
X-OriginalArrivalTime: 03 Dec 2003 11:45:21.0634 (UTC) FILETIME=[EEA01C20:01C3B992]
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Yaakov,

Thanks to you and Ron for reviewing the draft.

I don't see an inconsistency between the architecture draft talking in 
general terms about a two-bit field for fragmentation, and the 
fragmentation draft getting into the details of the individual bits by 
discussing them as two one-bit fields.  That said, I  like your table 
below, and will add it to the next revision.  Thanks for the suggestion.

Cheers,
Andy

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

At 12/3/2003 08:45 AM +0200, Yaakov Stein wrote:
>Andy,
>
>I find the text in draft-ietf-pwe3-fragmentation-03
>describing the setting of the fragmentation indication bits
>to be extremely confusing.
>
>The architecture draft states that the control word
>potentially contains a two-bit field called FRG.
>
>The fragmentation draft talks about two one-bit fields.
>Furthermore, it first explains the RFC 1990 conventions,
>but then goes on to say we are inverting them.
>
>It never explicitly spells out the meaning that IS used.
>
>Although I agree that sentient beings could decypher this,
>and make the connection between the two 1-bit fields
>and the one 2-bit field in a finite amount of time,
>I would prefer something like this:
>
>FRG
>00      indicates that the entire (un-fragmented) payload is carried in a 
>single packet
>01      indicates the packet carrying the first fragment
>10      indicates the packet carrying the last fragment
>11      indicates a packet carrying an intermediate fragment.
>
>
>You could, of course, keep the explanatory text as to why
>we use these particular combinations.
>
>Y(J)S


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: confusing text in fragmentation draft
Date: Wed, 03 Dec 2003 12:17:03 +0000
Organization: Cisco Systems, Inc.
Lines: 50
Sender: pwe3-admin@ietf.org
References: <27A0F290348F8E45AEF79889DDE65A5201700E5B@exrad2.ad.rad.co.il>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: Andy Malis <Andy.Malis@tellabs.com>, "PWE3 (IETF)" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Wed Dec 03 13:18:05 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: Yaakov Stein <yaakov_s@rad.com>
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5201700E5B@exrad2.ad.rad.co.il>
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA12089
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


Actually I think that we should consider simplifying the
whole of section 3 to remove the RFC-1990 tutorial,
and replace it with a direct description of what we
do and why. I think that we should use Yaakov's text
to directly specify the meaning of the bits.

Stewart




Yaakov Stein wrote:

> Andy,=20
>=20
> I find the text in draft-ietf-pwe3-fragmentation-03
> describing the setting of the fragmentation indication bits=20
> to be extremely confusing.
>=20
> The architecture draft states that the control word
> potentially contains a two-bit field called FRG.
>=20
> The fragmentation draft talks about two one-bit fields.
> Furthermore, it first explains the RFC 1990 conventions,=20
> but then goes on to say we are inverting them.
>=20
> It never explicitly spells out the meaning that IS used.
>=20
> Although I agree that sentient beings could decypher this,
> and make the connection between the two 1-bit fields
> and the one 2-bit field in a finite amount of time,
> I would prefer something like this:
>=20
> FRG
> 00	indicates that the entire (un-fragmented) payload is carried in a si=
ngle packet=20
> 01	indicates the packet carrying the first fragment
> 10	indicates the packet carrying the last fragment=20
> 11	indicates a packet carrying an intermediate fragment.
>=20
>=20
> You could, of course, keep the explanatory text as to why
> we use these particular combinations.
>=20
> Y(J)S
> ???????????????????????????????????????j)b?	b??p{=C1=BF?z????!??l????
> ???_????f??f??X??)=DF=A3?p
>=20
>=20


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Andy Malis" <Andy.Malis@tellabs.com>
Subject: RE: confusing text in fragmentation draft
Date: Wed, 3 Dec 2003 04:38:50 -0800
Lines: 41
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
Cc: "PWE3 (IETF)" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Wed Dec 03 13:40:08 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
Thread-Topic: [PWE3] confusing text in fragmentation draft
Thread-Index: AcO5l35e8VnW4BsSSnKXv227qSzn4QAAmQft
To: <stbryant@cisco.com>, "Yaakov Stein" <yaakov_s@rad.com>
Content-Transfer-Encoding: base64
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

U3Rld2FydCwNCiANCllvdSBwcm9iYWJseSBoYXZlbid0IHlldCBzZWVuIG15IHJlcGx5IHRvIFlh
YWtvdi4gIEkgaW50ZW5kIHRvIGFkZCBoaXMgdGFibGUgdG8gdGhlIHRleHQuICBIb3dldmVyLCBJ
IHRoaW5rIHRoZSBkaXNjdXNzaW9uIG9mIFJGQyAxOTkwIGlzIHVzZWZ1bCwgYmVjYXVzZSBpdCBy
ZWZlcmVuY2VzIHRoZSBlYXJsaWVyIHdvcmsgZm9yIHRob3NlIG5vdCBhd2FyZSBvZiBpdCwgYW5k
IGFuc3dlcnMgdGhlIHF1ZXN0aW9uIChzaG91bGQgaXQgYXJpc2UgaW4gdGhlIGZ1dHVyZSBmcm9t
IHBlb3BsZSBhbHJlYWR5IGZhbWlsaWFyIHdpdGggUkZDIDE5OTApIGFzIHRvIHdoeSB0aGUgYml0
cyBhcmUgaW52ZXJ0ZWQuICBUaGVyZSBhcmUgbWFueSBSRkMgMTk5MCBpbXBsZW1lbnRhdGlvbnMs
IGFuZCBJIGV4cGVjdCB0aGlzIGNvdWxkIGVuZCB1cCBiZWluZyBhIHBvcHVsYXIgcXVlc3Rpb24g
eWVhcnMgZnJvbSBub3cgaWYgdGhlIHRleHQgaXMgcmVtb3ZlZC4NCiANCkNoZWVycywNCkFuZHkN
Cg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IFN0ZXdhcnQgQnJ5YW50IFtt
YWlsdG86c3RicnlhbnRAY2lzY28uY29tXSANCglTZW50OiBXZWQgMTIvMy8yMDAzIDc6MTcgQU0g
DQoJVG86IFlhYWtvdiBTdGVpbiANCglDYzogQW5keSBNYWxpczsgUFdFMyAoSUVURikgDQoJU3Vi
amVjdDogUmU6IFtQV0UzXSBjb25mdXNpbmcgdGV4dCBpbiBmcmFnbWVudGF0aW9uIGRyYWZ0DQoJ
DQoJDQoNCg0KCUFjdHVhbGx5IEkgdGhpbmsgdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIgc2ltcGxp
ZnlpbmcgdGhlDQoJd2hvbGUgb2Ygc2VjdGlvbiAzIHRvIHJlbW92ZSB0aGUgUkZDLTE5OTAgdHV0
b3JpYWwsDQoJYW5kIHJlcGxhY2UgaXQgd2l0aCBhIGRpcmVjdCBkZXNjcmlwdGlvbiBvZiB3aGF0
IHdlDQoJZG8gYW5kIHdoeS4gSSB0aGluayB0aGF0IHdlIHNob3VsZCB1c2UgWWFha292J3MgdGV4
dA0KCXRvIGRpcmVjdGx5IHNwZWNpZnkgdGhlIG1lYW5pbmcgb2YgdGhlIGJpdHMuDQoJDQoJU3Rl
d2FydA0KCQ0KCQ0KCQ0KCQ0KCVlhYWtvdiBTdGVpbiB3cm90ZToNCgkNCgk+IEFuZHksDQoJPg0K
CT4gSSBmaW5kIHRoZSB0ZXh0IGluIGRyYWZ0LWlldGYtcHdlMy1mcmFnbWVudGF0aW9uLTAzDQoJ
PiBkZXNjcmliaW5nIHRoZSBzZXR0aW5nIG9mIHRoZSBmcmFnbWVudGF0aW9uIGluZGljYXRpb24g
Yml0cw0KCT4gdG8gYmUgZXh0cmVtZWx5IGNvbmZ1c2luZy4NCgk+DQoJPiBUaGUgYXJjaGl0ZWN0
dXJlIGRyYWZ0IHN0YXRlcyB0aGF0IHRoZSBjb250cm9sIHdvcmQNCgk+IHBvdGVudGlhbGx5IGNv
bnRhaW5zIGEgdHdvLWJpdCBmaWVsZCBjYWxsZWQgRlJHLg0KCT4NCgk+IFRoZSBmcmFnbWVudGF0
aW9uIGRyYWZ0IHRhbGtzIGFib3V0IHR3byBvbmUtYml0IGZpZWxkcy4NCgk+IEZ1cnRoZXJtb3Jl
LCBpdCBmaXJzdCBleHBsYWlucyB0aGUgUkZDIDE5OTAgY29udmVudGlvbnMsDQoJPiBidXQgdGhl
biBnb2VzIG9uIHRvIHNheSB3ZSBhcmUgaW52ZXJ0aW5nIHRoZW0uDQoJPg0KCT4gSXQgbmV2ZXIg
ZXhwbGljaXRseSBzcGVsbHMgb3V0IHRoZSBtZWFuaW5nIHRoYXQgSVMgdXNlZC4NCgk+DQoJPiBB
bHRob3VnaCBJIGFncmVlIHRoYXQgc2VudGllbnQgYmVpbmdzIGNvdWxkIGRlY3lwaGVyIHRoaXMs
DQoJPiBhbmQgbWFrZSB0aGUgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSB0d28gMS1iaXQgZmllbGRz
DQoJPiBhbmQgdGhlIG9uZSAyLWJpdCBmaWVsZCBpbiBhIGZpbml0ZSBhbW91bnQgb2YgdGltZSwN
Cgk+IEkgd291bGQgcHJlZmVyIHNvbWV0aGluZyBsaWtlIHRoaXM6DQoJPg0KCT4gRlJHDQoJPiAw
MCAgICBpbmRpY2F0ZXMgdGhhdCB0aGUgZW50aXJlICh1bi1mcmFnbWVudGVkKSBwYXlsb2FkIGlz
IGNhcnJpZWQgaW4gYSBzaW5nbGUgcGFja2V0DQoJPiAwMSAgICBpbmRpY2F0ZXMgdGhlIHBhY2tl
dCBjYXJyeWluZyB0aGUgZmlyc3QgZnJhZ21lbnQNCgk+IDEwICAgIGluZGljYXRlcyB0aGUgcGFj
a2V0IGNhcnJ5aW5nIHRoZSBsYXN0IGZyYWdtZW50DQoJPiAxMSAgICBpbmRpY2F0ZXMgYSBwYWNr
ZXQgY2FycnlpbmcgYW4gaW50ZXJtZWRpYXRlIGZyYWdtZW50Lg0KCT4NCgk+DQoJPiBZb3UgY291
bGQsIG9mIGNvdXJzZSwga2VlcCB0aGUgZXhwbGFuYXRvcnkgdGV4dCBhcyB0byB3aHkNCgk+IHdl
IHVzZSB0aGVzZSBwYXJ0aWN1bGFyIGNvbWJpbmF0aW9ucy4NCgk+DQoJPiBZKEopUw0KCT4gPz8/
Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/ailiPyAgIGI/P3B7P3o/Pz8/IT8/
bD8/Pz8NCgk+ID8/P18/Pz8/Zj8/Zj8/WD8/Kd+jP3ANCgk+DQoJPg0KCQ0KCQ0KDQo=


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Yaakov Stein" <yaakov_s@rad.com>
Subject: RE: confusing text in fragmentation draft
Date: Wed, 3 Dec 2003 14:40:55 +0200
Lines: 54
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64
Cc: "PWE3 \(IETF\)" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Wed Dec 03 13:42:04 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
Thread-Topic: [PWE3] confusing text in fragmentation draft
Thread-Index: AcO5l35e8VnW4BsSSnKXv227qSzn4QAAmQftAAAbDkA=
To: "Andy Malis" <Andy.Malis@tellabs.com>, <stbryant@cisco.com>
Content-Transfer-Encoding: base64
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

QW5keS9TdGV3YXJ0LCANCg0KSSBhZ3JlZSB0aGF0IHRoZSBleHBsYW5hdGlvbiBvZiBXSFkgdGhl
IGJpdHMNCmFyZSBpbnZlcnRlZCB2aXMgYSB2aXMgMTk5MCBpcyB1c2VmdWwuDQoNCkkganVzdCB0
aGluayB0aGF0IGl0IHNob3VsZCBiZSBhbiBleHBsYW5hdG9yeQ0Kbm90ZSBBRlRFUiBhbiBleHBs
YW5hdGlvbiBvZiB3aGF0IHRoZSBiaXRzIGRvLA0KcmF0aGVyIHRoYW4gYSBjcnlwdGljIGFsZ29y
aXRobSBvZiBob3cNCnRvIGZpZ3VyZSBvdXQgd2hhdCB0aGUgYml0cyBzaG91bGQgYmUuDQoNClko
SilTDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmR5IE1hbGlz
IFttYWlsdG86QW5keS5NYWxpc0B0ZWxsYWJzLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBEZWNl
bWJlciAwMywgMjAwMyAyOjM5IFBNDQo+IFRvOiBzdGJyeWFudEBjaXNjby5jb207IFlhYWtvdiBT
dGVpbg0KPiBDYzogUFdFMyAoSUVURikNCj4gU3ViamVjdDogUkU6IFtQV0UzXSBjb25mdXNpbmcg
dGV4dCBpbiBmcmFnbWVudGF0aW9uIGRyYWZ0DQo+IA0KPiANCj4gU3Rld2FydCwNCj4gIA0KPiBZ
b3UgcHJvYmFibHkgaGF2ZW4ndCB5ZXQgc2VlbiBteSByZXBseSB0byBZYWFrb3YuICBJIGludGVu
ZCANCj4gdG8gYWRkIGhpcyB0YWJsZSB0byB0aGUgdGV4dC4gIEhvd2V2ZXIsIEkgdGhpbmsgdGhl
IA0KPiBkaXNjdXNzaW9uIG9mIFJGQyAxOTkwIGlzIHVzZWZ1bCwgYmVjYXVzZSBpdCByZWZlcmVu
Y2VzIHRoZSANCj4gZWFybGllciB3b3JrIGZvciB0aG9zZSBub3QgYXdhcmUgb2YgaXQsIGFuZCBh
bnN3ZXJzIHRoZSANCj4gcXVlc3Rpb24gKHNob3VsZCBpdCBhcmlzZSBpbiB0aGUgZnV0dXJlIGZy
b20gcGVvcGxlIGFscmVhZHkgDQo+IGZhbWlsaWFyIHdpdGggUkZDIDE5OTApIGFzIHRvIHdoeSB0
aGUgYml0cyBhcmUgaW52ZXJ0ZWQuICANCj4gVGhlcmUgYXJlIG1hbnkgUkZDIDE5OTAgaW1wbGVt
ZW50YXRpb25zLCBhbmQgSSBleHBlY3QgdGhpcyANCj4gY291bGQgZW5kIHVwIGJlaW5nIGEgcG9w
dWxhciBxdWVzdGlvbiB5ZWFycyBmcm9tIG5vdyBpZiB0aGUgDQo+IHRleHQgaXMgcmVtb3ZlZC4N
Cj4gIA0KPiBDaGVlcnMsDQo+IEFuZHkNCj4gDQo+IAktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LSANCj4gCUZyb206IFN0ZXdhcnQgQnJ5YW50IFttYWlsdG86c3RicnlhbnRAY2lzY28uY29tXSAN
Cj4gCVNlbnQ6IFdlZCAxMi8zLzIwMDMgNzoxNyBBTSANCj4gCVRvOiBZYWFrb3YgU3RlaW4gDQo+
IAlDYzogQW5keSBNYWxpczsgUFdFMyAoSUVURikgDQo+IAlTdWJqZWN0OiBSZTogW1BXRTNdIGNv
bmZ1c2luZyB0ZXh0IGluIGZyYWdtZW50YXRpb24gZHJhZnQNCj4gCQ0KPiAJDQo+IA0KPiANCj4g
CUFjdHVhbGx5IEkgdGhpbmsgdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIgc2ltcGxpZnlpbmcgdGhl
DQo+IAl3aG9sZSBvZiBzZWN0aW9uIDMgdG8gcmVtb3ZlIHRoZSBSRkMtMTk5MCB0dXRvcmlhbCwN
Cj4gCWFuZCByZXBsYWNlIGl0IHdpdGggYSBkaXJlY3QgZGVzY3JpcHRpb24gb2Ygd2hhdCB3ZQ0K
PiAJZG8gYW5kIHdoeS4gSSB0aGluayB0aGF0IHdlIHNob3VsZCB1c2UgWWFha292J3MgdGV4dA0K
PiAJdG8gZGlyZWN0bHkgc3BlY2lmeSB0aGUgbWVhbmluZyBvZiB0aGUgYml0cy4NCj4gCQ0KPiAJ
U3Rld2FydA0KPiAJDQo+IAkNCj4gCQ0KPiAJDQo+IAlZYWFrb3YgU3RlaW4gd3JvdGU6DQo+IAkN
Cj4gCT4gQW5keSwNCj4gCT4NCj4gCT4gSSBmaW5kIHRoZSB0ZXh0IGluIGRyYWZ0LWlldGYtcHdl
My1mcmFnbWVudGF0aW9uLTAzDQo+IAk+IGRlc2NyaWJpbmcgdGhlIHNldHRpbmcgb2YgdGhlIGZy
YWdtZW50YXRpb24gaW5kaWNhdGlvbiBiaXRzDQo+IAk+IHRvIGJlIGV4dHJlbWVseSBjb25mdXNp
bmcuDQo+IAk+DQo+IAk+IFRoZSBhcmNoaXRlY3R1cmUgZHJhZnQgc3RhdGVzIHRoYXQgdGhlIGNv
bnRyb2wgd29yZA0KPiAJPiBwb3RlbnRpYWxseSBjb250YWlucyBhIHR3by1iaXQgZmllbGQgY2Fs
bGVkIEZSRy4NCj4gCT4NCj4gCT4gVGhlIGZyYWdtZW50YXRpb24gZHJhZnQgdGFsa3MgYWJvdXQg
dHdvIG9uZS1iaXQgZmllbGRzLg0KPiAJPiBGdXJ0aGVybW9yZSwgaXQgZmlyc3QgZXhwbGFpbnMg
dGhlIFJGQyAxOTkwIGNvbnZlbnRpb25zLA0KPiAJPiBidXQgdGhlbiBnb2VzIG9uIHRvIHNheSB3
ZSBhcmUgaW52ZXJ0aW5nIHRoZW0uDQo+IAk+DQo+IAk+IEl0IG5ldmVyIGV4cGxpY2l0bHkgc3Bl
bGxzIG91dCB0aGUgbWVhbmluZyB0aGF0IElTIHVzZWQuDQo+IAk+DQo+IAk+IEFsdGhvdWdoIEkg
YWdyZWUgdGhhdCBzZW50aWVudCBiZWluZ3MgY291bGQgZGVjeXBoZXIgdGhpcywNCj4gCT4gYW5k
IG1ha2UgdGhlIGNvbm5lY3Rpb24gYmV0d2VlbiB0aGUgdHdvIDEtYml0IGZpZWxkcw0KPiAJPiBh
bmQgdGhlIG9uZSAyLWJpdCBmaWVsZCBpbiBhIGZpbml0ZSBhbW91bnQgb2YgdGltZSwNCj4gCT4g
SSB3b3VsZCBwcmVmZXIgc29tZXRoaW5nIGxpa2UgdGhpczoNCj4gCT4NCj4gCT4gRlJHDQo+IAk+
IDAwICAgIGluZGljYXRlcyB0aGF0IHRoZSBlbnRpcmUgKHVuLWZyYWdtZW50ZWQpIA0KPiBwYXls
b2FkIGlzIGNhcnJpZWQgaW4gYSBzaW5nbGUgcGFja2V0DQo+IAk+IDAxICAgIGluZGljYXRlcyB0
aGUgcGFja2V0IGNhcnJ5aW5nIHRoZSBmaXJzdCBmcmFnbWVudA0KPiAJPiAxMCAgICBpbmRpY2F0
ZXMgdGhlIHBhY2tldCBjYXJyeWluZyB0aGUgbGFzdCBmcmFnbWVudA0KPiAJPiAxMSAgICBpbmRp
Y2F0ZXMgYSBwYWNrZXQgY2FycnlpbmcgYW4gaW50ZXJtZWRpYXRlIGZyYWdtZW50Lg0KPiAJPg0K
PiAJPg0KPiAJPiBZb3UgY291bGQsIG9mIGNvdXJzZSwga2VlcCB0aGUgZXhwbGFuYXRvcnkgdGV4
dCBhcyB0byB3aHkNCj4gCT4gd2UgdXNlIHRoZXNlIHBhcnRpY3VsYXIgY29tYmluYXRpb25zLg0K
PiAJPg0KPiAJPiBZKEopUw0KPiAJPiA/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/
Pz8/Pz9qKWI/ICAgDQo+IGI/P3B7P3o/Pz8/IT8/bD8/Pz8NCj4gCT4gPz8/Xz8/Pz9mPz9mPz9Y
Pz8p36M/cA0KPiAJPg0KPiAJPg0KPiAJDQo+IAkNCj4gDQo+IA0K


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: RE: Sequence number text in Fragmentation draft
Date: Wed, 03 Dec 2003 12:51:41 +0000
Organization: Cisco Systems, Inc.
Lines: 88
Sender: pwe3-admin@ietf.org
References: <6B44697BBC676B4F91546F829A472B8A384F01@po1.vivacenetworks.com>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: Ron Cohen <ronc@lyciumnetworks.com>, "PWE3 (IETF)" <pwe3@ietf.org>,
        Sasha Vainshtein <Sasha@AXERRA.com>
X-From: pwe3-admin@ietf.org Wed Dec 03 13:53:06 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: Andy Malis <Andy.Malis@tellabs.com>
In-Reply-To: <6B44697BBC676B4F91546F829A472B8A384F01@po1.vivacenetworks.com>
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA13178
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



Andy Malis wrote:

> Ron,
> =20
> Thanks, I'll put that into the next revision following WG last call (I'=
ll consider this as a last call comment).  BTW, that's a hint for Danny a=
nd Stewart ... :-)
> =20
> Cheers,
> Andy
>=20

As I indicated, I think that section 3 needs to be simplifed
along the lines proposed by Yaakov. It therefore follows
that we really need another spin before last call.

Your thoughts Danny?

Stewart



> 	-----Original Message-----=20
> 	From: Ron Cohen [mailto:ronc@lyciumnetworks.com]=20
> 	Sent: Tue 12/2/2003 3:03 PM=20
> 	To: PWE3 (IETF); Andy Malis=20
> 	Cc: Sasha Vainshtein=20
> 	Subject: Sequence number text in Fragmentation draft
> =09
> =09
>=20
> 	Hi,
> =09
> 	I have a small remark regarding the text on sequence number in
> 	draft-ietf-pwe3-fragmentation-03
> =09
> 	The current text reads (section 4.1):
> =09
> 	    The Sequence Number is used as already specified in the above
> 	    protocol specifications.  Specifically, since the value 0 indicate=
s
> 	    that the sequence number is not in use, its use for fragmentation
> 	    must follow this same rule - as the sequence number is incremented=
,
> 	    it skips zero and wraps from 65535 to 1.
> =09
> 	I suggest to modify this text to reflect the fact that there are
> 	services (SATOP) that use the entire range of sequence numbers
> 	(including zero) in the control word. This remark is only editorial bu=
t
> 	clarifies that the FRG bits and control word can be used in these case=
s
> 	as well.
> =09
> 	Thanks
> 	Ron
> =09
> =09
> =09
> 	Ron Cohen
> 	CTO
> 	Lycium Networks
> 	Mobile: 650.823.7672
> 	Mobile:  +972.55.245.104
> 	Tel:  650.234.4010
> 	Fax:  650.854.8183
> =09
> 	=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
> 	This email message and any files transmitted with it contain
> 	confidential information intended only for its addressee(s). If you ar=
e
> 	not the addressee of this message, any reading, disclosure, copying,
> 	printing, distribution or forwarding by you of this message or its
> 	content or attachments is strictly forbidden. In such case, please
> 	notify us immediately by replying to this message or by calling
> 	650.234.4010 and delete the message from your computer. Thank you.
> =09
> =09
> =09
>=20
> ???????????????????????????????????????j)b?	b??p{=C1=BF?z????!??l????
> ???_????f??f??X??)=DF=A3?p
>=20
>=20


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Andy Malis" <Andy.Malis@tellabs.com>
Subject: RE: RE: Sequence number text in Fragmentation draft
Date: Wed, 3 Dec 2003 05:04:13 -0800
Lines: 56
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
Cc: "Ron Cohen" <ronc@lyciumnetworks.com>, "PWE3 (IETF)" <pwe3@ietf.org>,
        "Sasha Vainshtein" <Sasha@AXERRA.com>,
        "Andy Malis" <Andy.Malis@tellabs.com>
X-From: pwe3-admin@ietf.org Wed Dec 03 14:05:05 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
Thread-Topic: [PWE3] RE: Sequence number text in Fragmentation draft
Thread-Index: AcO5nEfhfaf0E1ILSF+qcvf6nv6EMgAAWKNf
To: <stbryant@cisco.com>
Content-Transfer-Encoding: base64
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

U3Rld2FydCwNCiANCk9LLCBJJ2xsIGdpdmUgaXQgYW5vdGhlciBjb3VwbGUgb2YgZGF5cyBmb3Ig
YW55IG1vcmUgY29tbWVudHMgb24gdGhlIGN1cnJlbnQgcmV2aXNpb24sIGFuZCB0aGVuIEknbGwg
ZG8gYW5vdGhlciBzcGluIHByb2JhYmx5IG92ZXIgdGhlIHdlZWtlbmQgZm9yIFdHIGxhc3QgY2Fs
bC4NCiANClRoYW5rcywNCkFuZHkNCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZy
b206IFN0ZXdhcnQgQnJ5YW50IFttYWlsdG86c3RicnlhbnRAY2lzY28uY29tXSANCglTZW50OiBX
ZWQgMTIvMy8yMDAzIDc6NTEgQU0gDQoJVG86IEFuZHkgTWFsaXMgDQoJQ2M6IFJvbiBDb2hlbjsg
UFdFMyAoSUVURik7IFNhc2hhIFZhaW5zaHRlaW4gDQoJU3ViamVjdDogUmU6IFtQV0UzXSBSRTog
U2VxdWVuY2UgbnVtYmVyIHRleHQgaW4gRnJhZ21lbnRhdGlvbiBkcmFmdA0KCQ0KCQ0KDQoNCg0K
CUFuZHkgTWFsaXMgd3JvdGU6DQoJDQoJPiBSb24sDQoJPiANCgk+IFRoYW5rcywgSSdsbCBwdXQg
dGhhdCBpbnRvIHRoZSBuZXh0IHJldmlzaW9uIGZvbGxvd2luZyBXRyBsYXN0IGNhbGwgKEknbGwg
Y29uc2lkZXIgdGhpcyBhcyBhIGxhc3QgY2FsbCBjb21tZW50KS4gIEJUVywgdGhhdCdzIGEgaGlu
dCBmb3IgRGFubnkgYW5kIFN0ZXdhcnQgLi4uIDotKQ0KCT4gDQoJPiBDaGVlcnMsDQoJPiBBbmR5
DQoJPg0KCQ0KCUFzIEkgaW5kaWNhdGVkLCBJIHRoaW5rIHRoYXQgc2VjdGlvbiAzIG5lZWRzIHRv
IGJlIHNpbXBsaWZlZA0KCWFsb25nIHRoZSBsaW5lcyBwcm9wb3NlZCBieSBZYWFrb3YuIEl0IHRo
ZXJlZm9yZSBmb2xsb3dzDQoJdGhhdCB3ZSByZWFsbHkgbmVlZCBhbm90aGVyIHNwaW4gYmVmb3Jl
IGxhc3QgY2FsbC4NCgkNCglZb3VyIHRob3VnaHRzIERhbm55Pw0KCQ0KCVN0ZXdhcnQNCgkNCgkN
CgkNCgk+ICAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiAgICAgICBGcm9tOiBS
b24gQ29oZW4gW21haWx0bzpyb25jQGx5Y2l1bW5ldHdvcmtzLmNvbV0NCgk+ICAgICAgIFNlbnQ6
IFR1ZSAxMi8yLzIwMDMgMzowMyBQTQ0KCT4gICAgICAgVG86IFBXRTMgKElFVEYpOyBBbmR5IE1h
bGlzDQoJPiAgICAgICBDYzogU2FzaGEgVmFpbnNodGVpbg0KCT4gICAgICAgU3ViamVjdDogU2Vx
dWVuY2UgbnVtYmVyIHRleHQgaW4gRnJhZ21lbnRhdGlvbiBkcmFmdA0KCT4gICAgICANCgk+ICAg
ICAgDQoJPg0KCT4gICAgICAgSGksDQoJPiAgICAgIA0KCT4gICAgICAgSSBoYXZlIGEgc21hbGwg
cmVtYXJrIHJlZ2FyZGluZyB0aGUgdGV4dCBvbiBzZXF1ZW5jZSBudW1iZXIgaW4NCgk+ICAgICAg
IGRyYWZ0LWlldGYtcHdlMy1mcmFnbWVudGF0aW9uLTAzDQoJPiAgICAgIA0KCT4gICAgICAgVGhl
IGN1cnJlbnQgdGV4dCByZWFkcyAoc2VjdGlvbiA0LjEpOg0KCT4gICAgICANCgk+ICAgICAgICAg
ICBUaGUgU2VxdWVuY2UgTnVtYmVyIGlzIHVzZWQgYXMgYWxyZWFkeSBzcGVjaWZpZWQgaW4gdGhl
IGFib3ZlDQoJPiAgICAgICAgICAgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMuICBTcGVjaWZpY2Fs
bHksIHNpbmNlIHRoZSB2YWx1ZSAwIGluZGljYXRlcw0KCT4gICAgICAgICAgIHRoYXQgdGhlIHNl
cXVlbmNlIG51bWJlciBpcyBub3QgaW4gdXNlLCBpdHMgdXNlIGZvciBmcmFnbWVudGF0aW9uDQoJ
PiAgICAgICAgICAgbXVzdCBmb2xsb3cgdGhpcyBzYW1lIHJ1bGUgLSBhcyB0aGUgc2VxdWVuY2Ug
bnVtYmVyIGlzIGluY3JlbWVudGVkLA0KCT4gICAgICAgICAgIGl0IHNraXBzIHplcm8gYW5kIHdy
YXBzIGZyb20gNjU1MzUgdG8gMS4NCgk+ICAgICAgDQoJPiAgICAgICBJIHN1Z2dlc3QgdG8gbW9k
aWZ5IHRoaXMgdGV4dCB0byByZWZsZWN0IHRoZSBmYWN0IHRoYXQgdGhlcmUgYXJlDQoJPiAgICAg
ICBzZXJ2aWNlcyAoU0FUT1ApIHRoYXQgdXNlIHRoZSBlbnRpcmUgcmFuZ2Ugb2Ygc2VxdWVuY2Ug
bnVtYmVycw0KCT4gICAgICAgKGluY2x1ZGluZyB6ZXJvKSBpbiB0aGUgY29udHJvbCB3b3JkLiBU
aGlzIHJlbWFyayBpcyBvbmx5IGVkaXRvcmlhbCBidXQNCgk+ICAgICAgIGNsYXJpZmllcyB0aGF0
IHRoZSBGUkcgYml0cyBhbmQgY29udHJvbCB3b3JkIGNhbiBiZSB1c2VkIGluIHRoZXNlIGNhc2Vz
DQoJPiAgICAgICBhcyB3ZWxsLg0KCT4gICAgICANCgk+ICAgICAgIFRoYW5rcw0KCT4gICAgICAg
Um9uDQoJPiAgICAgIA0KCT4gICAgICANCgk+ICAgICAgDQoJPiAgICAgICBSb24gQ29oZW4NCgk+
ICAgICAgIENUTw0KCT4gICAgICAgTHljaXVtIE5ldHdvcmtzDQoJPiAgICAgICBNb2JpbGU6IDY1
MC44MjMuNzY3Mg0KCT4gICAgICAgTW9iaWxlOiAgKzk3Mi41NS4yNDUuMTA0DQoJPiAgICAgICBU
ZWw6ICA2NTAuMjM0LjQwMTANCgk+ICAgICAgIEZheDogIDY1MC44NTQuODE4Mw0KCT4gICAgICAN
Cgk+ICAgICAgID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09DQoJPiAgICAgICBUaGlzIGVtYWlsIG1lc3NhZ2UgYW5kIGFueSBmaWxlcyB0cmFuc21p
dHRlZCB3aXRoIGl0IGNvbnRhaW4NCgk+ICAgICAgIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBp
bnRlbmRlZCBvbmx5IGZvciBpdHMgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlDQoJPiAgICAgICBu
b3QgdGhlIGFkZHJlc3NlZSBvZiB0aGlzIG1lc3NhZ2UsIGFueSByZWFkaW5nLCBkaXNjbG9zdXJl
LCBjb3B5aW5nLA0KCT4gICAgICAgcHJpbnRpbmcsIGRpc3RyaWJ1dGlvbiBvciBmb3J3YXJkaW5n
IGJ5IHlvdSBvZiB0aGlzIG1lc3NhZ2Ugb3IgaXRzDQoJPiAgICAgICBjb250ZW50IG9yIGF0dGFj
aG1lbnRzIGlzIHN0cmljdGx5IGZvcmJpZGRlbi4gSW4gc3VjaCBjYXNlLCBwbGVhc2UNCgk+ICAg
ICAgIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSByZXBseWluZyB0byB0aGlzIG1lc3NhZ2Ugb3Ig
YnkgY2FsbGluZw0KCT4gICAgICAgNjUwLjIzNC40MDEwIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2Ug
ZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoJPiAgICAgIA0KCT4gICAgICANCgk+ICAg
ICAgDQoJPg0KCT4gPz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/ailiPyAg
IGI/P3B7P3o/Pz8/IT8/bD8/Pz8NCgk+ID8/P18/Pz8/Zj8/Zj8/WD8/Kd+jP3ANCgk+DQoJPg0K
CQ0KCQ0KDQo=


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 03 Dec 2003 13:10:04 +0000
Organization: Cisco Systems, Inc.
Lines: 75
Sender: pwe3-admin@ietf.org
References: <200312022129.hB2LTIX91395@merlot.juniper.net>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Rahul Aggarwal <rahul@juniper.net>, Luca Martini <lmartini@cisco.com>,
        Kireeti Kompella <kireeti@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 03 14:11:04 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: Yakov Rekhter <yakov@juniper.net>
In-Reply-To: <200312022129.hB2LTIX91395@merlot.juniper.net>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



Yakov Rekhter wrote:

> Stewart,
> 
> 
>>Rahul Aggarwal wrote:
>>
>>
>>>Hi Luca,
>>>
>>>How about:
>>>
>>>1. >From the current draft-ietf-pwe3-control-protocol-:
>>>
>>>   In the protocol specified herein, the pseudowire demultiplexor field
>>>   is an MPLS label.  Thus the packets which are transmitted from one
>>>   end of the pseudowire to the other are MPLS packets.  Unless the
>>>   pseudowire endpoints are immediately adjacent, these MPLS packets
>>>   must be transmitted through a PSN tunnel.  Any sort of PSN tunnel can
>>>   be used, as long as it is possible to transmit MPLS packets through
>>>   it.  The PSN tunnel can itself be an LSP, but it could equally well
>>>   be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
>>>   tunnel which can carry MPLS packets. Procedures for setting up and
>>>   maintaining the PSN tunnels are outside the scope of this document.
>>>
>>>Can we replace the last sentence in the above with the following:
>>>
>>>   Procedures for setting up and maintaining the PSN tunnels with GRE
>>>   or IP are specified in [MPLS-OVER-IP-GRE].
>>
>>The new text is prescriptive about MPLS-OVER-IP-GRE being THE method.
> 
> 
> Let's look at the proposed text again:
> 
>      Procedures for setting up and maintaining the PSN tunnels with GRE
>      or IP are specified in [MPLS-OVER-IP-GRE].
> 
> The new text is prescriptive about MPLS-OVER-IP-GRE being THE method,
> *but only* when the tunnel is GRE or IP.
> 
> On the other hand, the new text is *not* prescriptive about MPLS-OVER-IP-GRE
> being the only way to carry MPLS packets through non-MPLS IP networks.
> 
> 
>>Do we have WG concensus for that?
> 
> 
> In view of the above could you please be more specific about what
> do you mean by "that".
> 

Yakov

What I said last time was :

"The new text is prescriptive about MPLS-OVER-IP-GRE being THE method.
Do we have WG consensus for that?"

Which I took to mean:

"Do we have WG consensus to make MPLS-OVER-IP-GRE the method
for carrying PW over ((IP) or (GRE over IP))"

The use of the term IP in this context is a little confusing
because we mean "IP without transport or other adaptation layer"
(IPsec and L2TP both run over IP).

Looking at the responses to the thread, I detect that there
is consensus for leaving the text as it is, but note
that we need to give others time to respond.

Stewart


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: confusing text in fragmentation draft
Date: Wed, 03 Dec 2003 13:17:10 +0000
Organization: Cisco Systems, Inc.
Lines: 94
Sender: pwe3-admin@ietf.org
References: <6B44697BBC676B4F91546F829A472B8A384F03@po1.vivacenetworks.com>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: Yaakov Stein <yaakov_s@rad.com>, "PWE3 (IETF)" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Wed Dec 03 14:18:04 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: Andy Malis <Andy.Malis@tellabs.com>
In-Reply-To: <6B44697BBC676B4F91546F829A472B8A384F03@po1.vivacenetworks.com>
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA13782
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



Andy Malis wrote:

> Stewart,
> =20
> You probably haven't yet seen my reply to Yaakov. =20
> I intend to add his table to the text.  However,=20
> I think the discussion of RFC 1990 is useful,=20
> because it references the earlier work for those=20
> not aware of it, and answers the question=20
> (should it arise in the future from people=20
> already familiar with RFC 1990) as to why the=20
> bits are inverted.  There are many RFC 1990=20
> implementations, and I expect this could end up=20
> being a popular question years from now if the text is removed.

Yes we did cross-over.

I would still ask that we look at simplifying the
section to make it more readable for someone who
just wants to know how PW fragmentation works.
Perhaps this could be dome by moving the RFC1990
discussion to an appendix?

Stewart


> =20
> Cheers,
> Andy
>=20
> 	-----Original Message-----=20
> 	From: Stewart Bryant [mailto:stbryant@cisco.com]=20
> 	Sent: Wed 12/3/2003 7:17 AM=20
> 	To: Yaakov Stein=20
> 	Cc: Andy Malis; PWE3 (IETF)=20
> 	Subject: Re: [PWE3] confusing text in fragmentation draft
> =09
> =09
>=20
>=20
> 	Actually I think that we should consider simplifying the
> 	whole of section 3 to remove the RFC-1990 tutorial,
> 	and replace it with a direct description of what we
> 	do and why. I think that we should use Yaakov's text
> 	to directly specify the meaning of the bits.
> =09
> 	Stewart
> =09
> =09
> =09
> =09
> 	Yaakov Stein wrote:
> =09
> 	> Andy,
> 	>
> 	> I find the text in draft-ietf-pwe3-fragmentation-03
> 	> describing the setting of the fragmentation indication bits
> 	> to be extremely confusing.
> 	>
> 	> The architecture draft states that the control word
> 	> potentially contains a two-bit field called FRG.
> 	>
> 	> The fragmentation draft talks about two one-bit fields.
> 	> Furthermore, it first explains the RFC 1990 conventions,
> 	> but then goes on to say we are inverting them.
> 	>
> 	> It never explicitly spells out the meaning that IS used.
> 	>
> 	> Although I agree that sentient beings could decypher this,
> 	> and make the connection between the two 1-bit fields
> 	> and the one 2-bit field in a finite amount of time,
> 	> I would prefer something like this:
> 	>
> 	> FRG
> 	> 00    indicates that the entire (un-fragmented) payload is carried i=
n a single packet
> 	> 01    indicates the packet carrying the first fragment
> 	> 10    indicates the packet carrying the last fragment
> 	> 11    indicates a packet carrying an intermediate fragment.
> 	>
> 	>
> 	> You could, of course, keep the explanatory text as to why
> 	> we use these particular combinations.
> 	>
> 	> Y(J)S
> 	> ???????????????????????????????????????j)b?   b??p{?z????!??l????
> 	> ???_????f??f??X??)=DF=A3?p
> 	>
> 	>
> =09
> =09
>=20


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Luca Martini <lmartini@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 03 Dec 2003 07:51:26 -0700
Organization: Cisco Systems
Lines: 104
Sender: pwe3-admin@ietf.org
References: <200312022129.hB2LTIX91395@merlot.juniper.net> <3FCDE0AC.4030206@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Yakov Rekhter <yakov@juniper.net>, Rahul Aggarwal <rahul@juniper.net>,
        Kireeti Kompella <kireeti@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 03 15:53:07 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
To: stbryant@cisco.com
In-Reply-To: <3FCDE0AC.4030206@cisco.com>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Yakov,

I see here two problems. the first is that we need to transport MPLS 
over IP/GRE/IPSEC/L2TPV3, and this is is a useful problem to work on.
The second is this particular section of text in the control draft. The 
proposed text is not enought to solve the first problem , and solving 
the MPLS over IP problem is not what this draft is about.
The draft already suggests that PW can be used over MPLS over IP or 
something else , and it's enought.
So I would like to leave this text as is, and solve the MPLS over 
"IPsomething" problem in a separate document. We can probably get all 
this done by the next IETF meeting. ;-)

Luca


Stewart Bryant wrote:

>
>
> Yakov Rekhter wrote:
>
>> Stewart,
>>
>>
>>> Rahul Aggarwal wrote:
>>>
>>>
>>>> Hi Luca,
>>>>
>>>> How about:
>>>>
>>>> 1. >From the current draft-ietf-pwe3-control-protocol-:
>>>>
>>>>   In the protocol specified herein, the pseudowire demultiplexor field
>>>>   is an MPLS label.  Thus the packets which are transmitted from one
>>>>   end of the pseudowire to the other are MPLS packets.  Unless the
>>>>   pseudowire endpoints are immediately adjacent, these MPLS packets
>>>>   must be transmitted through a PSN tunnel.  Any sort of PSN tunnel 
>>>> can
>>>>   be used, as long as it is possible to transmit MPLS packets through
>>>>   it.  The PSN tunnel can itself be an LSP, but it could equally well
>>>>   be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
>>>>   tunnel which can carry MPLS packets. Procedures for setting up and
>>>>   maintaining the PSN tunnels are outside the scope of this document.
>>>>
>>>> Can we replace the last sentence in the above with the following:
>>>>
>>>>   Procedures for setting up and maintaining the PSN tunnels with GRE
>>>>   or IP are specified in [MPLS-OVER-IP-GRE].
>>>
>>>
>>> The new text is prescriptive about MPLS-OVER-IP-GRE being THE method.
>>
>>
>>
>> Let's look at the proposed text again:
>>
>>      Procedures for setting up and maintaining the PSN tunnels with GRE
>>      or IP are specified in [MPLS-OVER-IP-GRE].
>>
>> The new text is prescriptive about MPLS-OVER-IP-GRE being THE method,
>> *but only* when the tunnel is GRE or IP.
>>
>> On the other hand, the new text is *not* prescriptive about 
>> MPLS-OVER-IP-GRE
>> being the only way to carry MPLS packets through non-MPLS IP networks.
>>
>>
>>> Do we have WG concensus for that?
>>
>>
>>
>> In view of the above could you please be more specific about what
>> do you mean by "that".
>>
>
> Yakov
>
> What I said last time was :
>
> "The new text is prescriptive about MPLS-OVER-IP-GRE being THE method.
> Do we have WG consensus for that?"
>
> Which I took to mean:
>
> "Do we have WG consensus to make MPLS-OVER-IP-GRE the method
> for carrying PW over ((IP) or (GRE over IP))"
>
> The use of the term IP in this context is a little confusing
> because we mean "IP without transport or other adaptation layer"
> (IPsec and L2TP both run over IP).
>
> Looking at the responses to the thread, I detect that there
> is consensus for leaving the text as it is, but note
> that we need to give others time to respond.
>
> Stewart
>
>
>
>
>
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Sasha Vainshtein <Sasha@AXERRA.com>
Subject: RE: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control
	-protocol-04.txt
Date: Wed, 3 Dec 2003 16:44:52 +0200
Lines: 130
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-8"
Cc: Rahul Aggarwal <rahul@juniper.net>, Luca Martini <lmartini@cisco.com>,
        Kireeti Kompella <kireeti@juniper.net>,
        "W. Mark Townsley"
	 <townsley@cisco.com>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org,
        Yakov Rekhter <yakov@juniper.net>
X-From: pwe3-admin@ietf.org Wed Dec 03 16:28:08 2003
Return-path: <pwe3-admin@ietf.org>
To: "'stbryant@cisco.com'" <stbryant@cisco.com>
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Stewart and all,

Since you are giving "others" time to respond:

I also think that the relevant text in 
draft-ietf-pwe3-control-protocol-04.txt 
should remain "as is".

My 2c.

With best regards,
                                   Sasha Vainshtein
email:     sasha@axerra.com <mailto:sasha@axerra.com> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)
 


> -----Original Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com]
> Sent: Wednesday, December 03, 2003 3:10 PM
> To: Yakov Rekhter
> Cc: Rahul Aggarwal; Luca Martini; Kireeti Kompella; W. Mark 
> Townsley; Eric Rosen (erosen); pwe3@ietf.org
> Subject: Re: [PWE3] Re: MPLS PWs over IP: Text for 
> draft-ietf-pwe3-control-protocol-04.txt
> 
> 
> 
> 
> Yakov Rekhter wrote:
> 
> > Stewart,
> > 
> > 
> >>Rahul Aggarwal wrote:
> >>
> >>
> >>>Hi Luca,
> >>>
> >>>How about:
> >>>
> >>>1. >From the current draft-ietf-pwe3-control-protocol-:
> >>>
> >>>   In the protocol specified herein, the pseudowire 
> demultiplexor field
> >>>   is an MPLS label.  Thus the packets which are 
> transmitted from one
> >>>   end of the pseudowire to the other are MPLS packets.  Unless the
> >>>   pseudowire endpoints are immediately adjacent, these 
> MPLS packets
> >>>   must be transmitted through a PSN tunnel.  Any sort of 
> PSN tunnel can
> >>>   be used, as long as it is possible to transmit MPLS 
> packets through
> >>>   it.  The PSN tunnel can itself be an LSP, but it could 
> equally well
> >>>   be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any 
> other sort of
> >>>   tunnel which can carry MPLS packets. Procedures for 
> setting up and
> >>>   maintaining the PSN tunnels are outside the scope of 
> this document.
> >>>
> >>>Can we replace the last sentence in the above with the following:
> >>>
> >>>   Procedures for setting up and maintaining the PSN 
> tunnels with GRE
> >>>   or IP are specified in [MPLS-OVER-IP-GRE].
> >>
> >>The new text is prescriptive about MPLS-OVER-IP-GRE being 
> THE method.
> > 
> > 
> > Let's look at the proposed text again:
> > 
> >      Procedures for setting up and maintaining the PSN 
> tunnels with GRE
> >      or IP are specified in [MPLS-OVER-IP-GRE].
> > 
> > The new text is prescriptive about MPLS-OVER-IP-GRE being 
> THE method,
> > *but only* when the tunnel is GRE or IP.
> > 
> > On the other hand, the new text is *not* prescriptive about 
> MPLS-OVER-IP-GRE
> > being the only way to carry MPLS packets through non-MPLS 
> IP networks.
> > 
> > 
> >>Do we have WG concensus for that?
> > 
> > 
> > In view of the above could you please be more specific about what
> > do you mean by "that".
> > 
> 
> Yakov
> 
> What I said last time was :
> 
> "The new text is prescriptive about MPLS-OVER-IP-GRE being THE method.
> Do we have WG consensus for that?"
> 
> Which I took to mean:
> 
> "Do we have WG consensus to make MPLS-OVER-IP-GRE the method
> for carrying PW over ((IP) or (GRE over IP))"
> 
> The use of the term IP in this context is a little confusing
> because we mean "IP without transport or other adaptation layer"
> (IPsec and L2TP both run over IP).
> 
> Looking at the responses to the thread, I detect that there
> is consensus for leaving the text as it is, but note
> that we need to give others time to respond.
> 
> Stewart
> 
> 
> 
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Yaakov Stein" <yaakov_s@rad.com>
Subject: RE: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 3 Dec 2003 18:37:17 +0200
Lines: 25
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-8"
Content-Transfer-Encoding: quoted-printable
Cc: "Rahul Aggarwal" <rahul@juniper.net>, "Luca Martini" <lmartini@cisco.com>,
        "Kireeti Kompella" <kireeti@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Eric Rosen \(erosen\)" <erosen@cisco.com>,
        "Yakov Rekhter" <yakov@juniper.net>
X-From: pwe3-admin@ietf.org Wed Dec 03 17:38:11 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
Thread-Topic: [PWE3] Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Thread-Index: AcO5sieCnifabVadRRe5JbADuU8nrQAB021g
To: <stbryant@cisco.com>, <pwe3@ietf.org>
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Stewart and all,=20

There seem to be two anomalies regarding MPLS over IP PWs:

1) The PWE charter states that we need an encapsulation document
   for "MPLS (over IP or L2TP only)"
   but also states
   "PWE3 pseudo wires will have the same specification
   for all underlying PSNs (i.e. there will not be specific adaptation
   of a pseudo wire technology for MPLS that is distinct from what is
   used for IP and L2TP).
   These requirements seem mutually contradictory.

2) We have an agreed upon PW multiplexing method
   for MPLS PWs, but not for IP PWs.
   (This one applies to all IP PWs, not just MPLS ones).

However, I do not believe that specifying procedures
only for the GRE case is what we need here.

We should either start treating all the IP varieties separately=20
(i.e. specify L2TP-IP PWs, IPSec PWs, GRE PWs, etc)
or leave the text as it is.

Y(J)S


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Yakov Rekhter <yakov@juniper.net>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 03 Dec 2003 12:09:12 -0800
Lines: 42
Sender: pwe3-admin@ietf.org
References: <3FCDF86E.6080200@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: stbryant@cisco.com, Rahul Aggarwal <rahul@juniper.net>,
        Kireeti Kompella <kireeti@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 03 21:11:30 2003
Return-path: <pwe3-admin@ietf.org>
To: Luca Martini <lmartini@cisco.com>
In-Reply-To: Your message of "Wed, 03 Dec 2003 07:51:26 MST."
             <3FCDF86E.6080200@cisco.com> 
Content-ID: <12171.1070482152.1@juniper.net>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Luca,

> Yakov,
> 
> I see here two problems. the first is that we need to transport MPLS 
> over IP/GRE/IPSEC/L2TPV3, and this is is a useful problem to work on.

Let's not re-invent the wheel - there is no need "to work on" the problem 
of how to transport MPLS over IP/GRE, as it is a *solved* problem 
(draft-ietf-mpls-in-ip-or-gre-03.txt).

> The second is this particular section of text in the control draft. The 
> proposed text is not enought to solve the first problem , and solving 
> the MPLS over IP problem is not what this draft is about.

Here is the proposed text:

  Procedures for setting up and maintaining the PSN tunnels with GRE
  or IP are specified in [MPLS-OVER-IP-GRE].

You are certainly correct that the proposed text "is not enough to
solve the first problem" - it just points to the IETF document that
does solve the first problem (or to be more precise the subset of the
first problem). So, what's wrong with that ?

And I certainly agree with you that "solving the MPLS over IP problem
is not what this draft is about".

> The draft already suggests that PW can be used over MPLS over IP or 
> something else, and it's enought.

Disagree on "it's enough". Since the draft talks about MPLS over
IP/GRE and there is an existing IETF solution on how to transport
MPLS over IP/GRE, the draft should reference it.

> So I would like to leave this text as is, and solve the MPLS over 
> "IPsomething" problem in a separate document. We can probably get all 
> this done by the next IETF meeting. ;-)

So, I hope you would support Rahul's (separate) draft on MPLS over IPSec.

Yakov.


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "W. Mark Townsley" <townsley@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 03 Dec 2003 21:55:32 +0100
Lines: 16
Sender: pwe3-admin@ietf.org
References: <200312032009.hB3K9CX93427@merlot.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Luca Martini <lmartini@cisco.com>, stbryant@cisco.com,
        Rahul Aggarwal <rahul@juniper.net>,
        Kireeti Kompella <kireeti@juniper.net>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 03 21:57:53 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
To: Yakov Rekhter <yakov@juniper.net>
In-Reply-To: <200312032009.hB3K9CX93427@merlot.juniper.net>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


Yakov Rekhter wrote:
> 
> Here is the proposed text:
> 
>   Procedures for setting up and maintaining the PSN tunnels with GRE
>   or IP are specified in [MPLS-OVER-IP-GRE].

Rahul's proposal was also to remove this text:

"Procedures for setting up and maintaining the PSN tunnels are outside the scope 
of this document."

Which is why I said the proposal changes the scope of the document.

- Mark


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Rahul Aggarwal <rahul@juniper.net>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 3 Dec 2003 15:45:48 -0800 (PST)
Lines: 49
Sender: pwe3-admin@ietf.org
References: <200312032009.hB3K9CX93427@merlot.juniper.net> <3FCE4DC4.9020101@cisco.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Yakov Rekhter <yakov@juniper.net>, Luca Martini <lmartini@cisco.com>,
        "" <stbryant@cisco.com>, Kireeti Kompella <kireeti@juniper.net>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, "" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Thu Dec 04 00:48:12 2003
Return-path: <pwe3-admin@ietf.org>
X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs
To: "W. Mark Townsley" <townsley@cisco.com>
In-Reply-To: <3FCE4DC4.9020101@cisco.com>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


Hi Mark,

On Wed, 3 Dec 2003, W. Mark Townsley wrote:

>
> Yakov Rekhter wrote:
> >
> > Here is the proposed text:
> >
> >   Procedures for setting up and maintaining the PSN tunnels with GRE
> >   or IP are specified in [MPLS-OVER-IP-GRE].
>
> Rahul's proposal was also to remove this text:
>
> "Procedures for setting up and maintaining the PSN tunnels are outside the scope
> of this document."
>
> Which is why I said the proposal changes the scope of the document.
>

How about replacing

   The PSN tunnel can itself be an LSP, but it could equally well
   be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
   tunnel which can carry MPLS packets. Procedures for setting up and
   maintaining the PSN tunnels are outside the scope of this document.

with

   The PSN tunnel can itself be an LSP, but it could equally well
   be an IP tunnel [MPLS-OVER-IP-GRE], a GRE tunnel [MPLS-OVER-IP-GRE],
   an IPsec tunnel, or any other sort of tunnel which can carry MPLS
   packets. Procedures for setting up and maintaining the PSN tunnels
   are outside the scope of this document.


Thanks,
rahul

> - Mark
>
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Andrew G. Malis" <andy.malis@tellabs.com>
Subject: Re: confusing text in fragmentation draft
Date: Thu, 04 Dec 2003 07:12:03 -0500
Lines: 18
Sender: pwe3-admin@ietf.org
References: <6B44697BBC676B4F91546F829A472B8A384F03@po1.vivacenetworks.com>
 <3FCDE256.105@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: "Andrew G. Malis" <andy.malis@tellabs.com>,
        Yaakov Stein <yaakov_s@rad.com>, "PWE3 (IETF)" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Thu Dec 04 13:14:05 2003
Return-path: <pwe3-admin@ietf.org>
X-Sender: (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1
To: stbryant@cisco.com
In-Reply-To: <3FCDE256.105@cisco.com>
References: <6B44697BBC676B4F91546F829A472B8A384F03@po1.vivacenetworks.com>
 <3FCDE256.105@cisco.com>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Stewart,

OK, I hear you ....

Cheers,
Andy

--------

At 12/3/2003 01:17 PM +0000, Stewart Bryant wrote:

>I would still ask that we look at simplifying the
>section to make it more readable for someone who
>just wants to know how PW fragmentation works.
>Perhaps this could be dome by moving the RFC1990
>discussion to an appendix?
>
>Stewart


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "W. Mark Townsley" <townsley@cisco.com>
Subject: Re: confusing text in fragmentation draft
Date: Thu, 04 Dec 2003 18:19:11 +0100
Lines: 34
Sender: pwe3-admin@ietf.org
References: <6B44697BBC676B4F91546F829A472B8A384F03@po1.vivacenetworks.com> <3FCDE256.105@cisco.com> <6.0.1.1.2.20031204071056.02d22d08@mail.comcast.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stbryant@cisco.com, Yaakov Stein <yaakov_s@rad.com>,
        "PWE3 (IETF)" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Thu Dec 04 18:20:12 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
To: "Andrew G. Malis" <andy.malis@tellabs.com>
In-Reply-To: <6.0.1.1.2.20031204071056.02d22d08@mail.comcast.net>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


An appendix for 1990 sounds like a good idea to me.

Thanks,

- Mark

Andrew G. Malis wrote:
> Stewart,
> 
> OK, I hear you ....
> 
> Cheers,
> Andy
> 
> --------
> 
> At 12/3/2003 01:17 PM +0000, Stewart Bryant wrote:
> 
>> I would still ask that we look at simplifying the
>> section to make it more readable for someone who
>> just wants to know how PW fragmentation works.
>> Perhaps this could be dome by moving the RFC1990
>> discussion to an appendix?
>>
>> Stewart
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "W. Mark Townsley" <townsley@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Thu, 04 Dec 2003 18:36:13 +0100
Lines: 72
Sender: pwe3-admin@ietf.org
References: <200312032009.hB3K9CX93427@merlot.juniper.net> <3FCE4DC4.9020101@cisco.com> <20031203154500.I70999@sapphire.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Yakov Rekhter <yakov@juniper.net>, Luca Martini <lmartini@cisco.com>,
        stbryant@cisco.com, Kireeti Kompella <kireeti@juniper.net>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Thu Dec 04 18:38:07 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
To: Rahul Aggarwal <rahul@juniper.net>
In-Reply-To: <20031203154500.I70999@sapphire.juniper.net>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


Rahul Aggarwal wrote:
> Hi Mark,
> 
> On Wed, 3 Dec 2003, W. Mark Townsley wrote:
> 
> 
>>Yakov Rekhter wrote:
>>
>>>Here is the proposed text:
>>>
>>>  Procedures for setting up and maintaining the PSN tunnels with GRE
>>>  or IP are specified in [MPLS-OVER-IP-GRE].
>>
>>Rahul's proposal was also to remove this text:
>>
>>"Procedures for setting up and maintaining the PSN tunnels are outside the scope
>>of this document."
>>
>>Which is why I said the proposal changes the scope of the document.
>>
> 
> 
> How about replacing
> 
>    The PSN tunnel can itself be an LSP, but it could equally well
>    be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
>    tunnel which can carry MPLS packets. Procedures for setting up and
>    maintaining the PSN tunnels are outside the scope of this document.
> 
> with
> 
>    The PSN tunnel can itself be an LSP, but it could equally well
>    be an IP tunnel [MPLS-OVER-IP-GRE], a GRE tunnel [MPLS-OVER-IP-GRE],
>    an IPsec tunnel, or any other sort of tunnel which can carry MPLS
>    packets. Procedures for setting up and maintaining the PSN tunnels
>    are outside the scope of this document.

Better. However, *if* we are going to hit the text here turn what was a set of 
loose and unbounded examples into a list of specific references, I'd like to go 
ahead and add L2TPv3 as an example of "any other sort of tunnel which can carry 
MPLS packets" and include a reference to draft-townsley-l2tpv3-mpls-01.txt. For 
consistency, we would need to reference your upcoming MPLS over IPsec 
encapsulation draft as well. I find it arbitrary to reference some examples and 
not others.

I'm also fine with just leaving the text as is.

- Mark

> 
> 
> Thanks,
> rahul
> 
> 
>>- Mark
>>
>>
>>
>>_______________________________________________
>>pwe3 mailing list
>>pwe3@ietf.org
>>https://www1.ietf.org/mailman/listinfo/pwe3
>>
> 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Thu, 04 Dec 2003 18:13:13 +0000
Organization: Cisco Systems, Inc.
Lines: 101
Sender: pwe3-admin@ietf.org
References: <200312032009.hB3K9CX93427@merlot.juniper.net> <3FCE4DC4.9020101@cisco.com> <20031203154500.I70999@sapphire.juniper.net> <3FCF708D.4000209@cisco.com>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Rahul Aggarwal <rahul@juniper.net>, Yakov Rekhter <yakov@juniper.net>,
        Luca Martini <lmartini@cisco.com>,
        Kireeti Kompella <kireeti@juniper.net>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Thu Dec 04 20:22:14 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: "W. Mark Townsley" <townsley@cisco.com>
In-Reply-To: <3FCF708D.4000209@cisco.com>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



W. Mark Townsley wrote:

> 
> Rahul Aggarwal wrote:
> 
>> Hi Mark,
>>
>> On Wed, 3 Dec 2003, W. Mark Townsley wrote:
>>
>>
>>> Yakov Rekhter wrote:
>>>
>>>> Here is the proposed text:
>>>>
>>>>  Procedures for setting up and maintaining the PSN tunnels with GRE
>>>>  or IP are specified in [MPLS-OVER-IP-GRE].
>>>
>>>
>>> Rahul's proposal was also to remove this text:
>>>
>>> "Procedures for setting up and maintaining the PSN tunnels are 
>>> outside the scope
>>> of this document."
>>>
>>> Which is why I said the proposal changes the scope of the document.
>>>
>>
>>
>> How about replacing
>>
>>    The PSN tunnel can itself be an LSP, but it could equally well
>>    be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
>>    tunnel which can carry MPLS packets. Procedures for setting up and
>>    maintaining the PSN tunnels are outside the scope of this document.
>>
>> with
>>
>>    The PSN tunnel can itself be an LSP, but it could equally well
>>    be an IP tunnel [MPLS-OVER-IP-GRE], a GRE tunnel [MPLS-OVER-IP-GRE],
>>    an IPsec tunnel, or any other sort of tunnel which can carry MPLS
>>    packets. Procedures for setting up and maintaining the PSN tunnels
>>    are outside the scope of this document.
> 
> 
> Better. However, *if* we are going to hit the text here turn what was a 
> set of loose and unbounded examples into a list of specific references, 
> I'd like to go ahead and add L2TPv3 as an example of "any other sort of 
> tunnel which can carry MPLS packets" and include a reference to 
> draft-townsley-l2tpv3-mpls-01.txt. For consistency, we would need to 
> reference your upcoming MPLS over IPsec encapsulation draft as well. I 
> find it arbitrary to reference some examples and not others.
> 


Or alternatively should we further de-scope the draft by removing
all specifics?

After all it's up to other WGs how we carry MPLS over IP.

Perhaps something like:

The PSN tunnel can be an LSP, but it could equally well be some
form of IP based tunnel which can carry MPLS packets. Procedures
for setting up and maintaining the PSN tunnels are outside the
scope of this document.

- Stewart


> I'm also fine with just leaving the text as is.
> 
> - Mark
> 
>>
>>
>> Thanks,
>> rahul
>>
>>
>>> - Mark
>>>
>>>
>>>
>>> _______________________________________________
>>> pwe3 mailing list
>>> pwe3@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/pwe3
>>>
>>
>>
>> _______________________________________________
>> pwe3 mailing list
>> pwe3@ietf.org
>> https://www1.ietf.org/mailman/listinfo/pwe3
>>
> 
> 
> 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: mduckett@bellsouth.net
Subject: pseudowire stitching draft
Date: Thu, 4 Dec 2003 13:21:12 -0500
Lines: 6
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Thu Dec 04 23:17:08 2003
Return-path: <pwe3-admin@ietf.org>
To: <pwe3@ietf.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

At one time, I recall reading a draft addressing or containing information
about pseudowire stitching which is designed to address interdomain
pseudowires.  Believe the draft was authored by Eric Rosen.  If anyone has
pointers to such a document, I'd appreciate it.

Thanks


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Chris Metz <chmetz@cisco.com>
Subject: Re: pseudowire stitching draft
Date: Fri, 05 Dec 2003 09:35:17 -0800
Lines: 26
Sender: pwe3-admin@ietf.org
References: <000901c3ba93$659a0f60$03c7380a@GAR02G401663587>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Fri Dec 05 18:36:10 2003
Return-path: <pwe3-admin@ietf.org>
X-Sender: chmetz@mail1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: mduckett@bellsouth.net
In-Reply-To: <000901c3ba93$659a0f60$03c7380a@GAR02G401663587>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

At 01:21 PM 12/4/2003 -0500, mduckett@bellsouth.net wrote:
>At one time, I recall reading a draft addressing or containing information
>about pseudowire stitching which is designed to address interdomain
>pseudowires.  Believe the draft was authored by Eric Rosen.  If anyone has
>pointers to such a document, I'd appreciate it.

This is probably what you are looking for:

http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-00.txt

Also discussed in the following:

http://www.ietf.org/internet-drafts/draft-luo-l2tpext-l2vpn-signaling-02.txt

Thanks ...




>Thanks
>
>
>_______________________________________________
>pwe3 mailing list
>pwe3@ietf.org
>https://www1.ietf.org/mailman/listinfo/pwe3


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Rahul Aggarwal <rahul@juniper.net>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Fri, 5 Dec 2003 10:49:40 -0800 (PST)
Lines: 107
Sender: pwe3-admin@ietf.org
References: <200312032009.hB3K9CX93427@merlot.juniper.net> <3FCE4DC4.9020101@cisco.com>
 <20031203154500.I70999@sapphire.juniper.net> <3FCF708D.4000209@cisco.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Yakov Rekhter <yakov@juniper.net>, Luca Martini <lmartini@cisco.com>,
        "" <stbryant@cisco.com>, Kireeti Kompella <kireeti@juniper.net>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, "" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Fri Dec 05 19:51:15 2003
Return-path: <pwe3-admin@ietf.org>
X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs
To: "W. Mark Townsley" <townsley@cisco.com>
In-Reply-To: <3FCF708D.4000209@cisco.com>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


Hi Mark,

On Thu, 4 Dec 2003, W. Mark Townsley wrote:

>
> Rahul Aggarwal wrote:
> > Hi Mark,
> >
> > On Wed, 3 Dec 2003, W. Mark Townsley wrote:
> >
> >
> >>Yakov Rekhter wrote:
> >>
> >>>Here is the proposed text:
> >>>
> >>>  Procedures for setting up and maintaining the PSN tunnels with GRE
> >>>  or IP are specified in [MPLS-OVER-IP-GRE].
> >>
> >>Rahul's proposal was also to remove this text:
> >>
> >>"Procedures for setting up and maintaining the PSN tunnels are outside the scope
> >>of this document."
> >>
> >>Which is why I said the proposal changes the scope of the document.
> >>
> >
> >
> > How about replacing
> >
> >    The PSN tunnel can itself be an LSP, but it could equally well
> >    be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
> >    tunnel which can carry MPLS packets. Procedures for setting up and
> >    maintaining the PSN tunnels are outside the scope of this document.
> >
> > with
> >
> >    The PSN tunnel can itself be an LSP, but it could equally well
> >    be an IP tunnel [MPLS-OVER-IP-GRE], a GRE tunnel [MPLS-OVER-IP-GRE],
> >    an IPsec tunnel, or any other sort of tunnel which can carry MPLS
> >    packets. Procedures for setting up and maintaining the PSN tunnels
> >    are outside the scope of this document.
>
> Better. However, *if* we are going to hit the text here turn what was a set of
> loose and unbounded examples into a list of specific references, I'd like to go

It is sill a set of unbounded examples. References are being added, to
relevant IETF documents, where possible.

> ahead and add L2TPv3 as an example of "any other sort of tunnel which can carry
> MPLS packets" and include a reference to draft-townsley-l2tpv3-mpls-01.txt.

draft-townsley-l2tpv3-mpls-01.txt is not a MPLS WG document.
MPLS-OVER-IP-GRE is.

> For consistency,

In this case MPLS over IP is the set. MPLS over IP/GRE is a subset with an
existing IETF document that describes the solution. For rest of the
subset there is no existing IETF document that describes the solution. But
that does not mean that we shouldn't reference the MPLS over IP/GRE
subset.

> we would need to reference your upcoming MPLS over IPsec
> encapsulation draft as well.

As I meantioned above, it is not an existing IETF doucument.

> I find it arbitrary to reference some examples and
> not others.
>

All possible examples are being listed *if* they are existing IETF
documents. That is a consistant approach and is not aribtrary.

rahul


> I'm also fine with just leaving the text as is.
>
> - Mark
>
> >
> >
> > Thanks,
> > rahul
> >
> >
> >>- Mark
> >>
> >>
> >>
> >>_______________________________________________
> >>pwe3 mailing list
> >>pwe3@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/pwe3
> >>
> >
> >
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >
>
>
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Yaakov Stein" <yaakov_s@rad.com>
Subject: RE: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Sun, 7 Dec 2003 09:07:01 +0200
Lines: 20
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "Rahul Aggarwal" <rahul@juniper.net>, "Yakov Rekhter" <yakov@juniper.net>,
        "Luca Martini" <lmartini@cisco.com>,
        "Kireeti Kompella" <kireeti@juniper.net>,
        "Eric Rosen \(erosen\)" <erosen@cisco.com>, <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Sun Dec 07 08:08:12 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
Thread-Topic: [PWE3] Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Thread-Index: AcO6nDaxE/YrWav2Tg6YaDQLBB2LGAB861Bg
To: <stbryant@cisco.com>, "W. Mark Townsley" <townsley@cisco.com>
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

> The PSN tunnel can be an LSP, but it could equally well be some
> form of IP based tunnel which can carry MPLS packets. Procedures
> for setting up and maintaining the PSN tunnels are outside the
> scope of this document.

Well, first that which should be a that.

More importantly, why the requirement for carrying MPLS packets?
Why not carrying the PW label, control word and PW payload?

By saying MPLS packet I assume that you are trying to state
that the mandated method of sending the PW label is an MPLS shim header.

If this is so, let's state this specifically, and state that other =
methods
(e.g. UDP port numbers, L2TP, etc) are not allowed.

If not, the wording is "off".

Y(J)S


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "W. Mark Townsley" <townsley@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Mon, 08 Dec 2003 14:27:05 +0100
Lines: 20
Sender: pwe3-admin@ietf.org
References: <200312032009.hB3K9CX93427@merlot.juniper.net> <3FCE4DC4.9020101@cisco.com> <20031203154500.I70999@sapphire.juniper.net> <3FCF708D.4000209@cisco.com> <20031205103858.Y37331@sapphire.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Yakov Rekhter <yakov@juniper.net>, Luca Martini <lmartini@cisco.com>,
        stbryant@cisco.com, Kireeti Kompella <kireeti@juniper.net>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Dec 08 14:28:06 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
To: Rahul Aggarwal <rahul@juniper.net>
In-Reply-To: <20031205103858.Y37331@sapphire.juniper.net>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


Rahul Aggarwal wrote:
> Hi Mark,
> 
> 
> draft-townsley-l2tpv3-mpls-01.txt is not a MPLS WG document.
> MPLS-OVER-IP-GRE is.

There is no requirement that I know of for a non-normative reference to be on 
the IETF Standards Track.

>>we would need to reference your upcoming MPLS over IPsec
>>encapsulation draft as well.
> 
> As I meantioned above, it is not an existing IETF doucument.

I logically assumed that if you thought GRE and IP needed a reference in the 
document to be clear, IPsec would as well.

- Mark


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Luca Martini <lmartini@cisco.com>
Subject: Re: ATM/Ethernet/Control drafts minor corrections
Date: Mon, 08 Dec 2003 16:03:54 -0700
Organization: Cisco Systems
Lines: 165
Sender: pwe3-admin@ietf.org
References: <AF5018AC03D1D411ABB70002A5091326D31923@TLV1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 09 00:05:16 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
To: Sasha Vainshtein <Sasha@AXERRA.com>
In-Reply-To: <AF5018AC03D1D411ABB70002A5091326D31923@TLV1>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Done. ( there is now a default mode )

Luca


Sasha Vainshtein wrote:

>Luca and all,
>I'd like to repeat my previous comment regarding lack of default mode 
>(port with service-delimiting VLAN tags, port with VLAN tags that are not
>service-delimiting, tagged)
>in the Ethernet encapsulation draft.
>
>
>With best regards,
>                                   Sasha Vainshtein
>email:     sasha@axerra.com <mailto:sasha@axerra.com> 
>tel:       +972-3-7659993 (office)
>           +972-8-9254948 (res.)
>           +972-58-674833 (cell.)
> 
>
>
>  
>
>>-----Original Message-----
>>From: Luca Martini [mailto:lmartini@cisco.com]
>>Sent: Tuesday, November 25, 2003 7:53 PM
>>To: pwe3@ietf.org
>>Subject: [PWE3] ATM/Ethernet/Control drafts minor corrections
>>
>>
>>WG members,
>>
>>I have collected all the comments on the atm and ethernet  
>>encapsulation, drafts, as well as the control and maintenance 
>>protocol 
>>draft.
>>Most are either spelling , punctuation, or english 
>>corrections which are 
>>not significant enought to spell out individually.
>>But there is a minor text clarification below that does not 
>>change the 
>>technical design , but makes the reading easier.
>>
>>First , the title of the ATM draft does not fit:
>>
>>Encapsulation Methods for Transport of ATM Cells/Frame Over 
>>IP and MPLS 
>>Networks
>>So has chaged to :
>>Encapsulation Methods for Transport of ATM Over IP and MPLS Networks
>>
>>To fit in 72 columns.
>>
>>In the sequnce section:
>>
>>BEFORE:
>>4.3.4. Processing the sequence number field in the control word
>>[snip]
>>When a packet is received on that emulated VC, the sequence number
>>   should be processed as follows:
>>
>>     - if the sequence number on the packet is 0, then the 
>>packet passes
>>       the sequence number check
>>
>>     - otherwise if the packet sequence number >= the 
>>expected sequence
>>       number and the packet sequence number - the expected sequence
>>       number < 32768, then the packet is in order.
>>
>>     - otherwise if the packet sequence number < the expected sequence
>>       number and the expected sequence number - the packet sequence
>>       number >= 32768, then the packet is in order.
>>
>>     - otherwise the packet is out of order.
>>
>>   If a packet passes the sequence number check, or is in 
>>order then, it
>>   can be delivered immediately. If the packet is in order, then the
>>   expected sequence number should be set using the algorithm:
>>
>>   expected_sequence_number := packet_sequence_number + 1 mod 2**16
>>   if (expected_sequence_number = 0) then 
>>expected_sequence_number:= 1;
>>
>>   Packets which are received out of order MAY be dropped or reordered
>>   at the discretion of the receiver.
>>
>>   If a router PE2 does not support receive sequence number 
>>processing,
>>   then the sequence number field MAY be ignored.
>>
>>
>>AFTER:
>>
>>4.3.4. Processing the sequence number field in the control word
>>[snip]
>> When a packet is received on that emulated VC, the sequence number
>>   should be processed as follows:
>>
>>     - if the sequence number on the packet is 0, then the 
>>packet passes
>>       the sequence number check.
>>
>>     - otherwise if the packet sequence number >= the 
>>expected sequence
>>       number and the packet sequence number - the expected sequence
>>       number < 32768, then the packet is in order.
>>
>>     - otherwise if the packet sequence number < the expected sequence
>>       number and the expected sequence number - the packet sequence
>>       number >= 32768, then the packet is in order.
>>
>>     - otherwise the packet is out of order.
>>
>>   If a packet is in order then, it can be delivered 
>>immediately. If the
>>   packet is in order, then the expected sequence number MUST be set
>>   using the algorithm:
>>  
>>   expected_sequence_number := packet_sequence_number + 1 mod 2**16
>>   if (expected_sequence_number = 0) then 
>>expected_sequence_number:= 1;
>>
>>
>>   Packets which are received out of order MAY be dropped or reordered
>>   at the discretion of the receiver.
>>
>>   A simple extension of the above processing algorithm can be used to
>>   detect lost packets.
>>
>>   If a router PE2 does not support receive sequence number 
>>processing,
>>   then the sequence number field MAY be ignored.
>>
>>
>>This section is identical in the ethernet or atm draft, and should be 
>>identical in the frame-relay draft as well.
>>Also Stewart, Yakov Stein and I discussed the concerns raised at the 
>>last ITU  meeting , and concluded that this text is correct 
>>and needs no 
>>changes.
>>
>>Thanks.
>>Luca
>>
>>
>>Luca
>>
>>
>>
>>
>>
>>_______________________________________________
>>pwe3 mailing list
>>pwe3@ietf.org
>>https://www1.ietf.org/mailman/listinfo/pwe3
>>
>>    
>>
>
>  
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Luca Martini <lmartini@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Mon, 08 Dec 2003 17:11:14 -0700
Organization: Cisco Systems
Lines: 76
Sender: pwe3-admin@ietf.org
References: <200312032009.hB3K9CX93427@merlot.juniper.net> <3FCE4DC4.9020101@cisco.com> <20031203154500.I70999@sapphire.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "W. Mark Townsley" <townsley@cisco.com>, Yakov Rekhter <yakov@juniper.net>,
        stbryant@cisco.com, Kireeti Kompella <kireeti@juniper.net>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 09 01:13:24 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
To: Rahul Aggarwal <rahul@juniper.net>
In-Reply-To: <20031203154500.I70999@sapphire.juniper.net>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Rahul,

other then the fact that this will block the document pending  
[MPLS-OVER-IP-GRE] , this is ok with me.
( however, I sense that consensus is to leave the text as is )
I would not worry about this too much at this point. I really want to 
see what the IESG/ADs have to say about these documents. I have a 
feeling that we'll have to edit these documents once more. We can then 
add all the references we want.

Luca



Rahul Aggarwal wrote:

>Hi Mark,
>
>On Wed, 3 Dec 2003, W. Mark Townsley wrote:
>
>  
>
>>Yakov Rekhter wrote:
>>    
>>
>>>Here is the proposed text:
>>>
>>>  Procedures for setting up and maintaining the PSN tunnels with GRE
>>>  or IP are specified in [MPLS-OVER-IP-GRE].
>>>      
>>>
>>Rahul's proposal was also to remove this text:
>>
>>"Procedures for setting up and maintaining the PSN tunnels are outside the scope
>>of this document."
>>
>>Which is why I said the proposal changes the scope of the document.
>>
>>    
>>
>
>How about replacing
>
>   The PSN tunnel can itself be an LSP, but it could equally well
>   be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
>   tunnel which can carry MPLS packets. Procedures for setting up and
>   maintaining the PSN tunnels are outside the scope of this document.
>
>with
>
>   The PSN tunnel can itself be an LSP, but it could equally well
>   be an IP tunnel [MPLS-OVER-IP-GRE], a GRE tunnel [MPLS-OVER-IP-GRE],
>   an IPsec tunnel, or any other sort of tunnel which can carry MPLS
>   packets. Procedures for setting up and maintaining the PSN tunnels
>   are outside the scope of this document.
>
>
>Thanks,
>rahul
>
>  
>
>>- Mark
>>
>>
>>
>>_______________________________________________
>>pwe3 mailing list
>>pwe3@ietf.org
>>https://www1.ietf.org/mailman/listinfo/pwe3
>>
>>    
>>
>
>  
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Max Riegel <maximilian.riegel@siemens.com>
Subject: Fwd: Submission of draft-ietf-pwe3-tdm-requirements-02.txt
Date: Tue, 09 Dec 2003 18:49:47 +0100
Lines: 27
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: "Ron Cohen" <ronc@lyciumnetworks.com>,
        "'Sasha Vainshtein'" <Sasha@AXERRA.com>,
        "'Yaakov Stein'" <yaakov_s@Rad.co.il>,
        "'Tim Frost'" <Tim.Frost@Zarlink.Com>,
        "'Prayson Pate'" <prayson.pate@overturenetworks.com>
X-From: pwe3-admin@ietf.org Tue Dec 09 18:50:07 2003
Return-path: <pwe3-admin@ietf.org>
X-Sender: dems1cg2@139.21.212.200
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
To: <pwe3@ietf.org>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

We submitted a new revision of the TDM requirements document to the IETF.

After thorough review of all parts and cleaning up the document it is our 
feeling that draft-ietf-pwe3-tdm-requirements-02.txt is ready for WG last call.

Bye
Max


>Date: Tue, 09 Dec 2003 18:42:06 +0100
>To: "internet-drafts@ietf.org"@moody.mchh.siemens.de
>From: Max Riegel <maximilian.riegel@siemens.com>
>Subject: Submission of draft-ietf-pwe3-tdm-requirements-02.txt
>
>Dear Editor,
>
>we would like to submit the I-D draft-ietf-pwe3-tdm-requirements-02.txt,
>a new revision of the PWE3 WG item.
>
>The chairs of PWE3 are Stewart Bryant <stbryant@cisco.com> and Danny 
>McPherson <danny@tcb.net>.
>
>Please retrieve the full document by
>http://www.max.franken.de/ids/draft-ietf-pwe3-tdm-requirements-02.txt
>
>Kind regards
>Max


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pwe3-fragmentation-04.txt
Date: Tue, 09 Dec 2003 15:39:45 -0500
Lines: 79
Sender: pwe3-admin@ietf.org
Reply-To: Internet-Drafts@ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 09 21:41:05 2003
Return-path: <pwe3-admin@ietf.org>
To: IETF-Announce: ;
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

	Title		: PWE3 Fragmentation and Reassembly
	Author(s)	: A. Malis, M. Townsley
	Filename	: draft-ietf-pwe3-fragmentation-04.txt
	Pages		: 13
	Date		: 2003-12-9
	
This document defines a generalized method of performing
fragmentation for use by PWE3 protocols and services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-fragmentation-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-fragmentation-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Rahul Aggarwal <rahul@juniper.net>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Tue, 9 Dec 2003 13:22:05 -0800 (PST)
Lines: 98
Sender: pwe3-admin@ietf.org
References: <200312032009.hB3K9CX93427@merlot.juniper.net> <3FCE4DC4.9020101@cisco.com>
 <20031203154500.I70999@sapphire.juniper.net> <3FD51322.90006@cisco.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: "W. Mark Townsley" <townsley@cisco.com>, Yakov Rekhter <yakov@juniper.net>,
        "" <stbryant@cisco.com>, Kireeti Kompella <kireeti@juniper.net>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, "" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Tue Dec 09 22:25:06 2003
Return-path: <pwe3-admin@ietf.org>
X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs
To: Luca Martini <lmartini@cisco.com>
In-Reply-To: <3FD51322.90006@cisco.com>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


Hi Luca,

On Mon, 8 Dec 2003, Luca Martini wrote:

> Rahul,
>
> other then the fact that this will block the document pending
> [MPLS-OVER-IP-GRE] ,

MPLS-OVER-IP-GRE is in last call. Hence this may not be an issue.

> this is ok with me.

Great !

> ( however, I sense that consensus is to leave the text as is )
> I would not worry about this too much at this point. I really want to
> see what the IESG/ADs have to say about these documents. I have a
> feeling that we'll have to edit these documents once more. We can then
> add all the references we want.
>

Its your call to add the MPLS-OVER-IP-GRE reference now or in the next round  of editing.
Though it may be simpler to add the reference before getting the IESG/ADs
to review it.

Thanks,
rahul

> Luca
>
>
>
> Rahul Aggarwal wrote:
>
> >Hi Mark,
> >
> >On Wed, 3 Dec 2003, W. Mark Townsley wrote:
> >
> >
> >
> >>Yakov Rekhter wrote:
> >>
> >>
> >>>Here is the proposed text:
> >>>
> >>>  Procedures for setting up and maintaining the PSN tunnels with GRE
> >>>  or IP are specified in [MPLS-OVER-IP-GRE].
> >>>
> >>>
> >>Rahul's proposal was also to remove this text:
> >>
> >>"Procedures for setting up and maintaining the PSN tunnels are outside the scope
> >>of this document."
> >>
> >>Which is why I said the proposal changes the scope of the document.
> >>
> >>
> >>
> >
> >How about replacing
> >
> >   The PSN tunnel can itself be an LSP, but it could equally well
> >   be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
> >   tunnel which can carry MPLS packets. Procedures for setting up and
> >   maintaining the PSN tunnels are outside the scope of this document.
> >
> >with
> >
> >   The PSN tunnel can itself be an LSP, but it could equally well
> >   be an IP tunnel [MPLS-OVER-IP-GRE], a GRE tunnel [MPLS-OVER-IP-GRE],
> >   an IPsec tunnel, or any other sort of tunnel which can carry MPLS
> >   packets. Procedures for setting up and maintaining the PSN tunnels
> >   are outside the scope of this document.
> >
> >
> >Thanks,
> >rahul
> >
> >
> >
> >>- Mark
> >>
> >>
> >>
> >>_______________________________________________
> >>pwe3 mailing list
> >>pwe3@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/pwe3
> >>
> >>
> >>
> >
> >
> >
>
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Eric Rosen <erosen@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 10 Dec 2003 08:50:52 -0500
Lines: 15
Sender: pwe3-admin@ietf.org
References: <20031209125851.U76255@sapphire.juniper.net>
Reply-To: erosen@cisco.com
Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Cc: Luca Martini <lmartini@cisco.com>, "W. Mark Townsley" <townsley@cisco.com>,
        Yakov Rekhter <yakov@juniper.net>, "" <stbryant@cisco.com>,
        Kireeti Kompella <kireeti@juniper.net>, "" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Wed Dec 10 14:52:10 2003
Return-path: <pwe3-admin@ietf.org>
To: Rahul Aggarwal <rahul@juniper.net>
In-reply-to: Your message of Tue, 09 Dec 2003 13:22:05 -0800.
             <20031209125851.U76255@sapphire.juniper.net> 
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3
 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


Luca> however, I sense that consensus is to leave the text as is

Rahul> Its your  call to  add the MPLS-OVER-IP-GRE  reference now or  in the
Rahul> next round of editing.  

Not unless the WG agrees to the change! 

Given that (a)  the control protocol spec has already  passed last call, (b)
no  technical  problem has  been  raised, and  (c)  the  proposed change  is
controversial, I see no reason why any such change should be made. 

As there  hasn't been  any new information  or substantive new  arguments in
some weeks,  how about  a ruling  from the WG  chairs so  we can  close this
issue?  


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 10 Dec 2003 14:46:26 +0000
Organization: Cisco Systems, Inc.
Lines: 127
Sender: pwe3-admin@ietf.org
References: <200312032009.hB3K9CX93427@merlot.juniper.net> <3FCE4DC4.9020101@cisco.com> <20031203154500.I70999@sapphire.juniper.net> <3FD51322.90006@cisco.com> <20031209125851.U76255@sapphire.juniper.net>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Luca Martini <lmartini@cisco.com>, "W. Mark Townsley" <townsley@cisco.com>,
        Yakov Rekhter <yakov@juniper.net>,
        Kireeti Kompella <kireeti@juniper.net>,
        "Eric Rosen (erosen)" <erosen@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 10 15:48:02 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: Rahul Aggarwal <rahul@juniper.net>
In-Reply-To: <20031209125851.U76255@sapphire.juniper.net>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


Danny and I discussed this issue face to face yesterday.

We believe that PWE3 should be agnostic as to the method
used to carry an MPLS label over an IP network.

We therefore suggest that the way forward is to change
the text under discussion in

draft-ietf-pwe3-control-protocol-04.txt

to make it neutral in this respect.

- Stewart


Rahul Aggarwal wrote:
> Hi Luca,
> 
> On Mon, 8 Dec 2003, Luca Martini wrote:
> 
> 
>>Rahul,
>>
>>other then the fact that this will block the document pending
>>[MPLS-OVER-IP-GRE] ,
> 
> 
> MPLS-OVER-IP-GRE is in last call. Hence this may not be an issue.
> 
> 
>>this is ok with me.
> 
> 
> Great !
> 
> 
>>( however, I sense that consensus is to leave the text as is )
>>I would not worry about this too much at this point. I really want to
>>see what the IESG/ADs have to say about these documents. I have a
>>feeling that we'll have to edit these documents once more. We can then
>>add all the references we want.
>>
> 
> 
> Its your call to add the MPLS-OVER-IP-GRE reference now or in the next round  of editing.
> Though it may be simpler to add the reference before getting the IESG/ADs
> to review it.
> 
> Thanks,
> rahul
> 
> 
>>Luca
>>
>>
>>
>>Rahul Aggarwal wrote:
>>
>>
>>>Hi Mark,
>>>
>>>On Wed, 3 Dec 2003, W. Mark Townsley wrote:
>>>
>>>
>>>
>>>
>>>>Yakov Rekhter wrote:
>>>>
>>>>
>>>>
>>>>>Here is the proposed text:
>>>>>
>>>>> Procedures for setting up and maintaining the PSN tunnels with GRE
>>>>> or IP are specified in [MPLS-OVER-IP-GRE].
>>>>>
>>>>>
>>>>
>>>>Rahul's proposal was also to remove this text:
>>>>
>>>>"Procedures for setting up and maintaining the PSN tunnels are outside the scope
>>>>of this document."
>>>>
>>>>Which is why I said the proposal changes the scope of the document.
>>>>
>>>>
>>>>
>>>
>>>How about replacing
>>>
>>>  The PSN tunnel can itself be an LSP, but it could equally well
>>>  be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
>>>  tunnel which can carry MPLS packets. Procedures for setting up and
>>>  maintaining the PSN tunnels are outside the scope of this document.
>>>
>>>with
>>>
>>>  The PSN tunnel can itself be an LSP, but it could equally well
>>>  be an IP tunnel [MPLS-OVER-IP-GRE], a GRE tunnel [MPLS-OVER-IP-GRE],
>>>  an IPsec tunnel, or any other sort of tunnel which can carry MPLS
>>>  packets. Procedures for setting up and maintaining the PSN tunnels
>>>  are outside the scope of this document.
>>>
>>>
>>>Thanks,
>>>rahul
>>>
>>>
>>>
>>>
>>>>- Mark
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>pwe3 mailing list
>>>>pwe3@ietf.org
>>>>https://www1.ietf.org/mailman/listinfo/pwe3
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
> 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 10 Dec 2003 15:00:30 +0000
Organization: Cisco Systems, Inc.
Lines: 28
Sender: pwe3-admin@ietf.org
References: <200312101350.hBADosDM009298@rtp-core-2.cisco.com>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Rahul Aggarwal <rahul@juniper.net>, Luca Martini <lmartini@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        Yakov Rekhter <yakov@juniper.net>,
        Kireeti Kompella <kireeti@juniper.net>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 10 16:02:08 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: erosen@cisco.com
In-Reply-To: <200312101350.hBADosDM009298@rtp-core-2.cisco.com>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



Eric Rosen wrote:

> Luca> however, I sense that consensus is to leave the text as is
> 
> Rahul> Its your  call to  add the MPLS-OVER-IP-GRE  reference now or  in the
> Rahul> next round of editing.  
> 
> Not unless the WG agrees to the change! 
> 

Exactly, the text MUST reflect WG consensus.

> Given that (a)  the control protocol spec has already  passed last call, (b)
> no  technical  problem has  been  raised, and  (c)  the  proposed change  is
> controversial, I see no reason why any such change should be made. 
> 
> As there  hasn't been  any new information  or substantive new  arguments in
> some weeks,  how about  a ruling  from the WG  chairs so  we can  close this
> issue?  

Danny and I talked about this yesterday, and are of the opinion that PWE3
must be agnostic to the method of carrying MPLS over an IP network. Any
change must therefore be in the direction of REMOVING reference to any
specific technique for encapsulating MPLS over IP.

Stewart


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Andrew G. Malis" <andy.malis@tellabs.com>
Subject: Fwd: I-D ACTION:draft-ietf-pwe3-fragmentation-04.txt
Date: Wed, 10 Dec 2003 11:42:00 -0500
Lines: 84
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-From: pwe3-admin@ietf.org Wed Dec 10 17:43:05 2003
Return-path: <pwe3-admin@ietf.org>
X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1
To: "PWE3 (IETF)" <pwe3@ietf.org>
X-OriginalArrivalTime: 10 Dec 2003 16:42:02.0496 (UTC) FILETIME=[89A85800:01C3BF3C]
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

This contains the changes recently discussed on the list.  Danny and 
Stewart, please start WG last call.

Thanks,
Andy

------- Begin of Forwarded Message -------
X-Originating-IP: [132.151.6.22]
To: IETF-Announce: ;
Cc: pwe3@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 09 Dec 2003 15:39:45 -0500
Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-fragmentation-04.txt
Sender: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working 
Group of the IETF.

	Title		: PWE3 Fragmentation and Reassembly
	Author(s)	: A. Malis, M. Townsley
	Filename	: draft-ietf-pwe3-fragmentation-04.txt
	Pages		: 13
	Date		: 2003-12-9
	
This document defines a generalized method of performing
fragmentation for use by PWE3 protocols and services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-04.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-fragmentation-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-fragmentation-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:	<2003-12-9160121.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-pwe3-fragmentation-04.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-04.txt>

------- End of Forwarded Message ------- 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Luca Martini <lmartini@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 10 Dec 2003 11:11:58 -0700
Organization: Cisco Systems
Lines: 47
Sender: pwe3-admin@ietf.org
References: <200312101350.hBADosDM009298@rtp-core-2.cisco.com> <3FD7350E.4010407@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: erosen@cisco.com, Rahul Aggarwal <rahul@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        Yakov Rekhter <yakov@juniper.net>,
        Kireeti Kompella <kireeti@juniper.net>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 10 19:24:06 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
To: stbryant@cisco.com
In-Reply-To: <3FD7350E.4010407@cisco.com>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Also:


; if the PSN tunnel is, e.g., a GRE tunnel, then putting on the tunnel 
encapsulation requires prepending  an IP header and a GRE header.

needs to go.

Luca
Stewart Bryant wrote:

>
>
> Eric Rosen wrote:
>
>> Luca> however, I sense that consensus is to leave the text as is
>>
>> Rahul> Its your  call to  add the MPLS-OVER-IP-GRE  reference now or  
>> in the
>> Rahul> next round of editing. 
>> Not unless the WG agrees to the change!
>
>
> Exactly, the text MUST reflect WG consensus.
>
>> Given that (a)  the control protocol spec has already  passed last 
>> call, (b)
>> no  technical  problem has  been  raised, and  (c)  the  proposed 
>> change  is
>> controversial, I see no reason why any such change should be made.
>> As there  hasn't been  any new information  or substantive new  
>> arguments in
>> some weeks,  how about  a ruling  from the WG  chairs so  we can  
>> close this
>> issue?  
>
>
> Danny and I talked about this yesterday, and are of the opinion that PWE3
> must be agnostic to the method of carrying MPLS over an IP network. Any
> change must therefore be in the direction of REMOVING reference to any
> specific technique for encapsulating MPLS over IP.
>
> Stewart
>
>
>
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Luca Martini <lmartini@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 10 Dec 2003 11:09:02 -0700
Organization: Cisco Systems
Lines: 60
Sender: pwe3-admin@ietf.org
References: <200312101350.hBADosDM009298@rtp-core-2.cisco.com> <3FD7350E.4010407@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: erosen@cisco.com, Rahul Aggarwal <rahul@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        Yakov Rekhter <yakov@juniper.net>,
        Kireeti Kompella <kireeti@juniper.net>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 10 19:24:07 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
To: stbryant@cisco.com
In-Reply-To: <3FD7350E.4010407@cisco.com>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Stewart,

I propose to change this :

 Any sort of PSN tunnel can be used, as long as it is possible  to 
transmit MPLS packets through it.  The PSN tunnel can itself be an LSP,  
but it could equally well be an IP tunnel, a GRE tunnel, an IPsec 
tunnel, or any other sort of tunnel which can carry MPLS packets. 
Procedures for setting up and maintaining the PSN tunnels are outside 
the scope of this  document.

To:
Any sort of PSN tunnel can be used, as long as it is possible  to 
transmit MPLS packets through it.  The PSN tunnel can itself be an LSP,  
or any other sort of tunnel which can carry MPLS packets. Procedures for 
setting up and maintaining the PSN tunnels are outside the scope of 
this  document.

If this is ok , I will send out the update .

Luca

Stewart Bryant wrote:

>
>
> Eric Rosen wrote:
>
>> Luca> however, I sense that consensus is to leave the text as is
>>
>> Rahul> Its your  call to  add the MPLS-OVER-IP-GRE  reference now or  
>> in the
>> Rahul> next round of editing. 
>> Not unless the WG agrees to the change!
>
>
> Exactly, the text MUST reflect WG consensus.
>
>> Given that (a)  the control protocol spec has already  passed last 
>> call, (b)
>> no  technical  problem has  been  raised, and  (c)  the  proposed 
>> change  is
>> controversial, I see no reason why any such change should be made.
>> As there  hasn't been  any new information  or substantive new  
>> arguments in
>> some weeks,  how about  a ruling  from the WG  chairs so  we can  
>> close this
>> issue?  
>
>
> Danny and I talked about this yesterday, and are of the opinion that PWE3
> must be agnostic to the method of carrying MPLS over an IP network. Any
> change must therefore be in the direction of REMOVING reference to any
> specific technique for encapsulating MPLS over IP.
>
> Stewart
>
>
>
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Scott W Brim <sbrim@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 10 Dec 2003 14:06:56 -0500
Lines: 23
Sender: pwe3-admin@ietf.org
References: <200312101350.hBADosDM009298@rtp-core-2.cisco.com> <3FD7350E.4010407@cisco.com> <3FD7613E.5050709@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: stbryant@cisco.com, erosen@cisco.com, Rahul Aggarwal <rahul@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        Yakov Rekhter <yakov@juniper.net>,
        Kireeti Kompella <kireeti@juniper.net>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 10 20:08:24 2003
Return-path: <pwe3-admin@ietf.org>
To: Luca Martini <lmartini@cisco.com>
Mail-Followup-To: Scott W Brim <sbrim@cisco.com>,
	Luca Martini <lmartini@cisco.com>, stbryant@cisco.com,
	erosen@cisco.com, Rahul Aggarwal <rahul@juniper.net>,
	"W. Mark Townsley" <townsley@cisco.com>,
	Yakov Rekhter <yakov@juniper.net>,
	Kireeti Kompella <kireeti@juniper.net>, pwe3@ietf.org
Content-Disposition: inline
In-Reply-To: <3FD7613E.5050709@cisco.com>
User-Agent: Mutt/1.4.1i
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

On Wed, Dec 10, 2003 11:09:02AM -0700, Luca Martini allegedly wrote:
> Stewart,
> 
> I propose to change this :
> 
> Any sort of PSN tunnel can be used, as long as it is possible  to 
> transmit MPLS packets through it.  The PSN tunnel can itself be an LSP,  
> but it could equally well be an IP tunnel, a GRE tunnel, an IPsec 
> tunnel, or any other sort of tunnel which can carry MPLS packets. 
> Procedures for setting up and maintaining the PSN tunnels are outside 
> the scope of this  document.
> 
> To:
> Any sort of PSN tunnel can be used, as long as it is possible  to 
> transmit MPLS packets through it.  The PSN tunnel can itself be an LSP,  
> or any other sort of tunnel which can carry MPLS packets. Procedures for 
> setting up and maintaining the PSN tunnels are outside the scope of 
> this  document.

Add something like "as are the tunnel encapsulation mechanisms for
carrying MPLS packets."

Scott


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 10 Dec 2003 19:17:41 +0000
Organization: Cisco Systems, Inc.
Lines: 57
Sender: pwe3-admin@ietf.org
References: <200312101350.hBADosDM009298@rtp-core-2.cisco.com> <3FD7350E.4010407@cisco.com> <3FD761EE.9090907@cisco.com>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: erosen@cisco.com, Rahul Aggarwal <rahul@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        Yakov Rekhter <yakov@juniper.net>,
        Kireeti Kompella <kireeti@juniper.net>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 10 20:19:03 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: Luca Martini <lmartini@cisco.com>
In-Reply-To: <3FD761EE.9090907@cisco.com>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Yes, that's OK

Stewart

Luca Martini wrote:

> Also:
> 
> 
> ; if the PSN tunnel is, e.g., a GRE tunnel, then putting on the tunnel 
> encapsulation requires prepending  an IP header and a GRE header.
> 
> needs to go.
> 
> Luca
> Stewart Bryant wrote:
> 
>>
>>
>> Eric Rosen wrote:
>>
>>> Luca> however, I sense that consensus is to leave the text as is
>>>
>>> Rahul> Its your  call to  add the MPLS-OVER-IP-GRE  reference now or  
>>> in the
>>> Rahul> next round of editing. Not unless the WG agrees to the change!
>>
>>
>>
>> Exactly, the text MUST reflect WG consensus.
>>
>>> Given that (a)  the control protocol spec has already  passed last 
>>> call, (b)
>>> no  technical  problem has  been  raised, and  (c)  the  proposed 
>>> change  is
>>> controversial, I see no reason why any such change should be made.
>>> As there  hasn't been  any new information  or substantive new  
>>> arguments in
>>> some weeks,  how about  a ruling  from the WG  chairs so  we can  
>>> close this
>>> issue?  
>>
>>
>>
>> Danny and I talked about this yesterday, and are of the opinion that PWE3
>> must be agnostic to the method of carrying MPLS over an IP network. Any
>> change must therefore be in the direction of REMOVING reference to any
>> specific technique for encapsulating MPLS over IP.
>>
>> Stewart
>>
>>
>>
>>
> 
> 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 10 Dec 2003 19:17:00 +0000
Organization: Cisco Systems, Inc.
Lines: 70
Sender: pwe3-admin@ietf.org
References: <200312101350.hBADosDM009298@rtp-core-2.cisco.com> <3FD7350E.4010407@cisco.com> <3FD7613E.5050709@cisco.com>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: erosen@cisco.com, Rahul Aggarwal <rahul@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        Yakov Rekhter <yakov@juniper.net>,
        Kireeti Kompella <kireeti@juniper.net>, pwe3@ietf.org,
        Danny McPherson <danny@arbor.net>
X-From: pwe3-admin@ietf.org Wed Dec 10 20:19:03 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: Luca Martini <lmartini@cisco.com>
In-Reply-To: <3FD7613E.5050709@cisco.com>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Looks good to me

Stewart

Luca Martini wrote:

> Stewart,
> 
> I propose to change this :
> 
> Any sort of PSN tunnel can be used, as long as it is possible  to 
> transmit MPLS packets through it.  The PSN tunnel can itself be an LSP,  
> but it could equally well be an IP tunnel, a GRE tunnel, an IPsec 
> tunnel, or any other sort of tunnel which can carry MPLS packets. 
> Procedures for setting up and maintaining the PSN tunnels are outside 
> the scope of this  document.
> 
> To:
> Any sort of PSN tunnel can be used, as long as it is possible  to 
> transmit MPLS packets through it.  The PSN tunnel can itself be an LSP,  
> or any other sort of tunnel which can carry MPLS packets. Procedures for 
> setting up and maintaining the PSN tunnels are outside the scope of 
> this  document.
> 
> If this is ok , I will send out the update .
> 
> Luca
> 
> Stewart Bryant wrote:
> 
>>
>>
>> Eric Rosen wrote:
>>
>>> Luca> however, I sense that consensus is to leave the text as is
>>>
>>> Rahul> Its your  call to  add the MPLS-OVER-IP-GRE  reference now or  
>>> in the
>>> Rahul> next round of editing. Not unless the WG agrees to the change!
>>
>>
>>
>> Exactly, the text MUST reflect WG consensus.
>>
>>> Given that (a)  the control protocol spec has already  passed last 
>>> call, (b)
>>> no  technical  problem has  been  raised, and  (c)  the  proposed 
>>> change  is
>>> controversial, I see no reason why any such change should be made.
>>> As there  hasn't been  any new information  or substantive new  
>>> arguments in
>>> some weeks,  how about  a ruling  from the WG  chairs so  we can  
>>> close this
>>> issue?  
>>
>>
>>
>> Danny and I talked about this yesterday, and are of the opinion that PWE3
>> must be agnostic to the method of carrying MPLS over an IP network. Any
>> change must therefore be in the direction of REMOVING reference to any
>> specific technique for encapsulating MPLS over IP.
>>
>> Stewart
>>
>>
>>
>>
> 
> 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Luca Martini <lmartini@cisco.com>
Subject: Re: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Wed, 10 Dec 2003 12:23:22 -0700
Organization: Cisco Systems
Lines: 47
Sender: pwe3-admin@ietf.org
References: <200312101350.hBADosDM009298@rtp-core-2.cisco.com> <3FD7350E.4010407@cisco.com> <3FD7613E.5050709@cisco.com> <20031210190655.GD2036@sbrim-w2k01>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stbryant@cisco.com, erosen@cisco.com, Rahul Aggarwal <rahul@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        Yakov Rekhter <yakov@juniper.net>,
        Kireeti Kompella <kireeti@juniper.net>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 10 20:24:03 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
To: Scott W Brim <sbrim@cisco.com>
In-Reply-To: <20031210190655.GD2036@sbrim-w2k01>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

ok
something like :

Any sort of PSN tunnel can be used, as long as it is possible  to 
transmit MPLS packets through it.  The PSN tunnel can itself be an LSP,  
or any other sort of tunnel which can carry MPLS packets. 
The procedure for encapsulating MPLS packets in PSN tunnels, or the setup and 
maintenance of PSN tunnels is outside the scope of this document.


Luca




Scott W Brim wrote:

>On Wed, Dec 10, 2003 11:09:02AM -0700, Luca Martini allegedly wrote:
>  
>
>>Stewart,
>>
>>I propose to change this :
>>
>>Any sort of PSN tunnel can be used, as long as it is possible  to 
>>transmit MPLS packets through it.  The PSN tunnel can itself be an LSP,  
>>but it could equally well be an IP tunnel, a GRE tunnel, an IPsec 
>>tunnel, or any other sort of tunnel which can carry MPLS packets. 
>>Procedures for setting up and maintaining the PSN tunnels are outside 
>>the scope of this  document.
>>
>>To:
>>Any sort of PSN tunnel can be used, as long as it is possible  to 
>>transmit MPLS packets through it.  The PSN tunnel can itself be an LSP,  
>>or any other sort of tunnel which can carry MPLS packets. Procedures for 
>>setting up and maintaining the PSN tunnels are outside the scope of 
>>this  document.
>>    
>>
>
>Add something like "as are the tunnel encapsulation mechanisms for
>carrying MPLS packets."
>
>Scott
>
>  
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pwe3-tdm-requirements-02.txt
Date: Wed, 10 Dec 2003 15:41:13 -0500
Lines: 85
Sender: pwe3-admin@ietf.org
Reply-To: Internet-Drafts@ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 10 21:42:10 2003
Return-path: <pwe3-admin@ietf.org>
To: IETF-Announce: ;
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

	Title		: Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN)
	Author(s)	: M. Riegel
	Filename	: draft-ietf-pwe3-tdm-requirements-02.txt
	Pages		: 25
	Date		: 2003-12-10
	
This document specifies the particular requirements for
edge-to-edge-emulation of circuits carrying time division multiplexed
digital signals of the PDH as well as the SONET/SDH hierarchy over
packet-switched networks. It is based on the common architecture for
Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [PWE3-ARCH].
It makes references to requirements in [PWE3-REQ] where applicable
and complements [PWE3-REQ] by defining requirements originating from
specifics of TDM circuits.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-requirements-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-tdm-requirements-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-tdm-requirements-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Yaakov Stein" <yaakov_s@rad.com>
Subject: RE: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Date: Thu, 11 Dec 2003 09:56:34 +0200
Lines: 8
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: <stbryant@cisco.com>, "Scott W Brim" <sbrim@cisco.com>, <erosen@cisco.com>,
        "Rahul Aggarwal" <rahul@juniper.net>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Yakov Rekhter" <yakov@juniper.net>,
        "Kireeti Kompella" <kireeti@juniper.net>, <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Thu Dec 11 08:58:04 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
Thread-Topic: [PWE3] Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt
Thread-Index: AcO/Uzfmcf9yCy5jQIi8SeNyF3YmdwAZ6uDw
To: "Luca Martini" <lmartini@cisco.com>
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Try this:

Any PSN tunnel that could be used for the transport of MPLS packets
is acceptable. In particular, the PSN tunnel may itself be an LSP,=20
but other tunnel types are equally admissible.=20
Procedures for setup and maintenance of PSN tunnels,
as well as the MPLS packet encapsulation formats,=20
are beyond the scope of the present document.


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Maarten.Vissers@alcatel.de
Subject: VLAN ID functions [was: 802.1ad Customer FCS Retention]
Date: Thu, 11 Dec 2003 10:47:45 +0100
Lines: 118
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: pwe3@ietf.org, stds-802-1@ieee.org
X-From: pwe3-admin@ietf.org Thu Dec 11 10:49:10 2003
Return-path: <pwe3-admin@ietf.org>
To: <neil.2.harrison@bt.com>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
X-MIMETrack: Serialize by Router on DEMAIL02/DE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 12/11/2003 10:47:47,
	Serialize complete at 12/11/2003 10:47:47
X-Alcanet-virus-scanned: hBB9llV4000689 at mailrelay1.alcatel.de
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Neil,

The VLAN ID has two functions:
1) a means to identify an ETH VPN and instantiate an ETH flow domain 
fragment (G.8010)
2) a means to identify and instantiate an ETH component link.

In today's ethernet these two fucntions are often locked together.
 
It would however be possible to use the second function independent of the 
first one; i.e. to create a CO-PS VLAN layer network with VLAN IDs as 
tributary slot/link connection identifiers on VLAN Links (similar to VPI, 
VCI, label, timeslot) and VLAN connection functions [switches] that are 
able to perform VLAN ID translation/swapping. Each VLAN topological link 
would be able to carry 4k link connections (same number as on an ATM VP 
Link). With VLAN stacking it would be possible to create a hierarchy. With 
two [CO-PS] VLAN tags it would be similar to ATM (with its VC and VP 
levels). With an "infinite" number of [CO-PS] VLAN tags it would be 
similar to MPLS (LSP in tunnels in tunnels in tunnels in ..). 

This isn't "bridged ethernet" anymore; it is more "switched VLAN" or 
perhaps it could be called "switched ethernet". Nevertheless it would 
still use ethernet interfaces, now connected to "VLAN switches". Such 
Ethernet over [CO-PS] VLAN would be an alternative for Ethernet over MPLS 
and Ethernet over ATM. Any interest in such Ethernet CO-PS derivative? 

Regards,
Maarten


---------------------------------------------------------------------
Maarten Vissers
Network and Product Strategy - Optical Networks Division
Alcatel SEL AG 
Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
Mobile: +31 65 141 8140
Email:Maarten.Vissers@alcatel.de




<neil.2.harrison@bt.com>
Sent by: owner-stds-802-1@majordomo.ieee.org
01-12-2003 16:08

 
        To:     <stbryant@cisco.com>
        cc:     <sajassi@cisco.com>, <stds-802-1@ieee.org>, <pwe3@ietf.org>, Maarten 
VISSERS/DE/ALCATEL@ALCATEL
        Subject:        RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention



Stewart,

Stewart wrote 01 December 2003 13:37
<snipped>
> >>No PDH and SDH are different. These are port-based Ethernet 
> service; 
> >>whereas, I was talking about vlan-based services (e.g., each 
> >>VLAN is a VC) 
> >>and making analogy between VLAN-id in Ethernet and DLCI in FR 
> >>or VPI/VCI in 
> >>ATM.
> > 
> > NH=> I don't think this analogy is valid.  A VPI/VCI (ATM), 
> > DLCI (FR) or a 'label' (MPLS) are all examples of link-connection 
> > identifiers.  These entities have no network currency until/unless 
> > they are associated with some parent trail entity (no matter 
> > how that is created). 
> 
> Here you are talking about the inner label. The outer label
> would normally be an abbreviation for an IP address.
NH=> I think we need a better explantion as to what is actually going on 
here.  All co-ps/cs technologies work in essentially the same way.  If we 
take the largest subnetwork (G.805 sense) then the network access points 
are where it's addresses are located.  These are also intrinsically bound 
to trail termination functions.  The link-connections in co-ps/cs networks 
use labels that only have local (link) signficance.  When a trail is 
established between the network addressed access points than a series of 
concatenated link-connections and subnetworks (the smallest subnetwork 
being a node/switch in the technology of relevance) is created.....the 
link-connection IDs have no network currency before this, ie they sit in a 
pool waiting to be allocated (and are reuturned to the pool when the trail 
is torn-down).  So in all co-ps/cs technologies then 'yes' one could say a 
label points to some distant access point address.....and since the labels 
are a series of related/concatenated!
  links then this pointing to a distant destination address carries all 
the way to the access point at the trail source.

This is also why mp2p is a deprecated topology in the co-ps/cs 
modes.....though in the co-cs mode you simply can't physically create this 
violation, but you can force it in the co-ps mode.  Merging means we have 
lost transparency and integrity of the CI, ie we no longer uniquely know 
the source.  Which is why we are forced to run an extra p2p LSP above the 
mp2p construct to recover from the arch violation of this mode.  So the 
fact that the semantics of the label (ie inner vs outer) is now altered is 
simply a consequence of this arch violation.  Also note that IP belongs to 
the cnls mode and never has this problem....that is, the cnls mode always 
muxes and never merges....why?...because each traffic unit carries the 
full network DA/SA pair.....and that is indeed the signature of the cnls 
mode.
> 
> > A VLAN ID is not a link-connection 
> > identifier.  It is more like a 'name', in that it 
> > subdivides the total MAC address population into contained 
> > sub-spaces of MAC addresses (that belong to a given VLAN). 
> 
> Isn't it a virtual network identifier.
NH=> Yes, that was my point above saying it is a more like a 'name'....its 
not a link-connection ID in the same sense as VPI/VCI, DLCIs and MPLS 
labels are.

Stewart....I think we are wandering off topic now....so if this is to 
continue I suggest we change the title.

regards, Neil


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Maarten.Vissers@alcatel.de
Subject: PW functional model and its OAM [was: FCS retention in PWE3]
Date: Thu, 11 Dec 2003 12:45:15 +0100
Lines: 196
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Thu Dec 11 12:47:04 2003
Return-path: <pwe3-admin@ietf.org>
To: stbryant@cisco.com
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
X-MIMETrack: Serialize by Router on DEMAIL02/DE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 12/11/2003 12:45:16,
	Serialize complete at 12/11/2003 12:45:16
X-Alcanet-virus-scanned: hBBBjHV4018386 at mailrelay1.alcatel.de
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Stewart,

> VCCV is the only method that has been formally accepted bt the PWE3
> WG for further study. If you think that Y.1711 is more appropriate,
> please write a draft explaining how this works in the PWE3 context and
> why it is better. The WG will then decide the way forward through
> our normal process.


The G.805/G.809 based functional model for an Ethernet over MPLS 
connection will [likely] contain: an MPLS/ETH_A (adaptation) function that 
is connected to an MPLS_TT (trail termination) function:

                   |
                   O ETH_FP (flow point, see G.8010)
                   |
           ----------------
            \ MPLS/ETH_A /  Encapsulation of ETH MAC frame
             ------------   into MPLS packet payload
                   |
                   O MPLS_AP (access point)
                   |
              -----------
               \MPLS_TT/    Y.1711 OAM (e.g. CV, BDI, FDI)
                \     /
                 \   /
                  \ /
                   |
                   O MPLS_TCP (termination connecction point)
                   |
       other MPLS functions, or
       Server/MPLS_A function
 
The MPLS/ETH adaptation function encapsulates the ETH MAC frames into the 
MPLS packet payload (PW). The MPLS trail termination function is the 
endpoint of the MPLS Maintenance Entity (i.e. trail) and has associated 
with it MPLS OAM to perform pro-active fault management (e.g. using Y.1711 
MPLS-CV, MPLS-BDI, MPLS-FDI) or on-demand fault localisation for the 
network connection (X-to-Y in figure below).

On-demand fault localisation OAM (e.g. loopback/ping, traceroute) may also 
be sourced/sinked in MPLS test trail termination functions (centralised 
function in a node), which may be connected to the MPLS serial compound 
link connection (between ingress and egress PE: K-to-L in figure below). 
In this case the connections through the first and last fabrics ((a) in 
MPLS connection functions in figure below) are not monitored.


             Ingress PE
<-------------------------------->
              -----------
               \  MPLS /  on-demand
                \ Test/   MPLS OAM
                 \   /
                  \ /
                   |
    pro-act.       O
    MPLS OAM       |
     |\     -----------   |\
     |M\    |   (b)|  | K | \
     |P \ X |      \  |-O-|  |     MPLS
  -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
     |S /   |  (a)    |-O-|  |             |
     | /    |         |   | /              |
     |/     -----------   |/               |
         MPLS Conn. funct.                 |
                                           |
                                           |
         MPLS Conn. funct.                 |
     |\     -----------   |\               |
     |M\    |         | L | \              |
     |P \ Y |  (a)    |-O-|  |     MPLS    |
  -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
     |S /   |       / |-O-|  |
     | /    |   (b)|  |   | /
     |/     -----------   |/
    pro-act.       |
    MPLS OAM       O
                   |
                  / \
                 /   \
                / MPLS\   on-demand
               /  Test \  MPLS OAM
              -----------
<--------------------------------> 
              Egress PE


Based on the functional model of a pseudowire, the presence of Y.1711 as 
MPLS OAM standard and the default allocation of certains types of [MPLS] 
OAM to [MPLS] trail termination functions, one may conclude that Y.1711 is 
already an existing alternative in the fault management and performance 
monitoring of a MPLS based pseudowire (which is a client layer-network 
link supported by a MPLS trail).

Regards,
Maarten



---------------------------------------------------------------------
Maarten Vissers
Network and Product Strategy - Optical Networks Division
Alcatel SEL AG 
Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
Mobile: +31 65 141 8140
Email:Maarten.Vissers@alcatel.de





Stewart Bryant <stbryant@cisco.com>
Sent by: pwe3-admin@ietf.org
01-12-2003 11:31
Please respond to stbryant

 
        To:     neil.2.harrison@bt.com
        cc:     pwe3@ietf.org
        Subject:        Re: [PWE3] FCS retention in PWE3




neil.2.harrison@bt.com wrote:

> Stwart,
> 
> In general I agree with you.  But what you are actually saying 
> here is that we want independent OAM in each layer network (simply
> has to be independent....one reason being that we want the *same*
> OAM solution in the server irrespective of its client). 

Independent yes. Same depends on whether there are any differences
in the requirement that suggest otherwise, but I agree same would
be a good thing.

> But please note this:
> -              a PW is not a layer network, ie we do not network/switch 
PW entities;

I am not sure about this. Logically what we are doing is to recurse
back to a lower layer, over which we could run for example a new IGP.
In as much as we network/switch wires, we network/switch PWs.

> -              an LSP is a layer network, ie we do network/switch LSP 
entities;
> -              why can't we use Y.1711 OAM on the top level p2p LSP?

VCCV is the only method that has been formally accepted bt the PWE3
WG for further study. If you think that Y.1711 is more appropriate,
please write a draft explaining how this works in the PWE3 context and
why it is better. The WG will then decide the way forward through
our normal process.

> -              Y.1711 is sparse/simple/complete, ie all defects are 
defined 
         with entry-exit criteria and consequent actions.....it even
         defines availability and does so in order it can be used a
         single-ended way, ie behaviour of both directions can be
         observed from 1 end.

> -              MPLS and ATM OAM layer I/W is already defined in 
Y.1712.....
         and again its really simple.

         I thought that we were talking about Ethernet here?
> 
> None of this is done (and in some cases is not appropriate) for 
> the VCCV approach. 

I which case the VCCV team need to either provide these or explain
why they are not needed.

> 
> So what is wrong with this solution?

There is no WG draft describing the applicability of Y.1711 to PWE3.
If you want that solution, then you have to run the normal IETF
process to get it adopted, which will involve writing a draft,
getting it accepted by the WG, and going through a point by point
analysis of the advantages and disadvantages of Y.1711 and VCCV.

Regards

Stewart




_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: neil.2.harrison@bt.com
Subject: RE: PW functional model and its OAM [was: FCS retention in PWE3]
Date: Thu, 11 Dec 2003 14:39:34 -0000
Lines: 257
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Thu Dec 11 15:41:12 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
Thread-Topic: [PWE3] PW functional model and its OAM [was: FCS retention in PWE3]
Thread-Index: AcO/3viTFIYug14rRGC2rBkD+BWwGgAAsbtw
To: <Maarten.Vissers@alcatel.de>, <stbryant@cisco.com>
X-OriginalArrivalTime: 11 Dec 2003 14:39:34.0623 (UTC) FILETIME=[9865A6F0:01C3BFF4]
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Thanks Maarten....that seems pretty-well spot-on.  And yes, your =
diagrams clearly show that the PW is an adaptation function that lies =
above the MPLS layer network.  So VCCV and Y.1711 are not operating in =
the same space and thus it is technically incorrect to try and compare =
them.....that is:
-	VCCV is defining some OAM function that is specific to a PW adaptation =
function (rather odd architecturally however...also see Note);
-	whilst Y.1711 is generic and operates in the MPLS layer network =
irrespective of the client.

Note - In the draft draft-ietf-pwe3-satop-00.txt one will also find some =
specific client/PW case OAM functions....here for a certain type of TDM =
client, ie the 'L' and 'R' bits.

The key point however, is that MPLS OAM should be generic irrespective =
of the client, and it should not be a function of the client adaptation =
function but only of the MPLS trail termination function as Maarten =
correctly identifies below.

So, if one is to compare Y.1711 to anything it should be to LSP-Ping =
say.  However, I see these as complimentary functions;  and its clear =
from what Maarten writes below he shares this view.

regards, Neil

> -----Original Message-----
> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of
> Maarten.Vissers@alcatel.de
> Sent: 11 December 2003 11:45
> To: stbryant@cisco.com
> Cc: pwe3@ietf.org
> Subject: [PWE3] PW functional model and its OAM [was: FCS retention in
> PWE3]
>=20
>=20
> Stewart,
>=20
> > VCCV is the only method that has been formally accepted bt the PWE3
> > WG for further study. If you think that Y.1711 is more appropriate,
> > please write a draft explaining how this works in the PWE3=20
> context and
> > why it is better. The WG will then decide the way forward through
> > our normal process.
>=20
>=20
> The G.805/G.809 based functional model for an Ethernet over MPLS=20
> connection will [likely] contain: an MPLS/ETH_A (adaptation)=20
> function that=20
> is connected to an MPLS_TT (trail termination) function:
>=20
>                    |
>                    O ETH_FP (flow point, see G.8010)
>                    |
>            ----------------
>             \ MPLS/ETH_A /  Encapsulation of ETH MAC frame
>              ------------   into MPLS packet payload
>                    |
>                    O MPLS_AP (access point)
>                    |
>               -----------
>                \MPLS_TT/    Y.1711 OAM (e.g. CV, BDI, FDI)
>                 \     /
>                  \   /
>                   \ /
>                    |
>                    O MPLS_TCP (termination connecction point)
>                    |
>        other MPLS functions, or
>        Server/MPLS_A function
> =20
> The MPLS/ETH adaptation function encapsulates the ETH MAC=20
> frames into the=20
> MPLS packet payload (PW). The MPLS trail termination function is the=20
> endpoint of the MPLS Maintenance Entity (i.e. trail) and has=20
> associated=20
> with it MPLS OAM to perform pro-active fault management (e.g.=20
> using Y.1711=20
> MPLS-CV, MPLS-BDI, MPLS-FDI) or on-demand fault localisation for the=20
> network connection (X-to-Y in figure below).
>=20
> On-demand fault localisation OAM (e.g. loopback/ping,=20
> traceroute) may also=20
> be sourced/sinked in MPLS test trail termination functions=20
> (centralised=20
> function in a node), which may be connected to the MPLS=20
> serial compound=20
> link connection (between ingress and egress PE: K-to-L in=20
> figure below).=20
> In this case the connections through the first and last=20
> fabrics ((a) in=20
> MPLS connection functions in figure below) are not monitored.
>=20
>=20
>              Ingress PE
> <-------------------------------->
>               -----------
>                \  MPLS /  on-demand
>                 \ Test/   MPLS OAM
>                  \   /
>                   \ /
>                    |
>     pro-act.       O
>     MPLS OAM       |
>      |\     -----------   |\
>      |M\    |   (b)|  | K | \
>      |P \ X |      \  |-O-|  |     MPLS
>   -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
>      |S /   |  (a)    |-O-|  |             |
>      | /    |         |   | /              |
>      |/     -----------   |/               |
>          MPLS Conn. funct.                 |
>                                            |
>                                            |
>          MPLS Conn. funct.                 |
>      |\     -----------   |\               |
>      |M\    |         | L | \              |
>      |P \ Y |  (a)    |-O-|  |     MPLS    |
>   -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
>      |S /   |       / |-O-|  |
>      | /    |   (b)|  |   | /
>      |/     -----------   |/
>     pro-act.       |
>     MPLS OAM       O
>                    |
>                   / \
>                  /   \
>                 / MPLS\   on-demand
>                /  Test \  MPLS OAM
>               -----------
> <-------------------------------->=20
>               Egress PE
>=20
>=20
> Based on the functional model of a pseudowire, the presence=20
> of Y.1711 as=20
> MPLS OAM standard and the default allocation of certains=20
> types of [MPLS]=20
> OAM to [MPLS] trail termination functions, one may conclude=20
> that Y.1711 is=20
> already an existing alternative in the fault management and=20
> performance=20
> monitoring of a MPLS based pseudowire (which is a client=20
> layer-network=20
> link supported by a MPLS trail).
>=20
> Regards,
> Maarten
>=20
>=20
>=20
> ---------------------------------------------------------------------
> Maarten Vissers
> Network and Product Strategy - Optical Networks Division
> Alcatel SEL AG=20
> Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
> Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
> Mobile: +31 65 141 8140
> Email:Maarten.Vissers@alcatel.de
>=20
>=20
>=20
>=20
>=20
> Stewart Bryant <stbryant@cisco.com>
> Sent by: pwe3-admin@ietf.org
> 01-12-2003 11:31
> Please respond to stbryant
>=20
> =20
>         To:     neil.2.harrison@bt.com
>         cc:     pwe3@ietf.org
>         Subject:        Re: [PWE3] FCS retention in PWE3
>=20
>=20
>=20
>=20
> neil.2.harrison@bt.com wrote:
>=20
> > Stwart,
> >=20
> > In general I agree with you.  But what you are actually saying=20
> > here is that we want independent OAM in each layer network (simply
> > has to be independent....one reason being that we want the *same*
> > OAM solution in the server irrespective of its client).=20
>=20
> Independent yes. Same depends on whether there are any differences
> in the requirement that suggest otherwise, but I agree same would
> be a good thing.
>=20
> > But please note this:
> > -              a PW is not a layer network, ie we do not=20
> network/switch=20
> PW entities;
>=20
> I am not sure about this. Logically what we are doing is to recurse
> back to a lower layer, over which we could run for example a new IGP.
> In as much as we network/switch wires, we network/switch PWs.
>=20
> > -              an LSP is a layer network, ie we do=20
> network/switch LSP=20
> entities;
> > -              why can't we use Y.1711 OAM on the top level p2p LSP?
>=20
> VCCV is the only method that has been formally accepted bt the PWE3
> WG for further study. If you think that Y.1711 is more appropriate,
> please write a draft explaining how this works in the PWE3 context and
> why it is better. The WG will then decide the way forward through
> our normal process.
>=20
> > -              Y.1711 is sparse/simple/complete, ie all defects are=20
> defined=20
>          with entry-exit criteria and consequent actions.....it even
>          defines availability and does so in order it can be used a
>          single-ended way, ie behaviour of both directions can be
>          observed from 1 end.
>=20
> > -              MPLS and ATM OAM layer I/W is already defined in=20
> Y.1712.....
>          and again its really simple.
>=20
>          I thought that we were talking about Ethernet here?
> >=20
> > None of this is done (and in some cases is not appropriate) for=20
> > the VCCV approach.=20
>=20
> I which case the VCCV team need to either provide these or explain
> why they are not needed.
>=20
> >=20
> > So what is wrong with this solution?
>=20
> There is no WG draft describing the applicability of Y.1711 to PWE3.
> If you want that solution, then you have to run the normal IETF
> process to get it adopted, which will involve writing a draft,
> getting it accepted by the WG, and going through a point by point
> analysis of the advantages and disadvantages of Y.1711 and VCCV.
>=20
> Regards
>=20
> Stewart
>=20
>=20
>=20
>=20
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>=20
>=20
>=20
>=20
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>=20


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in
	 PWE3]
Date: Thu, 11 Dec 2003 10:54:34 -0500
Lines: 294
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Thu Dec 11 16:59:07 2003
Return-path: <pwe3-admin@ietf.org>
To: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        Maarten.Vissers@alcatel.de, stbryant@cisco.com
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Neil,

You seem to suggest that VCCV is has client-specific elements. I don't see that. Could you explain what in the VCCV draft is client-specific?

Thanks,

Peter

> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Thursday, December 11, 2003 9:40 AM
> To: Maarten.Vissers@alcatel.de; stbryant@cisco.com
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> retention
> in PWE3]
> 
> 
> Thanks Maarten....that seems pretty-well spot-on.  And yes, 
> your diagrams clearly show that the PW is an adaptation 
> function that lies above the MPLS layer network.  So VCCV and 
> Y.1711 are not operating in the same space and thus it is 
> technically incorrect to try and compare them.....that is:
> -	VCCV is defining some OAM function that is specific to 
> a PW adaptation function (rather odd architecturally 
> however...also see Note);
> -	whilst Y.1711 is generic and operates in the MPLS layer 
> network irrespective of the client.
> 
> Note - In the draft draft-ietf-pwe3-satop-00.txt one will 
> also find some specific client/PW case OAM functions....here 
> for a certain type of TDM client, ie the 'L' and 'R' bits.
> 
> The key point however, is that MPLS OAM should be generic 
> irrespective of the client, and it should not be a function 
> of the client adaptation function but only of the MPLS trail 
> termination function as Maarten correctly identifies below.
> 
> So, if one is to compare Y.1711 to anything it should be to 
> LSP-Ping say.  However, I see these as complimentary 
> functions;  and its clear from what Maarten writes below he 
> shares this view.
> 
> regards, Neil
> 
> > -----Original Message-----
> > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of
> > Maarten.Vissers@alcatel.de
> > Sent: 11 December 2003 11:45
> > To: stbryant@cisco.com
> > Cc: pwe3@ietf.org
> > Subject: [PWE3] PW functional model and its OAM [was: FCS 
> retention in
> > PWE3]
> > 
> > 
> > Stewart,
> > 
> > > VCCV is the only method that has been formally accepted 
> bt the PWE3
> > > WG for further study. If you think that Y.1711 is more 
> appropriate,
> > > please write a draft explaining how this works in the PWE3 
> > context and
> > > why it is better. The WG will then decide the way forward through
> > > our normal process.
> > 
> > 
> > The G.805/G.809 based functional model for an Ethernet over MPLS 
> > connection will [likely] contain: an MPLS/ETH_A (adaptation) 
> > function that 
> > is connected to an MPLS_TT (trail termination) function:
> > 
> >                    |
> >                    O ETH_FP (flow point, see G.8010)
> >                    |
> >            ----------------
> >             \ MPLS/ETH_A /  Encapsulation of ETH MAC frame
> >              ------------   into MPLS packet payload
> >                    |
> >                    O MPLS_AP (access point)
> >                    |
> >               -----------
> >                \MPLS_TT/    Y.1711 OAM (e.g. CV, BDI, FDI)
> >                 \     /
> >                  \   /
> >                   \ /
> >                    |
> >                    O MPLS_TCP (termination connecction point)
> >                    |
> >        other MPLS functions, or
> >        Server/MPLS_A function
> >  
> > The MPLS/ETH adaptation function encapsulates the ETH MAC 
> > frames into the 
> > MPLS packet payload (PW). The MPLS trail termination 
> function is the 
> > endpoint of the MPLS Maintenance Entity (i.e. trail) and has 
> > associated 
> > with it MPLS OAM to perform pro-active fault management (e.g. 
> > using Y.1711 
> > MPLS-CV, MPLS-BDI, MPLS-FDI) or on-demand fault 
> localisation for the 
> > network connection (X-to-Y in figure below).
> > 
> > On-demand fault localisation OAM (e.g. loopback/ping, 
> > traceroute) may also 
> > be sourced/sinked in MPLS test trail termination functions 
> > (centralised 
> > function in a node), which may be connected to the MPLS 
> > serial compound 
> > link connection (between ingress and egress PE: K-to-L in 
> > figure below). 
> > In this case the connections through the first and last 
> > fabrics ((a) in 
> > MPLS connection functions in figure below) are not monitored.
> > 
> > 
> >              Ingress PE
> > <-------------------------------->
> >               -----------
> >                \  MPLS /  on-demand
> >                 \ Test/   MPLS OAM
> >                  \   /
> >                   \ /
> >                    |
> >     pro-act.       O
> >     MPLS OAM       |
> >      |\     -----------   |\
> >      |M\    |   (b)|  | K | \
> >      |P \ X |      \  |-O-|  |     MPLS
> >   -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
> >      |S /   |  (a)    |-O-|  |             |
> >      | /    |         |   | /              |
> >      |/     -----------   |/               |
> >          MPLS Conn. funct.                 |
> >                                            |
> >                                            |
> >          MPLS Conn. funct.                 |
> >      |\     -----------   |\               |
> >      |M\    |         | L | \              |
> >      |P \ Y |  (a)    |-O-|  |     MPLS    |
> >   -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
> >      |S /   |       / |-O-|  |
> >      | /    |   (b)|  |   | /
> >      |/     -----------   |/
> >     pro-act.       |
> >     MPLS OAM       O
> >                    |
> >                   / \
> >                  /   \
> >                 / MPLS\   on-demand
> >                /  Test \  MPLS OAM
> >               -----------
> > <--------------------------------> 
> >               Egress PE
> > 
> > 
> > Based on the functional model of a pseudowire, the presence 
> > of Y.1711 as 
> > MPLS OAM standard and the default allocation of certains 
> > types of [MPLS] 
> > OAM to [MPLS] trail termination functions, one may conclude 
> > that Y.1711 is 
> > already an existing alternative in the fault management and 
> > performance 
> > monitoring of a MPLS based pseudowire (which is a client 
> > layer-network 
> > link supported by a MPLS trail).
> > 
> > Regards,
> > Maarten
> > 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > Maarten Vissers
> > Network and Product Strategy - Optical Networks Division
> > Alcatel SEL AG 
> > Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
> > Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The 
> Netherlands
> > Mobile: +31 65 141 8140
> > Email:Maarten.Vissers@alcatel.de
> > 
> > 
> > 
> > 
> > 
> > Stewart Bryant <stbryant@cisco.com>
> > Sent by: pwe3-admin@ietf.org
> > 01-12-2003 11:31
> > Please respond to stbryant
> > 
> >  
> >         To:     neil.2.harrison@bt.com
> >         cc:     pwe3@ietf.org
> >         Subject:        Re: [PWE3] FCS retention in PWE3
> > 
> > 
> > 
> > 
> > neil.2.harrison@bt.com wrote:
> > 
> > > Stwart,
> > > 
> > > In general I agree with you.  But what you are actually saying 
> > > here is that we want independent OAM in each layer network (simply
> > > has to be independent....one reason being that we want the *same*
> > > OAM solution in the server irrespective of its client). 
> > 
> > Independent yes. Same depends on whether there are any differences
> > in the requirement that suggest otherwise, but I agree same would
> > be a good thing.
> > 
> > > But please note this:
> > > -              a PW is not a layer network, ie we do not 
> > network/switch 
> > PW entities;
> > 
> > I am not sure about this. Logically what we are doing is to recurse
> > back to a lower layer, over which we could run for example 
> a new IGP.
> > In as much as we network/switch wires, we network/switch PWs.
> > 
> > > -              an LSP is a layer network, ie we do 
> > network/switch LSP 
> > entities;
> > > -              why can't we use Y.1711 OAM on the top 
> level p2p LSP?
> > 
> > VCCV is the only method that has been formally accepted bt the PWE3
> > WG for further study. If you think that Y.1711 is more appropriate,
> > please write a draft explaining how this works in the PWE3 
> context and
> > why it is better. The WG will then decide the way forward through
> > our normal process.
> > 
> > > -              Y.1711 is sparse/simple/complete, ie all 
> defects are 
> > defined 
> >          with entry-exit criteria and consequent actions.....it even
> >          defines availability and does so in order it can be used a
> >          single-ended way, ie behaviour of both directions can be
> >          observed from 1 end.
> > 
> > > -              MPLS and ATM OAM layer I/W is already defined in 
> > Y.1712.....
> >          and again its really simple.
> > 
> >          I thought that we were talking about Ethernet here?
> > > 
> > > None of this is done (and in some cases is not appropriate) for 
> > > the VCCV approach. 
> > 
> > I which case the VCCV team need to either provide these or explain
> > why they are not needed.
> > 
> > > 
> > > So what is wrong with this solution?
> > 
> > There is no WG draft describing the applicability of Y.1711 to PWE3.
> > If you want that solution, then you have to run the normal IETF
> > process to get it adopted, which will involve writing a draft,
> > getting it accepted by the WG, and going through a point by point
> > analysis of the advantages and disadvantages of Y.1711 and VCCV.
> > 
> > Regards
> > 
> > Stewart
> > 
> > 
> > 
> > 
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> > 
> > 
> > 
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in PWE3]
Date: Thu, 11 Dec 2003 11:27:14 -0500
Organization: Cisco Systems, inc.
Lines: 250
Sender: pwe3-admin@ietf.org
References: <OF442262AD.8D7AD990-ONC1256DF9.003A010D@netfr.alcatel.fr>
Reply-To: <tnadeau@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Thu Dec 11 17:28:24 2003
Return-path: <pwe3-admin@ietf.org>
To: <Maarten.Vissers@alcatel.de>, <stbryant@cisco.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <OF442262AD.8D7AD990-ONC1256DF9.003A010D@netfr.alcatel.fr>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


	Martin,

	It seems that you are claiming that the
G.805/809 model should be our reference model for
PWE3 as you are pointing out deficiencies in the 
coverage of current OAM tools created by the PWE3 WG.  
I think the larger question we should be asking
is whether or not the IETF PWE3 WG accepts the model from 
G.805/809 to be the model we will use for the PWE3 architecture.  
Since we already have an architecture document that last
time I checked, was pretty complete, I think it is worth hearing 
from the chairs/ADs on this issue to give us some direction 
on how to consider the G.805 model in the context of PWE3.

	--Tom



>-----Original Message-----
>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On 
>Behalf Of Maarten.Vissers@alcatel.de
>Sent: Thursday, December 11, 2003 6:45 AM
>To: stbryant@cisco.com
>Cc: pwe3@ietf.org
>Subject: [PWE3] PW functional model and its OAM [was: FCS 
>retention in PWE3]
>
>
>Stewart,
>
>> VCCV is the only method that has been formally accepted bt the PWE3
>> WG for further study. If you think that Y.1711 is more appropriate,
>> please write a draft explaining how this works in the PWE3 
>context and
>> why it is better. The WG will then decide the way forward through
>> our normal process.
>
>
>The G.805/G.809 based functional model for an Ethernet over MPLS 
>connection will [likely] contain: an MPLS/ETH_A (adaptation) 
>function that 
>is connected to an MPLS_TT (trail termination) function:
>
>                   |
>                   O ETH_FP (flow point, see G.8010)
>                   |
>           ----------------
>            \ MPLS/ETH_A /  Encapsulation of ETH MAC frame
>             ------------   into MPLS packet payload
>                   |
>                   O MPLS_AP (access point)
>                   |
>              -----------
>               \MPLS_TT/    Y.1711 OAM (e.g. CV, BDI, FDI)
>                \     /
>                 \   /
>                  \ /
>                   |
>                   O MPLS_TCP (termination connecction point)
>                   |
>       other MPLS functions, or
>       Server/MPLS_A function
> 
>The MPLS/ETH adaptation function encapsulates the ETH MAC 
>frames into the 
>MPLS packet payload (PW). The MPLS trail termination function is the 
>endpoint of the MPLS Maintenance Entity (i.e. trail) and has 
>associated 
>with it MPLS OAM to perform pro-active fault management (e.g. 
>using Y.1711 
>MPLS-CV, MPLS-BDI, MPLS-FDI) or on-demand fault localisation for the 
>network connection (X-to-Y in figure below).
>
>On-demand fault localisation OAM (e.g. loopback/ping, 
>traceroute) may also 
>be sourced/sinked in MPLS test trail termination functions 
>(centralised 
>function in a node), which may be connected to the MPLS serial 
>compound 
>link connection (between ingress and egress PE: K-to-L in 
>figure below). 
>In this case the connections through the first and last 
>fabrics ((a) in 
>MPLS connection functions in figure below) are not monitored.
>
>
>             Ingress PE
><-------------------------------->
>              -----------
>               \  MPLS /  on-demand
>                \ Test/   MPLS OAM
>                 \   /
>                  \ /
>                   |
>    pro-act.       O
>    MPLS OAM       |
>     |\     -----------   |\
>     |M\    |   (b)|  | K | \
>     |P \ X |      \  |-O-|  |     MPLS
>  -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
>     |S /   |  (a)    |-O-|  |             |
>     | /    |         |   | /              |
>     |/     -----------   |/               |
>         MPLS Conn. funct.                 |
>                                           |
>                                           |
>         MPLS Conn. funct.                 |
>     |\     -----------   |\               |
>     |M\    |         | L | \              |
>     |P \ Y |  (a)    |-O-|  |     MPLS    |
>  -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
>     |S /   |       / |-O-|  |
>     | /    |   (b)|  |   | /
>     |/     -----------   |/
>    pro-act.       |
>    MPLS OAM       O
>                   |
>                  / \
>                 /   \
>                / MPLS\   on-demand
>               /  Test \  MPLS OAM
>              -----------
><--------------------------------> 
>              Egress PE
>
>
>Based on the functional model of a pseudowire, the presence of 
>Y.1711 as 
>MPLS OAM standard and the default allocation of certains types 
>of [MPLS] 
>OAM to [MPLS] trail termination functions, one may conclude 
>that Y.1711 is 
>already an existing alternative in the fault management and 
>performance 
>monitoring of a MPLS based pseudowire (which is a client layer-network 
>link supported by a MPLS trail).
>
>Regards,
>Maarten
>
>
>
>---------------------------------------------------------------------
>Maarten Vissers
>Network and Product Strategy - Optical Networks Division
>Alcatel SEL AG 
>Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
>Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
>Mobile: +31 65 141 8140
>Email:Maarten.Vissers@alcatel.de
>
>
>
>
>
>Stewart Bryant <stbryant@cisco.com>
>Sent by: pwe3-admin@ietf.org
>01-12-2003 11:31
>Please respond to stbryant
>
> 
>        To:     neil.2.harrison@bt.com
>        cc:     pwe3@ietf.org
>        Subject:        Re: [PWE3] FCS retention in PWE3
>
>
>
>
>neil.2.harrison@bt.com wrote:
>
>> Stwart,
>> 
>> In general I agree with you.  But what you are actually saying 
>> here is that we want independent OAM in each layer network (simply
>> has to be independent....one reason being that we want the *same*
>> OAM solution in the server irrespective of its client). 
>
>Independent yes. Same depends on whether there are any differences
>in the requirement that suggest otherwise, but I agree same would
>be a good thing.
>
>> But please note this:
>> -              a PW is not a layer network, ie we do not 
>network/switch 
>PW entities;
>
>I am not sure about this. Logically what we are doing is to recurse
>back to a lower layer, over which we could run for example a new IGP.
>In as much as we network/switch wires, we network/switch PWs.
>
>> -              an LSP is a layer network, ie we do 
>network/switch LSP 
>entities;
>> -              why can't we use Y.1711 OAM on the top level p2p LSP?
>
>VCCV is the only method that has been formally accepted bt the PWE3
>WG for further study. If you think that Y.1711 is more appropriate,
>please write a draft explaining how this works in the PWE3 context and
>why it is better. The WG will then decide the way forward through
>our normal process.
>
>> -              Y.1711 is sparse/simple/complete, ie all defects are 
>defined 
>         with entry-exit criteria and consequent actions.....it even
>         defines availability and does so in order it can be used a
>         single-ended way, ie behaviour of both directions can be
>         observed from 1 end.
>
>> -              MPLS and ATM OAM layer I/W is already defined in 
>Y.1712.....
>         and again its really simple.
>
>         I thought that we were talking about Ethernet here?
>> 
>> None of this is done (and in some cases is not appropriate) for 
>> the VCCV approach. 
>
>I which case the VCCV team need to either provide these or explain
>why they are not needed.
>
>> 
>> So what is wrong with this solution?
>
>There is no WG draft describing the applicability of Y.1711 to PWE3.
>If you want that solution, then you have to run the normal IETF
>process to get it adopted, which will involve writing a draft,
>getting it accepted by the WG, and going through a point by point
>analysis of the advantages and disadvantages of Y.1711 and VCCV.
>
>Regards
>
>Stewart
>
>
>
>
>_______________________________________________
>pwe3 mailing list
>pwe3@ietf.org
>https://www1.ietf.org/mailman/listinfo/pwe3
>
>
>
>
>_______________________________________________
>pwe3 mailing list
>pwe3@ietf.org
>https://www1.ietf.org/mailman/listinfo/pwe3
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: neil.2.harrison@bt.com
Subject: RE: PW functional model and its OAM [was: FCS retention in PWE3]
Date: Thu, 11 Dec 2003 16:54:17 -0000
Lines: 367
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Thu Dec 11 17:55:10 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
Thread-Topic: [PWE3] PW functional model and its OAM [was: FCS retention in PWE3]
Thread-Index: AcPAAE6E9TTLr638TXK5ATp1sZ7TzwAAdZ4g
To: <busschbach@lucent.com>, <Maarten.Vissers@alcatel.de>,
        <stbryant@cisco.com>
X-OriginalArrivalTime: 11 Dec 2003 16:54:17.0860 (UTC) FILETIME=[6A61BC40:01C3C007]
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Busschbach, Peter B (Peter) wrote 11 December 2003 15:55
Peter, please see below:
>=20
> Neil,
>=20
> You seem to suggest that VCCV is has client-specific=20
> elements. I don't see that. Could you explain what in the=20
> VCCV draft is client-specific?
>=20
> Thanks,
>=20
> Peter

NH=3D> Sorry if I did not explain this well enough.  Let me have another =
go.  We have some client X and some server Y.  X and Y should have their =
own OAM that is independent....hopefully that is an obvious requirement. =
 Note - this observation is pertinent to all layers networks, not just =
the case here.=20

PWs add an adapation function between X and Y.  Some elements of the PW =
adaptation are client specific.

Now:
-	from the 1st observation above, the OAM of X and Y should be present =
irrespective of any PW adapation function.....one wants these generic =
for *all* cases;
-	VCCV puts some additional PW generic OAM in the PW adaptation =
function....but this is a strange thing to do architecturally if X and Y =
are properly specified in the 1st place;
-	and some client specific adaptations (I quoted the TDM client case) =
are adding further client specific OAM, ie the L and R flags I =
mentioned.

Hopefully that makes what I was saying clear.

There is, of course, more to the complete picture that.  One needs a =
very clear view of the overall layered relationships to get the defect =
handling right.....the func arch stuff Maarten was depicting is =
excellent for understanding this and avoiding mistakes.

Y.1711 was carefully written to be as simple and complete as possible, =
ie attention was paid from the outset to make sure all defects had =
automatic defect detection/handling.  I don't see any of this level of =
detail elsewhere.

Further, it also considers the mapping of defects arising below the MPLS =
layer into MPLS FDI to *suppress* MPLS layer alarms being raised....and =
this must recurse up through any nested LSPs up to the client's FDI =
where this is appropriate (else we get alarm storms all the way =
up....not a nice thing operationally).  I don't see any of this having =
been thought about either.

However, I do understand *why* this can't easily be sorted....it =
basically boils down to:
-	IP and MPLS are not the same network mode....and the fact that they =
are not is what gives each unique value....so the adapation (and other =
things like OAM) does not have to be the same.  However, I know this is =
anti-religious talk so I'll park that one here.
-	MPLS pkts use label swapping and thus have a forwarding behaviour (and =
defect behaviour) that belongs to the co-ps mode....it does not use full =
DA/SA identifiers in the pkts as a true cnls mode requires.  This means =
the topology constructs that should be used with this mode are p2p and =
p2mp....step outside that and you get problems elsewhere.....fault =
management being one of them.=20

In closing Y.1711 was written by an operator with a strong background in =
functional arch.....but hey, what do we know about this stuff ;-)

regards, Neil
>=20
> > -----Original Message-----
> > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> > Sent: Thursday, December 11, 2003 9:40 AM
> > To: Maarten.Vissers@alcatel.de; stbryant@cisco.com
> > Cc: pwe3@ietf.org
> > Subject: RE: [PWE3] PW functional model and its OAM [was: FCS=20
> > retention
> > in PWE3]
> >=20
> >=20
> > Thanks Maarten....that seems pretty-well spot-on.  And yes,=20
> > your diagrams clearly show that the PW is an adaptation=20
> > function that lies above the MPLS layer network.  So VCCV and=20
> > Y.1711 are not operating in the same space and thus it is=20
> > technically incorrect to try and compare them.....that is:
> > -	VCCV is defining some OAM function that is specific to=20
> > a PW adaptation function (rather odd architecturally=20
> > however...also see Note);
> > -	whilst Y.1711 is generic and operates in the MPLS layer=20
> > network irrespective of the client.
> >=20
> > Note - In the draft draft-ietf-pwe3-satop-00.txt one will=20
> > also find some specific client/PW case OAM functions....here=20
> > for a certain type of TDM client, ie the 'L' and 'R' bits.
> >=20
> > The key point however, is that MPLS OAM should be generic=20
> > irrespective of the client, and it should not be a function=20
> > of the client adaptation function but only of the MPLS trail=20
> > termination function as Maarten correctly identifies below.
> >=20
> > So, if one is to compare Y.1711 to anything it should be to=20
> > LSP-Ping say.  However, I see these as complimentary=20
> > functions;  and its clear from what Maarten writes below he=20
> > shares this view.
> >=20
> > regards, Neil
> >=20
> > > -----Original Message-----
> > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of
> > > Maarten.Vissers@alcatel.de
> > > Sent: 11 December 2003 11:45
> > > To: stbryant@cisco.com
> > > Cc: pwe3@ietf.org
> > > Subject: [PWE3] PW functional model and its OAM [was: FCS=20
> > retention in
> > > PWE3]
> > >=20
> > >=20
> > > Stewart,
> > >=20
> > > > VCCV is the only method that has been formally accepted=20
> > bt the PWE3
> > > > WG for further study. If you think that Y.1711 is more=20
> > appropriate,
> > > > please write a draft explaining how this works in the PWE3=20
> > > context and
> > > > why it is better. The WG will then decide the way=20
> forward through
> > > > our normal process.
> > >=20
> > >=20
> > > The G.805/G.809 based functional model for an Ethernet over MPLS=20
> > > connection will [likely] contain: an MPLS/ETH_A (adaptation)=20
> > > function that=20
> > > is connected to an MPLS_TT (trail termination) function:
> > >=20
> > >                    |
> > >                    O ETH_FP (flow point, see G.8010)
> > >                    |
> > >            ----------------
> > >             \ MPLS/ETH_A /  Encapsulation of ETH MAC frame
> > >              ------------   into MPLS packet payload
> > >                    |
> > >                    O MPLS_AP (access point)
> > >                    |
> > >               -----------
> > >                \MPLS_TT/    Y.1711 OAM (e.g. CV, BDI, FDI)
> > >                 \     /
> > >                  \   /
> > >                   \ /
> > >                    |
> > >                    O MPLS_TCP (termination connecction point)
> > >                    |
> > >        other MPLS functions, or
> > >        Server/MPLS_A function
> > > =20
> > > The MPLS/ETH adaptation function encapsulates the ETH MAC=20
> > > frames into the=20
> > > MPLS packet payload (PW). The MPLS trail termination=20
> > function is the=20
> > > endpoint of the MPLS Maintenance Entity (i.e. trail) and has=20
> > > associated=20
> > > with it MPLS OAM to perform pro-active fault management (e.g.=20
> > > using Y.1711=20
> > > MPLS-CV, MPLS-BDI, MPLS-FDI) or on-demand fault=20
> > localisation for the=20
> > > network connection (X-to-Y in figure below).
> > >=20
> > > On-demand fault localisation OAM (e.g. loopback/ping,=20
> > > traceroute) may also=20
> > > be sourced/sinked in MPLS test trail termination functions=20
> > > (centralised=20
> > > function in a node), which may be connected to the MPLS=20
> > > serial compound=20
> > > link connection (between ingress and egress PE: K-to-L in=20
> > > figure below).=20
> > > In this case the connections through the first and last=20
> > > fabrics ((a) in=20
> > > MPLS connection functions in figure below) are not monitored.
> > >=20
> > >=20
> > >              Ingress PE
> > > <-------------------------------->
> > >               -----------
> > >                \  MPLS /  on-demand
> > >                 \ Test/   MPLS OAM
> > >                  \   /
> > >                   \ /
> > >                    |
> > >     pro-act.       O
> > >     MPLS OAM       |
> > >      |\     -----------   |\
> > >      |M\    |   (b)|  | K | \
> > >      |P \ X |      \  |-O-|  |     MPLS
> > >   -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
> > >      |S /   |  (a)    |-O-|  |             |
> > >      | /    |         |   | /              |
> > >      |/     -----------   |/               |
> > >          MPLS Conn. funct.                 |
> > >                                            |
> > >                                            |
> > >          MPLS Conn. funct.                 |
> > >      |\     -----------   |\               |
> > >      |M\    |         | L | \              |
> > >      |P \ Y |  (a)    |-O-|  |     MPLS    |
> > >   -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
> > >      |S /   |       / |-O-|  |
> > >      | /    |   (b)|  |   | /
> > >      |/     -----------   |/
> > >     pro-act.       |
> > >     MPLS OAM       O
> > >                    |
> > >                   / \
> > >                  /   \
> > >                 / MPLS\   on-demand
> > >                /  Test \  MPLS OAM
> > >               -----------
> > > <-------------------------------->=20
> > >               Egress PE
> > >=20
> > >=20
> > > Based on the functional model of a pseudowire, the presence=20
> > > of Y.1711 as=20
> > > MPLS OAM standard and the default allocation of certains=20
> > > types of [MPLS]=20
> > > OAM to [MPLS] trail termination functions, one may conclude=20
> > > that Y.1711 is=20
> > > already an existing alternative in the fault management and=20
> > > performance=20
> > > monitoring of a MPLS based pseudowire (which is a client=20
> > > layer-network=20
> > > link supported by a MPLS trail).
> > >=20
> > > Regards,
> > > Maarten
> > >=20
> > >=20
> > >=20
> > >=20
> >=20
> ---------------------------------------------------------------------
> > > Maarten Vissers
> > > Network and Product Strategy - Optical Networks Division
> > > Alcatel SEL AG=20
> > > Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
> > > Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The=20
> > Netherlands
> > > Mobile: +31 65 141 8140
> > > Email:Maarten.Vissers@alcatel.de
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > > Stewart Bryant <stbryant@cisco.com>
> > > Sent by: pwe3-admin@ietf.org
> > > 01-12-2003 11:31
> > > Please respond to stbryant
> > >=20
> > > =20
> > >         To:     neil.2.harrison@bt.com
> > >         cc:     pwe3@ietf.org
> > >         Subject:        Re: [PWE3] FCS retention in PWE3
> > >=20
> > >=20
> > >=20
> > >=20
> > > neil.2.harrison@bt.com wrote:
> > >=20
> > > > Stwart,
> > > >=20
> > > > In general I agree with you.  But what you are actually saying=20
> > > > here is that we want independent OAM in each layer=20
> network (simply
> > > > has to be independent....one reason being that we want=20
> the *same*
> > > > OAM solution in the server irrespective of its client).=20
> > >=20
> > > Independent yes. Same depends on whether there are any differences
> > > in the requirement that suggest otherwise, but I agree same would
> > > be a good thing.
> > >=20
> > > > But please note this:
> > > > -              a PW is not a layer network, ie we do not=20
> > > network/switch=20
> > > PW entities;
> > >=20
> > > I am not sure about this. Logically what we are doing is=20
> to recurse
> > > back to a lower layer, over which we could run for example=20
> > a new IGP.
> > > In as much as we network/switch wires, we network/switch PWs.
> > >=20
> > > > -              an LSP is a layer network, ie we do=20
> > > network/switch LSP=20
> > > entities;
> > > > -              why can't we use Y.1711 OAM on the top=20
> > level p2p LSP?
> > >=20
> > > VCCV is the only method that has been formally accepted=20
> bt the PWE3
> > > WG for further study. If you think that Y.1711 is more=20
> appropriate,
> > > please write a draft explaining how this works in the PWE3=20
> > context and
> > > why it is better. The WG will then decide the way forward through
> > > our normal process.
> > >=20
> > > > -              Y.1711 is sparse/simple/complete, ie all=20
> > defects are=20
> > > defined=20
> > >          with entry-exit criteria and consequent=20
> actions.....it even
> > >          defines availability and does so in order it can=20
> be used a
> > >          single-ended way, ie behaviour of both directions can be
> > >          observed from 1 end.
> > >=20
> > > > -              MPLS and ATM OAM layer I/W is already defined in=20
> > > Y.1712.....
> > >          and again its really simple.
> > >=20
> > >          I thought that we were talking about Ethernet here?
> > > >=20
> > > > None of this is done (and in some cases is not appropriate) for=20
> > > > the VCCV approach.=20
> > >=20
> > > I which case the VCCV team need to either provide these or explain
> > > why they are not needed.
> > >=20
> > > >=20
> > > > So what is wrong with this solution?
> > >=20
> > > There is no WG draft describing the applicability of=20
> Y.1711 to PWE3.
> > > If you want that solution, then you have to run the normal IETF
> > > process to get it adopted, which will involve writing a draft,
> > > getting it accepted by the WG, and going through a point by point
> > > analysis of the advantages and disadvantages of Y.1711 and VCCV.
> > >=20
> > > Regards
> > >=20
> > > Stewart
> > >=20
> > >=20
> > >=20
> > >=20
> > > _______________________________________________
> > > pwe3 mailing list
> > > pwe3@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/pwe3
> > >=20
> > >=20
> > >=20
> > >=20
> > > _______________________________________________
> > > pwe3 mailing list
> > > pwe3@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/pwe3
> > >=20
> >=20
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >=20
>=20


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: neil.2.harrison@bt.com
Subject: RE: PW functional model and its OAM [was: FCS retention in PWE3]
Date: Thu, 11 Dec 2003 17:35:06 -0000
Lines: 294
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Thu Dec 11 18:36:09 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
Thread-Topic: [PWE3] PW functional model and its OAM [was: FCS retention in PWE3]
Thread-Index: AcPABMVFASqBoxpdTla4JLt8QtvsHwAAzKng
To: <tnadeau@cisco.com>, <Maarten.Vissers@alcatel.de>, <stbryant@cisco.com>
X-OriginalArrivalTime: 11 Dec 2003 17:35:07.0693 (UTC) FILETIME=[1E9895D0:01C3C00D]
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Tom,

It does not matter what folk's opinions are on whether they recognise =
G.805 and G.809 or not here.....as they are simply a formal language =
that unambiguously describe networks.  Whether one chooses to use them =
or not is their business....that does not diminish their intrinsic =
'truth'.

We have been using them for years however, and if they did not work or =
did not have value would not have done so. You obviously don't believe =
they are useful.  However I, as an operator, do value them because when =
architectural mistakes and violations occur these ultimately usually =
mean some cost to us.....using functional modelling means we can =
identify these issues up-front and not make these mistakes.  They are =
also invaluable for creating management information models.....also very =
important for operational/network-management reasons. That may or =
may-not strike a chord with you.

regards, Neil
BT/GS CTO

> -----Original Message-----
> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of
> Thomas D. Nadeau
> Sent: 11 December 2003 16:27
> To: Maarten.Vissers@alcatel.de; stbryant@cisco.com
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PW functional model and its OAM [was: FCS=20
> retention
> in PWE3]
>=20
>=20
>=20
> 	Martin,
>=20
> 	It seems that you are claiming that the
> G.805/809 model should be our reference model for
> PWE3 as you are pointing out deficiencies in the=20
> coverage of current OAM tools created by the PWE3 WG. =20
> I think the larger question we should be asking
> is whether or not the IETF PWE3 WG accepts the model from=20
> G.805/809 to be the model we will use for the PWE3 architecture. =20
> Since we already have an architecture document that last
> time I checked, was pretty complete, I think it is worth hearing=20
> from the chairs/ADs on this issue to give us some direction=20
> on how to consider the G.805 model in the context of PWE3.
>=20
> 	--Tom
>=20
>=20
>=20
> >-----Original Message-----
> >From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On=20
> >Behalf Of Maarten.Vissers@alcatel.de
> >Sent: Thursday, December 11, 2003 6:45 AM
> >To: stbryant@cisco.com
> >Cc: pwe3@ietf.org
> >Subject: [PWE3] PW functional model and its OAM [was: FCS=20
> >retention in PWE3]
> >
> >
> >Stewart,
> >
> >> VCCV is the only method that has been formally accepted bt the PWE3
> >> WG for further study. If you think that Y.1711 is more appropriate,
> >> please write a draft explaining how this works in the PWE3=20
> >context and
> >> why it is better. The WG will then decide the way forward through
> >> our normal process.
> >
> >
> >The G.805/G.809 based functional model for an Ethernet over MPLS=20
> >connection will [likely] contain: an MPLS/ETH_A (adaptation)=20
> >function that=20
> >is connected to an MPLS_TT (trail termination) function:
> >
> >                   |
> >                   O ETH_FP (flow point, see G.8010)
> >                   |
> >           ----------------
> >            \ MPLS/ETH_A /  Encapsulation of ETH MAC frame
> >             ------------   into MPLS packet payload
> >                   |
> >                   O MPLS_AP (access point)
> >                   |
> >              -----------
> >               \MPLS_TT/    Y.1711 OAM (e.g. CV, BDI, FDI)
> >                \     /
> >                 \   /
> >                  \ /
> >                   |
> >                   O MPLS_TCP (termination connecction point)
> >                   |
> >       other MPLS functions, or
> >       Server/MPLS_A function
> >=20
> >The MPLS/ETH adaptation function encapsulates the ETH MAC=20
> >frames into the=20
> >MPLS packet payload (PW). The MPLS trail termination function is the=20
> >endpoint of the MPLS Maintenance Entity (i.e. trail) and has=20
> >associated=20
> >with it MPLS OAM to perform pro-active fault management (e.g.=20
> >using Y.1711=20
> >MPLS-CV, MPLS-BDI, MPLS-FDI) or on-demand fault localisation for the=20
> >network connection (X-to-Y in figure below).
> >
> >On-demand fault localisation OAM (e.g. loopback/ping,=20
> >traceroute) may also=20
> >be sourced/sinked in MPLS test trail termination functions=20
> >(centralised=20
> >function in a node), which may be connected to the MPLS serial=20
> >compound=20
> >link connection (between ingress and egress PE: K-to-L in=20
> >figure below).=20
> >In this case the connections through the first and last=20
> >fabrics ((a) in=20
> >MPLS connection functions in figure below) are not monitored.
> >
> >
> >             Ingress PE
> ><-------------------------------->
> >              -----------
> >               \  MPLS /  on-demand
> >                \ Test/   MPLS OAM
> >                 \   /
> >                  \ /
> >                   |
> >    pro-act.       O
> >    MPLS OAM       |
> >     |\     -----------   |\
> >     |M\    |   (b)|  | K | \
> >     |P \ X |      \  |-O-|  |     MPLS
> >  -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
> >     |S /   |  (a)    |-O-|  |             |
> >     | /    |         |   | /              |
> >     |/     -----------   |/               |
> >         MPLS Conn. funct.                 |
> >                                           |
> >                                           |
> >         MPLS Conn. funct.                 |
> >     |\     -----------   |\               |
> >     |M\    |         | L | \              |
> >     |P \ Y |  (a)    |-O-|  |     MPLS    |
> >  -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
> >     |S /   |       / |-O-|  |
> >     | /    |   (b)|  |   | /
> >     |/     -----------   |/
> >    pro-act.       |
> >    MPLS OAM       O
> >                   |
> >                  / \
> >                 /   \
> >                / MPLS\   on-demand
> >               /  Test \  MPLS OAM
> >              -----------
> ><-------------------------------->=20
> >              Egress PE
> >
> >
> >Based on the functional model of a pseudowire, the presence of=20
> >Y.1711 as=20
> >MPLS OAM standard and the default allocation of certains types=20
> >of [MPLS]=20
> >OAM to [MPLS] trail termination functions, one may conclude=20
> >that Y.1711 is=20
> >already an existing alternative in the fault management and=20
> >performance=20
> >monitoring of a MPLS based pseudowire (which is a client=20
> layer-network=20
> >link supported by a MPLS trail).
> >
> >Regards,
> >Maarten
> >
> >
> >
> >---------------------------------------------------------------------
> >Maarten Vissers
> >Network and Product Strategy - Optical Networks Division
> >Alcatel SEL AG=20
> >Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
> >Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The=20
> Netherlands
> >Mobile: +31 65 141 8140
> >Email:Maarten.Vissers@alcatel.de
> >
> >
> >
> >
> >
> >Stewart Bryant <stbryant@cisco.com>
> >Sent by: pwe3-admin@ietf.org
> >01-12-2003 11:31
> >Please respond to stbryant
> >
> >=20
> >        To:     neil.2.harrison@bt.com
> >        cc:     pwe3@ietf.org
> >        Subject:        Re: [PWE3] FCS retention in PWE3
> >
> >
> >
> >
> >neil.2.harrison@bt.com wrote:
> >
> >> Stwart,
> >>=20
> >> In general I agree with you.  But what you are actually saying=20
> >> here is that we want independent OAM in each layer network (simply
> >> has to be independent....one reason being that we want the *same*
> >> OAM solution in the server irrespective of its client).=20
> >
> >Independent yes. Same depends on whether there are any differences
> >in the requirement that suggest otherwise, but I agree same would
> >be a good thing.
> >
> >> But please note this:
> >> -              a PW is not a layer network, ie we do not=20
> >network/switch=20
> >PW entities;
> >
> >I am not sure about this. Logically what we are doing is to recurse
> >back to a lower layer, over which we could run for example a new IGP.
> >In as much as we network/switch wires, we network/switch PWs.
> >
> >> -              an LSP is a layer network, ie we do=20
> >network/switch LSP=20
> >entities;
> >> -              why can't we use Y.1711 OAM on the top=20
> level p2p LSP?
> >
> >VCCV is the only method that has been formally accepted bt the PWE3
> >WG for further study. If you think that Y.1711 is more appropriate,
> >please write a draft explaining how this works in the PWE3=20
> context and
> >why it is better. The WG will then decide the way forward through
> >our normal process.
> >
> >> -              Y.1711 is sparse/simple/complete, ie all=20
> defects are=20
> >defined=20
> >         with entry-exit criteria and consequent actions.....it even
> >         defines availability and does so in order it can be used a
> >         single-ended way, ie behaviour of both directions can be
> >         observed from 1 end.
> >
> >> -              MPLS and ATM OAM layer I/W is already defined in=20
> >Y.1712.....
> >         and again its really simple.
> >
> >         I thought that we were talking about Ethernet here?
> >>=20
> >> None of this is done (and in some cases is not appropriate) for=20
> >> the VCCV approach.=20
> >
> >I which case the VCCV team need to either provide these or explain
> >why they are not needed.
> >
> >>=20
> >> So what is wrong with this solution?
> >
> >There is no WG draft describing the applicability of Y.1711 to PWE3.
> >If you want that solution, then you have to run the normal IETF
> >process to get it adopted, which will involve writing a draft,
> >getting it accepted by the WG, and going through a point by point
> >analysis of the advantages and disadvantages of Y.1711 and VCCV.
> >
> >Regards
> >
> >Stewart
> >
> >
> >
> >
> >_______________________________________________
> >pwe3 mailing list
> >pwe3@ietf.org
> >https://www1.ietf.org/mailman/listinfo/pwe3
> >
> >
> >
> >
> >_______________________________________________
> >pwe3 mailing list
> >pwe3@ietf.org
> >https://www1.ietf.org/mailman/listinfo/pwe3
> >
>=20
>=20
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>=20


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in
	 PWE3]
Date: Thu, 11 Dec 2003 16:24:15 -0500
Lines: 410
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Thu Dec 11 22:27:08 2003
Return-path: <pwe3-admin@ietf.org>
To: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        Maarten.Vissers@alcatel.de, stbryant@cisco.com
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Thursday, December 11, 2003 11:54 AM
> To: busschbach@lucent.com; Maarten.Vissers@alcatel.de;
> stbryant@cisco.com
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> retention
> in PWE3]
> 
> 
> Busschbach, Peter B (Peter) wrote 11 December 2003 15:55
> Peter, please see below:
> > 
> > Neil,
> > 
> > You seem to suggest that VCCV is has client-specific 
> > elements. I don't see that. Could you explain what in the 
> > VCCV draft is client-specific?
> > 
> > Thanks,
> > 
> > Peter
> 
> NH=> Sorry if I did not explain this well enough.  Let me 
> have another go.  We have some client X and some server Y.  X 
> and Y should have their own OAM that is 
> independent....hopefully that is an obvious requirement.  
> Note - this observation is pertinent to all layers networks, 
> not just the case here. 
> 
> PWs add an adapation function between X and Y.  Some elements 
> of the PW adaptation are client specific.
> 
> Now:
> -	from the 1st observation above, the OAM of X and Y 
> should be present irrespective of any PW adapation 
> function.....one wants these generic for *all* cases;
> -	VCCV puts some additional PW generic OAM in the PW 
> adaptation function....but this is a strange thing to do 
> architecturally if X and Y are properly specified in the 1st place;
> -	and some client specific adaptations (I quoted the TDM 
> client case) are adding further client specific OAM, ie the L 
> and R flags I mentioned.


Neil,

I think your clarification implies that you agree that VCCV is client-layer independent. I agree with you that the SATOP draft seems to violate that separation, but I think that should be raised as an issue against that draft, not against VCCV.

Could you explain why you believe that "VCCV puts some additional PW generic OAM in the PW adaptation function"? The VCCV draft defines how to encapsulate OAM traffic so that it runs over the PW that it is related to. Apart from that, I don't see how VCCV impacts the PW adaptation function.

Peter


> 
> Hopefully that makes what I was saying clear.
> 
> There is, of course, more to the complete picture that.  One 
> needs a very clear view of the overall layered relationships 
> to get the defect handling right.....the func arch stuff 
> Maarten was depicting is excellent for understanding this and 
> avoiding mistakes.
> 
> Y.1711 was carefully written to be as simple and complete as 
> possible, ie attention was paid from the outset to make sure 
> all defects had automatic defect detection/handling.  I don't 
> see any of this level of detail elsewhere.
> 
> Further, it also considers the mapping of defects arising 
> below the MPLS layer into MPLS FDI to *suppress* MPLS layer 
> alarms being raised....and this must recurse up through any 
> nested LSPs up to the client's FDI where this is appropriate 
> (else we get alarm storms all the way up....not a nice thing 
> operationally).  I don't see any of this having been thought 
> about either.
> 
> However, I do understand *why* this can't easily be 
> sorted....it basically boils down to:
> -	IP and MPLS are not the same network mode....and the 
> fact that they are not is what gives each unique value....so 
> the adapation (and other things like OAM) does not have to be 
> the same.  However, I know this is anti-religious talk so 
> I'll park that one here.
> -	MPLS pkts use label swapping and thus have a forwarding 
> behaviour (and defect behaviour) that belongs to the co-ps 
> mode....it does not use full DA/SA identifiers in the pkts as 
> a true cnls mode requires.  This means the topology 
> constructs that should be used with this mode are p2p and 
> p2mp....step outside that and you get problems 
> elsewhere.....fault management being one of them. 
> 
> In closing Y.1711 was written by an operator with a strong 
> background in functional arch.....but hey, what do we know 
> about this stuff ;-)
> 
> regards, Neil
> > 
> > > -----Original Message-----
> > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> > > Sent: Thursday, December 11, 2003 9:40 AM
> > > To: Maarten.Vissers@alcatel.de; stbryant@cisco.com
> > > Cc: pwe3@ietf.org
> > > Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> > > retention
> > > in PWE3]
> > > 
> > > 
> > > Thanks Maarten....that seems pretty-well spot-on.  And yes, 
> > > your diagrams clearly show that the PW is an adaptation 
> > > function that lies above the MPLS layer network.  So VCCV and 
> > > Y.1711 are not operating in the same space and thus it is 
> > > technically incorrect to try and compare them.....that is:
> > > -	VCCV is defining some OAM function that is specific to 
> > > a PW adaptation function (rather odd architecturally 
> > > however...also see Note);
> > > -	whilst Y.1711 is generic and operates in the MPLS layer 
> > > network irrespective of the client.
> > > 
> > > Note - In the draft draft-ietf-pwe3-satop-00.txt one will 
> > > also find some specific client/PW case OAM functions....here 
> > > for a certain type of TDM client, ie the 'L' and 'R' bits.
> > > 
> > > The key point however, is that MPLS OAM should be generic 
> > > irrespective of the client, and it should not be a function 
> > > of the client adaptation function but only of the MPLS trail 
> > > termination function as Maarten correctly identifies below.
> > > 
> > > So, if one is to compare Y.1711 to anything it should be to 
> > > LSP-Ping say.  However, I see these as complimentary 
> > > functions;  and its clear from what Maarten writes below he 
> > > shares this view.
> > > 
> > > regards, Neil
> > > 
> > > > -----Original Message-----
> > > > From: pwe3-admin@ietf.org 
> [mailto:pwe3-admin@ietf.org]On Behalf Of
> > > > Maarten.Vissers@alcatel.de
> > > > Sent: 11 December 2003 11:45
> > > > To: stbryant@cisco.com
> > > > Cc: pwe3@ietf.org
> > > > Subject: [PWE3] PW functional model and its OAM [was: FCS 
> > > retention in
> > > > PWE3]
> > > > 
> > > > 
> > > > Stewart,
> > > > 
> > > > > VCCV is the only method that has been formally accepted 
> > > bt the PWE3
> > > > > WG for further study. If you think that Y.1711 is more 
> > > appropriate,
> > > > > please write a draft explaining how this works in the PWE3 
> > > > context and
> > > > > why it is better. The WG will then decide the way 
> > forward through
> > > > > our normal process.
> > > > 
> > > > 
> > > > The G.805/G.809 based functional model for an Ethernet 
> over MPLS 
> > > > connection will [likely] contain: an MPLS/ETH_A (adaptation) 
> > > > function that 
> > > > is connected to an MPLS_TT (trail termination) function:
> > > > 
> > > >                    |
> > > >                    O ETH_FP (flow point, see G.8010)
> > > >                    |
> > > >            ----------------
> > > >             \ MPLS/ETH_A /  Encapsulation of ETH MAC frame
> > > >              ------------   into MPLS packet payload
> > > >                    |
> > > >                    O MPLS_AP (access point)
> > > >                    |
> > > >               -----------
> > > >                \MPLS_TT/    Y.1711 OAM (e.g. CV, BDI, FDI)
> > > >                 \     /
> > > >                  \   /
> > > >                   \ /
> > > >                    |
> > > >                    O MPLS_TCP (termination connecction point)
> > > >                    |
> > > >        other MPLS functions, or
> > > >        Server/MPLS_A function
> > > >  
> > > > The MPLS/ETH adaptation function encapsulates the ETH MAC 
> > > > frames into the 
> > > > MPLS packet payload (PW). The MPLS trail termination 
> > > function is the 
> > > > endpoint of the MPLS Maintenance Entity (i.e. trail) and has 
> > > > associated 
> > > > with it MPLS OAM to perform pro-active fault management (e.g. 
> > > > using Y.1711 
> > > > MPLS-CV, MPLS-BDI, MPLS-FDI) or on-demand fault 
> > > localisation for the 
> > > > network connection (X-to-Y in figure below).
> > > > 
> > > > On-demand fault localisation OAM (e.g. loopback/ping, 
> > > > traceroute) may also 
> > > > be sourced/sinked in MPLS test trail termination functions 
> > > > (centralised 
> > > > function in a node), which may be connected to the MPLS 
> > > > serial compound 
> > > > link connection (between ingress and egress PE: K-to-L in 
> > > > figure below). 
> > > > In this case the connections through the first and last 
> > > > fabrics ((a) in 
> > > > MPLS connection functions in figure below) are not monitored.
> > > > 
> > > > 
> > > >              Ingress PE
> > > > <-------------------------------->
> > > >               -----------
> > > >                \  MPLS /  on-demand
> > > >                 \ Test/   MPLS OAM
> > > >                  \   /
> > > >                   \ /
> > > >                    |
> > > >     pro-act.       O
> > > >     MPLS OAM       |
> > > >      |\     -----------   |\
> > > >      |M\    |   (b)|  | K | \
> > > >      |P \ X |      \  |-O-|  |     MPLS
> > > >   -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
> > > >      |S /   |  (a)    |-O-|  |             |
> > > >      | /    |         |   | /              |
> > > >      |/     -----------   |/               |
> > > >          MPLS Conn. funct.                 |
> > > >                                            |
> > > >                                            |
> > > >          MPLS Conn. funct.                 |
> > > >      |\     -----------   |\               |
> > > >      |M\    |         | L | \              |
> > > >      |P \ Y |  (a)    |-O-|  |     MPLS    |
> > > >   -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
> > > >      |S /   |       / |-O-|  |
> > > >      | /    |   (b)|  |   | /
> > > >      |/     -----------   |/
> > > >     pro-act.       |
> > > >     MPLS OAM       O
> > > >                    |
> > > >                   / \
> > > >                  /   \
> > > >                 / MPLS\   on-demand
> > > >                /  Test \  MPLS OAM
> > > >               -----------
> > > > <--------------------------------> 
> > > >               Egress PE
> > > > 
> > > > 
> > > > Based on the functional model of a pseudowire, the presence 
> > > > of Y.1711 as 
> > > > MPLS OAM standard and the default allocation of certains 
> > > > types of [MPLS] 
> > > > OAM to [MPLS] trail termination functions, one may conclude 
> > > > that Y.1711 is 
> > > > already an existing alternative in the fault management and 
> > > > performance 
> > > > monitoring of a MPLS based pseudowire (which is a client 
> > > > layer-network 
> > > > link supported by a MPLS trail).
> > > > 
> > > > Regards,
> > > > Maarten
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > > Maarten Vissers
> > > > Network and Product Strategy - Optical Networks Division
> > > > Alcatel SEL AG 
> > > > Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
> > > > Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The 
> > > Netherlands
> > > > Mobile: +31 65 141 8140
> > > > Email:Maarten.Vissers@alcatel.de
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Stewart Bryant <stbryant@cisco.com>
> > > > Sent by: pwe3-admin@ietf.org
> > > > 01-12-2003 11:31
> > > > Please respond to stbryant
> > > > 
> > > >  
> > > >         To:     neil.2.harrison@bt.com
> > > >         cc:     pwe3@ietf.org
> > > >         Subject:        Re: [PWE3] FCS retention in PWE3
> > > > 
> > > > 
> > > > 
> > > > 
> > > > neil.2.harrison@bt.com wrote:
> > > > 
> > > > > Stwart,
> > > > > 
> > > > > In general I agree with you.  But what you are 
> actually saying 
> > > > > here is that we want independent OAM in each layer 
> > network (simply
> > > > > has to be independent....one reason being that we want 
> > the *same*
> > > > > OAM solution in the server irrespective of its client). 
> > > > 
> > > > Independent yes. Same depends on whether there are any 
> differences
> > > > in the requirement that suggest otherwise, but I agree 
> same would
> > > > be a good thing.
> > > > 
> > > > > But please note this:
> > > > > -              a PW is not a layer network, ie we do not 
> > > > network/switch 
> > > > PW entities;
> > > > 
> > > > I am not sure about this. Logically what we are doing is 
> > to recurse
> > > > back to a lower layer, over which we could run for example 
> > > a new IGP.
> > > > In as much as we network/switch wires, we network/switch PWs.
> > > > 
> > > > > -              an LSP is a layer network, ie we do 
> > > > network/switch LSP 
> > > > entities;
> > > > > -              why can't we use Y.1711 OAM on the top 
> > > level p2p LSP?
> > > > 
> > > > VCCV is the only method that has been formally accepted 
> > bt the PWE3
> > > > WG for further study. If you think that Y.1711 is more 
> > appropriate,
> > > > please write a draft explaining how this works in the PWE3 
> > > context and
> > > > why it is better. The WG will then decide the way 
> forward through
> > > > our normal process.
> > > > 
> > > > > -              Y.1711 is sparse/simple/complete, ie all 
> > > defects are 
> > > > defined 
> > > >          with entry-exit criteria and consequent 
> > actions.....it even
> > > >          defines availability and does so in order it can 
> > be used a
> > > >          single-ended way, ie behaviour of both 
> directions can be
> > > >          observed from 1 end.
> > > > 
> > > > > -              MPLS and ATM OAM layer I/W is already 
> defined in 
> > > > Y.1712.....
> > > >          and again its really simple.
> > > > 
> > > >          I thought that we were talking about Ethernet here?
> > > > > 
> > > > > None of this is done (and in some cases is not 
> appropriate) for 
> > > > > the VCCV approach. 
> > > > 
> > > > I which case the VCCV team need to either provide these 
> or explain
> > > > why they are not needed.
> > > > 
> > > > > 
> > > > > So what is wrong with this solution?
> > > > 
> > > > There is no WG draft describing the applicability of 
> > Y.1711 to PWE3.
> > > > If you want that solution, then you have to run the normal IETF
> > > > process to get it adopted, which will involve writing a draft,
> > > > getting it accepted by the WG, and going through a 
> point by point
> > > > analysis of the advantages and disadvantages of Y.1711 and VCCV.
> > > > 
> > > > Regards
> > > > 
> > > > Stewart
> > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > pwe3 mailing list
> > > > pwe3@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > pwe3 mailing list
> > > > pwe3@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > > 
> > > 
> > > _______________________________________________
> > > pwe3 mailing list
> > > pwe3@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > 
> > 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: neil.2.harrison@bt.com
Subject: RE: PW functional model and its OAM [was: FCS retention in PWE3]
Date: Fri, 12 Dec 2003 00:18:23 -0000
Lines: 475
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Fri Dec 12 01:19:14 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
Thread-Topic: [PWE3] PW functional model and its OAM [was: FCS retention in PWE3]
Thread-Index: AcPALVDrVg9GNeP+T7ukw1EWwKxvJQADQBXA
To: <busschbach@lucent.com>, <Maarten.Vissers@alcatel.de>,
        <stbryant@cisco.com>
X-OriginalArrivalTime: 12 Dec 2003 00:18:24.0018 (UTC) FILETIME=[74BAC720:01C3C045]
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



> -----Original Message-----
> From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com]
> Sent: 11 December 2003 21:24
> To: Harrison,N,Neil,IKR2 R; Maarten.Vissers@alcatel.de;
> stbryant@cisco.com
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PW functional model and its OAM [was: FCS=20
> retention
> in PWE3]
>=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> > Sent: Thursday, December 11, 2003 11:54 AM
> > To: busschbach@lucent.com; Maarten.Vissers@alcatel.de;
> > stbryant@cisco.com
> > Cc: pwe3@ietf.org
> > Subject: RE: [PWE3] PW functional model and its OAM [was: FCS=20
> > retention
> > in PWE3]
> >=20
> >=20
> > Busschbach, Peter B (Peter) wrote 11 December 2003 15:55
> > Peter, please see below:
> > >=20
> > > Neil,
> > >=20
> > > You seem to suggest that VCCV is has client-specific=20
> > > elements. I don't see that. Could you explain what in the=20
> > > VCCV draft is client-specific?
> > >=20
> > > Thanks,
> > >=20
> > > Peter
> >=20
> > NH=3D> Sorry if I did not explain this well enough.  Let me=20
> > have another go.  We have some client X and some server Y.  X=20
> > and Y should have their own OAM that is=20
> > independent....hopefully that is an obvious requirement. =20
> > Note - this observation is pertinent to all layers networks,=20
> > not just the case here.=20
> >=20
> > PWs add an adapation function between X and Y.  Some elements=20
> > of the PW adaptation are client specific.
> >=20
> > Now:
> > -	from the 1st observation above, the OAM of X and Y=20
> > should be present irrespective of any PW adapation=20
> > function.....one wants these generic for *all* cases;
> > -	VCCV puts some additional PW generic OAM in the PW=20
> > adaptation function....but this is a strange thing to do=20
> > architecturally if X and Y are properly specified in the 1st place;
> > -	and some client specific adaptations (I quoted the TDM=20
> > client case) are adding further client specific OAM, ie the L=20
> > and R flags I mentioned.
>=20
>=20
> Neil,
>=20
> I think your clarification implies that you agree that VCCV=20
> is client-layer independent.
NH=3D> Well yes, but its also redundant *if* MPLS had properly specified =
OAM in the 1st place......which is what I started to go into in the =
later text, inc the correct handling of FDI forwarding/alarm issue.

> I agree with you that the SATOP=20
> draft seems to violate that separation,
NH=3D> I believe I understand why the authors felt they wanted to place =
L and R indicators in here.....and although not relevent to the specific =
SATOP draft, if any framing structure is taken into account at the IWF =
we have a sort-of trail termination proxy of the TDM client here, and so =
I can make some guesses on how these L/R bits might then be used to =
detect abberations of such framing structures and take action.  I am not =
saying I agree with all this, and again this does not excuse having =
proper MPLS layer OAM.

> but I think that=20
> should be raised as an issue against that draft, not against VCCV.
NH=3D>I can forgive to some extent the aims of the TDMoverMPLS folks =
given the specific nature of the client in question; but it still does =
not excuse proper MPLS being required as I noted above.  I am less =
inclined to forgive the other arch violations as these cause us grief in =
the network management of them and don't provide any sensible foundation =
for the future (assuming one believes, as many do, that MPLS could =
provide a core convergence technology for operators).  Some of my =
colleagues are doing functional modelling (of the type Maarten showed) =
of all the facets of the 3 networking modes (of cnls, co-ps and co-cs) =
and their 9 possible client/server relationships.  MPLS is coming in for =
some detailed scutiny......merging and PHP don't look good under =
analysis, but I expect most engineers know this intuitively anyway.
>=20
> Could you explain why you believe that "VCCV puts some=20
> additional PW generic OAM in the PW adaptation function"? The=20
> VCCV draft defines how to encapsulate OAM traffic so that it=20
> runs over the PW that it is related to. Apart from that, I=20
> don't see how VCCV impacts the PW adaptation function.
NH=3D> I agree it does not run directly in some of the PW fields, but =
that this indicates a further level of stuff before we get to whatever =
the OAM protocol of choice is as an IP-based application, ie.  we have =
LSP->LSP(to demerge)-> PW CW (carrying mostly redundant stuff, no SN =
aberration defect defined, ECMP hack avoidance)-> PID -> Client or IP =
based OAM....some of which is optional, so there are further spins on =
this.  And then we have LSP-Ping....very complex IMO.  Can you honestly =
come to me/BT and tell us this lot is representative of good network =
design?....and where are all the defects defined in terms of automatic =
detection/handling and the *right* consequenct actions?  Things should =
be a lot simpler/cleaner than that IMO.

regards, Neil
BT/GS CTO
>=20
> Peter
>=20
>=20
> >=20
> > Hopefully that makes what I was saying clear.
> >=20
> > There is, of course, more to the complete picture that.  One=20
> > needs a very clear view of the overall layered relationships=20
> > to get the defect handling right.....the func arch stuff=20
> > Maarten was depicting is excellent for understanding this and=20
> > avoiding mistakes.
> >=20
> > Y.1711 was carefully written to be as simple and complete as=20
> > possible, ie attention was paid from the outset to make sure=20
> > all defects had automatic defect detection/handling.  I don't=20
> > see any of this level of detail elsewhere.
> >=20
> > Further, it also considers the mapping of defects arising=20
> > below the MPLS layer into MPLS FDI to *suppress* MPLS layer=20
> > alarms being raised....and this must recurse up through any=20
> > nested LSPs up to the client's FDI where this is appropriate=20
> > (else we get alarm storms all the way up....not a nice thing=20
> > operationally).  I don't see any of this having been thought=20
> > about either.
> >=20
> > However, I do understand *why* this can't easily be=20
> > sorted....it basically boils down to:
> > -	IP and MPLS are not the same network mode....and the=20
> > fact that they are not is what gives each unique value....so=20
> > the adapation (and other things like OAM) does not have to be=20
> > the same.  However, I know this is anti-religious talk so=20
> > I'll park that one here.
> > -	MPLS pkts use label swapping and thus have a forwarding=20
> > behaviour (and defect behaviour) that belongs to the co-ps=20
> > mode....it does not use full DA/SA identifiers in the pkts as=20
> > a true cnls mode requires.  This means the topology=20
> > constructs that should be used with this mode are p2p and=20
> > p2mp....step outside that and you get problems=20
> > elsewhere.....fault management being one of them.=20
> >=20
> > In closing Y.1711 was written by an operator with a strong=20
> > background in functional arch.....but hey, what do we know=20
> > about this stuff ;-)
> >=20
> > regards, Neil
> > >=20
> > > > -----Original Message-----
> > > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> > > > Sent: Thursday, December 11, 2003 9:40 AM
> > > > To: Maarten.Vissers@alcatel.de; stbryant@cisco.com
> > > > Cc: pwe3@ietf.org
> > > > Subject: RE: [PWE3] PW functional model and its OAM [was: FCS=20
> > > > retention
> > > > in PWE3]
> > > >=20
> > > >=20
> > > > Thanks Maarten....that seems pretty-well spot-on.  And yes,=20
> > > > your diagrams clearly show that the PW is an adaptation=20
> > > > function that lies above the MPLS layer network.  So VCCV and=20
> > > > Y.1711 are not operating in the same space and thus it is=20
> > > > technically incorrect to try and compare them.....that is:
> > > > -	VCCV is defining some OAM function that is specific to=20
> > > > a PW adaptation function (rather odd architecturally=20
> > > > however...also see Note);
> > > > -	whilst Y.1711 is generic and operates in the MPLS layer=20
> > > > network irrespective of the client.
> > > >=20
> > > > Note - In the draft draft-ietf-pwe3-satop-00.txt one will=20
> > > > also find some specific client/PW case OAM functions....here=20
> > > > for a certain type of TDM client, ie the 'L' and 'R' bits.
> > > >=20
> > > > The key point however, is that MPLS OAM should be generic=20
> > > > irrespective of the client, and it should not be a function=20
> > > > of the client adaptation function but only of the MPLS trail=20
> > > > termination function as Maarten correctly identifies below.
> > > >=20
> > > > So, if one is to compare Y.1711 to anything it should be to=20
> > > > LSP-Ping say.  However, I see these as complimentary=20
> > > > functions;  and its clear from what Maarten writes below he=20
> > > > shares this view.
> > > >=20
> > > > regards, Neil
> > > >=20
> > > > > -----Original Message-----
> > > > > From: pwe3-admin@ietf.org=20
> > [mailto:pwe3-admin@ietf.org]On Behalf Of
> > > > > Maarten.Vissers@alcatel.de
> > > > > Sent: 11 December 2003 11:45
> > > > > To: stbryant@cisco.com
> > > > > Cc: pwe3@ietf.org
> > > > > Subject: [PWE3] PW functional model and its OAM [was: FCS=20
> > > > retention in
> > > > > PWE3]
> > > > >=20
> > > > >=20
> > > > > Stewart,
> > > > >=20
> > > > > > VCCV is the only method that has been formally accepted=20
> > > > bt the PWE3
> > > > > > WG for further study. If you think that Y.1711 is more=20
> > > > appropriate,
> > > > > > please write a draft explaining how this works in the PWE3=20
> > > > > context and
> > > > > > why it is better. The WG will then decide the way=20
> > > forward through
> > > > > > our normal process.
> > > > >=20
> > > > >=20
> > > > > The G.805/G.809 based functional model for an Ethernet=20
> > over MPLS=20
> > > > > connection will [likely] contain: an MPLS/ETH_A (adaptation)=20
> > > > > function that=20
> > > > > is connected to an MPLS_TT (trail termination) function:
> > > > >=20
> > > > >                    |
> > > > >                    O ETH_FP (flow point, see G.8010)
> > > > >                    |
> > > > >            ----------------
> > > > >             \ MPLS/ETH_A /  Encapsulation of ETH MAC frame
> > > > >              ------------   into MPLS packet payload
> > > > >                    |
> > > > >                    O MPLS_AP (access point)
> > > > >                    |
> > > > >               -----------
> > > > >                \MPLS_TT/    Y.1711 OAM (e.g. CV, BDI, FDI)
> > > > >                 \     /
> > > > >                  \   /
> > > > >                   \ /
> > > > >                    |
> > > > >                    O MPLS_TCP (termination connecction point)
> > > > >                    |
> > > > >        other MPLS functions, or
> > > > >        Server/MPLS_A function
> > > > > =20
> > > > > The MPLS/ETH adaptation function encapsulates the ETH MAC=20
> > > > > frames into the=20
> > > > > MPLS packet payload (PW). The MPLS trail termination=20
> > > > function is the=20
> > > > > endpoint of the MPLS Maintenance Entity (i.e. trail) and has=20
> > > > > associated=20
> > > > > with it MPLS OAM to perform pro-active fault management (e.g.=20
> > > > > using Y.1711=20
> > > > > MPLS-CV, MPLS-BDI, MPLS-FDI) or on-demand fault=20
> > > > localisation for the=20
> > > > > network connection (X-to-Y in figure below).
> > > > >=20
> > > > > On-demand fault localisation OAM (e.g. loopback/ping,=20
> > > > > traceroute) may also=20
> > > > > be sourced/sinked in MPLS test trail termination functions=20
> > > > > (centralised=20
> > > > > function in a node), which may be connected to the MPLS=20
> > > > > serial compound=20
> > > > > link connection (between ingress and egress PE: K-to-L in=20
> > > > > figure below).=20
> > > > > In this case the connections through the first and last=20
> > > > > fabrics ((a) in=20
> > > > > MPLS connection functions in figure below) are not monitored.
> > > > >=20
> > > > >=20
> > > > >              Ingress PE
> > > > > <-------------------------------->
> > > > >               -----------
> > > > >                \  MPLS /  on-demand
> > > > >                 \ Test/   MPLS OAM
> > > > >                  \   /
> > > > >                   \ /
> > > > >                    |
> > > > >     pro-act.       O
> > > > >     MPLS OAM       |
> > > > >      |\     -----------   |\
> > > > >      |M\    |   (b)|  | K | \
> > > > >      |P \ X |      \  |-O-|  |     MPLS
> > > > >   -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
> > > > >      |S /   |  (a)    |-O-|  |             |
> > > > >      | /    |         |   | /              |
> > > > >      |/     -----------   |/               |
> > > > >          MPLS Conn. funct.                 |
> > > > >                                            |
> > > > >                                            |
> > > > >          MPLS Conn. funct.                 |
> > > > >      |\     -----------   |\               |
> > > > >      |M\    |         | L | \              |
> > > > >      |P \ Y |  (a)    |-O-|  |     MPLS    |
> > > > >   -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
> > > > >      |S /   |       / |-O-|  |
> > > > >      | /    |   (b)|  |   | /
> > > > >      |/     -----------   |/
> > > > >     pro-act.       |
> > > > >     MPLS OAM       O
> > > > >                    |
> > > > >                   / \
> > > > >                  /   \
> > > > >                 / MPLS\   on-demand
> > > > >                /  Test \  MPLS OAM
> > > > >               -----------
> > > > > <-------------------------------->=20
> > > > >               Egress PE
> > > > >=20
> > > > >=20
> > > > > Based on the functional model of a pseudowire, the presence=20
> > > > > of Y.1711 as=20
> > > > > MPLS OAM standard and the default allocation of certains=20
> > > > > types of [MPLS]=20
> > > > > OAM to [MPLS] trail termination functions, one may conclude=20
> > > > > that Y.1711 is=20
> > > > > already an existing alternative in the fault management and=20
> > > > > performance=20
> > > > > monitoring of a MPLS based pseudowire (which is a client=20
> > > > > layer-network=20
> > > > > link supported by a MPLS trail).
> > > > >=20
> > > > > Regards,
> > > > > Maarten
> > > > >=20
> > > > >=20
> > > > >=20
> > > > >=20
> > > >=20
> > >=20
> >=20
> ---------------------------------------------------------------------
> > > > > Maarten Vissers
> > > > > Network and Product Strategy - Optical Networks Division
> > > > > Alcatel SEL AG=20
> > > > > Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
> > > > > Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The=20
> > > > Netherlands
> > > > > Mobile: +31 65 141 8140
> > > > > Email:Maarten.Vissers@alcatel.de
> > > > >=20
> > > > >=20
> > > > >=20
> > > > >=20
> > > > >=20
> > > > > Stewart Bryant <stbryant@cisco.com>
> > > > > Sent by: pwe3-admin@ietf.org
> > > > > 01-12-2003 11:31
> > > > > Please respond to stbryant
> > > > >=20
> > > > > =20
> > > > >         To:     neil.2.harrison@bt.com
> > > > >         cc:     pwe3@ietf.org
> > > > >         Subject:        Re: [PWE3] FCS retention in PWE3
> > > > >=20
> > > > >=20
> > > > >=20
> > > > >=20
> > > > > neil.2.harrison@bt.com wrote:
> > > > >=20
> > > > > > Stwart,
> > > > > >=20
> > > > > > In general I agree with you.  But what you are=20
> > actually saying=20
> > > > > > here is that we want independent OAM in each layer=20
> > > network (simply
> > > > > > has to be independent....one reason being that we want=20
> > > the *same*
> > > > > > OAM solution in the server irrespective of its client).=20
> > > > >=20
> > > > > Independent yes. Same depends on whether there are any=20
> > differences
> > > > > in the requirement that suggest otherwise, but I agree=20
> > same would
> > > > > be a good thing.
> > > > >=20
> > > > > > But please note this:
> > > > > > -              a PW is not a layer network, ie we do not=20
> > > > > network/switch=20
> > > > > PW entities;
> > > > >=20
> > > > > I am not sure about this. Logically what we are doing is=20
> > > to recurse
> > > > > back to a lower layer, over which we could run for example=20
> > > > a new IGP.
> > > > > In as much as we network/switch wires, we network/switch PWs.
> > > > >=20
> > > > > > -              an LSP is a layer network, ie we do=20
> > > > > network/switch LSP=20
> > > > > entities;
> > > > > > -              why can't we use Y.1711 OAM on the top=20
> > > > level p2p LSP?
> > > > >=20
> > > > > VCCV is the only method that has been formally accepted=20
> > > bt the PWE3
> > > > > WG for further study. If you think that Y.1711 is more=20
> > > appropriate,
> > > > > please write a draft explaining how this works in the PWE3=20
> > > > context and
> > > > > why it is better. The WG will then decide the way=20
> > forward through
> > > > > our normal process.
> > > > >=20
> > > > > > -              Y.1711 is sparse/simple/complete, ie all=20
> > > > defects are=20
> > > > > defined=20
> > > > >          with entry-exit criteria and consequent=20
> > > actions.....it even
> > > > >          defines availability and does so in order it can=20
> > > be used a
> > > > >          single-ended way, ie behaviour of both=20
> > directions can be
> > > > >          observed from 1 end.
> > > > >=20
> > > > > > -              MPLS and ATM OAM layer I/W is already=20
> > defined in=20
> > > > > Y.1712.....
> > > > >          and again its really simple.
> > > > >=20
> > > > >          I thought that we were talking about Ethernet here?
> > > > > >=20
> > > > > > None of this is done (and in some cases is not=20
> > appropriate) for=20
> > > > > > the VCCV approach.=20
> > > > >=20
> > > > > I which case the VCCV team need to either provide these=20
> > or explain
> > > > > why they are not needed.
> > > > >=20
> > > > > >=20
> > > > > > So what is wrong with this solution?
> > > > >=20
> > > > > There is no WG draft describing the applicability of=20
> > > Y.1711 to PWE3.
> > > > > If you want that solution, then you have to run the=20
> normal IETF
> > > > > process to get it adopted, which will involve writing a draft,
> > > > > getting it accepted by the WG, and going through a=20
> > point by point
> > > > > analysis of the advantages and disadvantages of=20
> Y.1711 and VCCV.
> > > > >=20
> > > > > Regards
> > > > >=20
> > > > > Stewart
> > > > >=20
> > > > >=20
> > > > >=20
> > > > >=20
> > > > > _______________________________________________
> > > > > pwe3 mailing list
> > > > > pwe3@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > > >=20
> > > > >=20
> > > > >=20
> > > > >=20
> > > > > _______________________________________________
> > > > > pwe3 mailing list
> > > > > pwe3@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > > >=20
> > > >=20
> > > > _______________________________________________
> > > > pwe3 mailing list
> > > > pwe3@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > >=20
> > >=20
> >=20
>=20


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in
	 PWE3]
Date: Thu, 11 Dec 2003 21:15:19 -0500
Lines: 519
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Fri Dec 12 03:17:17 2003
Return-path: <pwe3-admin@ietf.org>
To: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        Maarten.Vissers@alcatel.de, stbryant@cisco.com
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Neil,

You have stated many times that MPLS would have been a better protocol if it didn't have PHP, MTP and ECMP. Suppose that such a form of MPLS existed. Then it would have been straightforward to define encapsulation of client protocols into this form of MPLS. Without PHP, only one label would be required. Without ECMP, it would be easy to guarantee that OAM traffic would fate-share with the client signal. With such a solution, a PW would be equivalent to an LSP; Maarten's functional model would apply; and everything would be fine and dandy.

However, with such a solution, one ends up with a vary large number of LSPs between to PEs. I suspect that fairly soon Service Providers would decide that it would make sense to set up one LSP between two PEs and tunnel all PW-LSPs through that Tunnel LSP. That would require two layers of OAM. There would be a need for OAM of the Tunnel LSP as well as OAM for every PW-LSP running through it.

In your emails, you have made clear that you believe that PW is broken because it should only be an adaptation function and instead (because of PHP, MTP and ECMP) it almost seems a layer in and of itself.

In seems to me that the situation is actually not that much worse than what I described above for the "ideal" two-layer case. Personally, I don't have a problem with seeing the PW as layer on top of an MPLS or IP infrastructure and I don't see a problem with defining VCCV as the OAM mechanism within that layer. Philosophically, it might not be pure, but pragmatically, it seems equivalent to purer solutions.

I believe that with VCCV, and especially with the adition of BFD, we are on the right way to meet Service Provider needs. The current drafts are not perfect and need additional work. In earlier emails you mentioned the need to define how Sequence Number errors are translated to failure conditions. That is a valid criticism and I agree that it should be addressed. On the other hand, blanket statements like "VCCV is not client-layer independent" are not very helpful, especially since they are wrong.

I hope that we can work our way through the real problems and come up with a good solution.

Peter

> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Thursday, December 11, 2003 7:18 PM
> To: busschbach@lucent.com; Maarten.Vissers@alcatel.de;
> stbryant@cisco.com
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> retention
> in PWE3]
> 
> 
> 
> 
> > -----Original Message-----
> > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com]
> > Sent: 11 December 2003 21:24
> > To: Harrison,N,Neil,IKR2 R; Maarten.Vissers@alcatel.de;
> > stbryant@cisco.com
> > Cc: pwe3@ietf.org
> > Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> > retention
> > in PWE3]
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> > > Sent: Thursday, December 11, 2003 11:54 AM
> > > To: busschbach@lucent.com; Maarten.Vissers@alcatel.de;
> > > stbryant@cisco.com
> > > Cc: pwe3@ietf.org
> > > Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> > > retention
> > > in PWE3]
> > > 
> > > 
> > > Busschbach, Peter B (Peter) wrote 11 December 2003 15:55
> > > Peter, please see below:
> > > > 
> > > > Neil,
> > > > 
> > > > You seem to suggest that VCCV is has client-specific 
> > > > elements. I don't see that. Could you explain what in the 
> > > > VCCV draft is client-specific?
> > > > 
> > > > Thanks,
> > > > 
> > > > Peter
> > > 
> > > NH=> Sorry if I did not explain this well enough.  Let me 
> > > have another go.  We have some client X and some server Y.  X 
> > > and Y should have their own OAM that is 
> > > independent....hopefully that is an obvious requirement.  
> > > Note - this observation is pertinent to all layers networks, 
> > > not just the case here. 
> > > 
> > > PWs add an adapation function between X and Y.  Some elements 
> > > of the PW adaptation are client specific.
> > > 
> > > Now:
> > > -	from the 1st observation above, the OAM of X and Y 
> > > should be present irrespective of any PW adapation 
> > > function.....one wants these generic for *all* cases;
> > > -	VCCV puts some additional PW generic OAM in the PW 
> > > adaptation function....but this is a strange thing to do 
> > > architecturally if X and Y are properly specified in the 
> 1st place;
> > > -	and some client specific adaptations (I quoted the TDM 
> > > client case) are adding further client specific OAM, ie the L 
> > > and R flags I mentioned.
> > 
> > 
> > Neil,
> > 
> > I think your clarification implies that you agree that VCCV 
> > is client-layer independent.
> NH=> Well yes, but its also redundant *if* MPLS had properly 
> specified OAM in the 1st place......which is what I started 
> to go into in the later text, inc the correct handling of FDI 
> forwarding/alarm issue.
> 
> > I agree with you that the SATOP 
> > draft seems to violate that separation,
> NH=> I believe I understand why the authors felt they wanted 
> to place L and R indicators in here.....and although not 
> relevent to the specific SATOP draft, if any framing 
> structure is taken into account at the IWF we have a sort-of 
> trail termination proxy of the TDM client here, and so I can 
> make some guesses on how these L/R bits might then be used to 
> detect abberations of such framing structures and take 
> action.  I am not saying I agree with all this, and again 
> this does not excuse having proper MPLS layer OAM.
> 
> > but I think that 
> > should be raised as an issue against that draft, not against VCCV.
> NH=>I can forgive to some extent the aims of the TDMoverMPLS 
> folks given the specific nature of the client in question; 
> but it still does not excuse proper MPLS being required as I 
> noted above.  I am less inclined to forgive the other arch 
> violations as these cause us grief in the network management 
> of them and don't provide any sensible foundation for the 
> future (assuming one believes, as many do, that MPLS could 
> provide a core convergence technology for operators).  Some 
> of my colleagues are doing functional modelling (of the type 
> Maarten showed) of all the facets of the 3 networking modes 
> (of cnls, co-ps and co-cs) and their 9 possible client/server 
> relationships.  MPLS is coming in for some detailed 
> scutiny......merging and PHP don't look good under analysis, 
> but I expect most engineers know this intuitively anyway.
> > 
> > Could you explain why you believe that "VCCV puts some 
> > additional PW generic OAM in the PW adaptation function"? The 
> > VCCV draft defines how to encapsulate OAM traffic so that it 
> > runs over the PW that it is related to. Apart from that, I 
> > don't see how VCCV impacts the PW adaptation function.
> NH=> I agree it does not run directly in some of the PW 
> fields, but that this indicates a further level of stuff 
> before we get to whatever the OAM protocol of choice is as an 
> IP-based application, ie.  we have LSP->LSP(to demerge)-> PW 
> CW (carrying mostly redundant stuff, no SN aberration defect 
> defined, ECMP hack avoidance)-> PID -> Client or IP based 
> OAM....some of which is optional, so there are further spins 
> on this.  And then we have LSP-Ping....very complex IMO.  Can 
> you honestly come to me/BT and tell us this lot is 
> representative of good network design?....and where are all 
> the defects defined in terms of automatic detection/handling 
> and the *right* consequenct actions?  Things should be a lot 
> simpler/cleaner than that IMO.
> 
> regards, Neil
> BT/GS CTO
> > 
> > Peter
> > 
> > 
> > > 
> > > Hopefully that makes what I was saying clear.
> > > 
> > > There is, of course, more to the complete picture that.  One 
> > > needs a very clear view of the overall layered relationships 
> > > to get the defect handling right.....the func arch stuff 
> > > Maarten was depicting is excellent for understanding this and 
> > > avoiding mistakes.
> > > 
> > > Y.1711 was carefully written to be as simple and complete as 
> > > possible, ie attention was paid from the outset to make sure 
> > > all defects had automatic defect detection/handling.  I don't 
> > > see any of this level of detail elsewhere.
> > > 
> > > Further, it also considers the mapping of defects arising 
> > > below the MPLS layer into MPLS FDI to *suppress* MPLS layer 
> > > alarms being raised....and this must recurse up through any 
> > > nested LSPs up to the client's FDI where this is appropriate 
> > > (else we get alarm storms all the way up....not a nice thing 
> > > operationally).  I don't see any of this having been thought 
> > > about either.
> > > 
> > > However, I do understand *why* this can't easily be 
> > > sorted....it basically boils down to:
> > > -	IP and MPLS are not the same network mode....and the 
> > > fact that they are not is what gives each unique value....so 
> > > the adapation (and other things like OAM) does not have to be 
> > > the same.  However, I know this is anti-religious talk so 
> > > I'll park that one here.
> > > -	MPLS pkts use label swapping and thus have a forwarding 
> > > behaviour (and defect behaviour) that belongs to the co-ps 
> > > mode....it does not use full DA/SA identifiers in the pkts as 
> > > a true cnls mode requires.  This means the topology 
> > > constructs that should be used with this mode are p2p and 
> > > p2mp....step outside that and you get problems 
> > > elsewhere.....fault management being one of them. 
> > > 
> > > In closing Y.1711 was written by an operator with a strong 
> > > background in functional arch.....but hey, what do we know 
> > > about this stuff ;-)
> > > 
> > > regards, Neil
> > > > 
> > > > > -----Original Message-----
> > > > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> > > > > Sent: Thursday, December 11, 2003 9:40 AM
> > > > > To: Maarten.Vissers@alcatel.de; stbryant@cisco.com
> > > > > Cc: pwe3@ietf.org
> > > > > Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> > > > > retention
> > > > > in PWE3]
> > > > > 
> > > > > 
> > > > > Thanks Maarten....that seems pretty-well spot-on.  And yes, 
> > > > > your diagrams clearly show that the PW is an adaptation 
> > > > > function that lies above the MPLS layer network.  So VCCV and 
> > > > > Y.1711 are not operating in the same space and thus it is 
> > > > > technically incorrect to try and compare them.....that is:
> > > > > -	VCCV is defining some OAM function that is specific to 
> > > > > a PW adaptation function (rather odd architecturally 
> > > > > however...also see Note);
> > > > > -	whilst Y.1711 is generic and operates in the MPLS layer 
> > > > > network irrespective of the client.
> > > > > 
> > > > > Note - In the draft draft-ietf-pwe3-satop-00.txt one will 
> > > > > also find some specific client/PW case OAM functions....here 
> > > > > for a certain type of TDM client, ie the 'L' and 'R' bits.
> > > > > 
> > > > > The key point however, is that MPLS OAM should be generic 
> > > > > irrespective of the client, and it should not be a function 
> > > > > of the client adaptation function but only of the MPLS trail 
> > > > > termination function as Maarten correctly identifies below.
> > > > > 
> > > > > So, if one is to compare Y.1711 to anything it should be to 
> > > > > LSP-Ping say.  However, I see these as complimentary 
> > > > > functions;  and its clear from what Maarten writes below he 
> > > > > shares this view.
> > > > > 
> > > > > regards, Neil
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: pwe3-admin@ietf.org 
> > > [mailto:pwe3-admin@ietf.org]On Behalf Of
> > > > > > Maarten.Vissers@alcatel.de
> > > > > > Sent: 11 December 2003 11:45
> > > > > > To: stbryant@cisco.com
> > > > > > Cc: pwe3@ietf.org
> > > > > > Subject: [PWE3] PW functional model and its OAM [was: FCS 
> > > > > retention in
> > > > > > PWE3]
> > > > > > 
> > > > > > 
> > > > > > Stewart,
> > > > > > 
> > > > > > > VCCV is the only method that has been formally accepted 
> > > > > bt the PWE3
> > > > > > > WG for further study. If you think that Y.1711 is more 
> > > > > appropriate,
> > > > > > > please write a draft explaining how this works in 
> the PWE3 
> > > > > > context and
> > > > > > > why it is better. The WG will then decide the way 
> > > > forward through
> > > > > > > our normal process.
> > > > > > 
> > > > > > 
> > > > > > The G.805/G.809 based functional model for an Ethernet 
> > > over MPLS 
> > > > > > connection will [likely] contain: an MPLS/ETH_A 
> (adaptation) 
> > > > > > function that 
> > > > > > is connected to an MPLS_TT (trail termination) function:
> > > > > > 
> > > > > >                    |
> > > > > >                    O ETH_FP (flow point, see G.8010)
> > > > > >                    |
> > > > > >            ----------------
> > > > > >             \ MPLS/ETH_A /  Encapsulation of ETH MAC frame
> > > > > >              ------------   into MPLS packet payload
> > > > > >                    |
> > > > > >                    O MPLS_AP (access point)
> > > > > >                    |
> > > > > >               -----------
> > > > > >                \MPLS_TT/    Y.1711 OAM (e.g. CV, BDI, FDI)
> > > > > >                 \     /
> > > > > >                  \   /
> > > > > >                   \ /
> > > > > >                    |
> > > > > >                    O MPLS_TCP (termination 
> connecction point)
> > > > > >                    |
> > > > > >        other MPLS functions, or
> > > > > >        Server/MPLS_A function
> > > > > >  
> > > > > > The MPLS/ETH adaptation function encapsulates the ETH MAC 
> > > > > > frames into the 
> > > > > > MPLS packet payload (PW). The MPLS trail termination 
> > > > > function is the 
> > > > > > endpoint of the MPLS Maintenance Entity (i.e. 
> trail) and has 
> > > > > > associated 
> > > > > > with it MPLS OAM to perform pro-active fault 
> management (e.g. 
> > > > > > using Y.1711 
> > > > > > MPLS-CV, MPLS-BDI, MPLS-FDI) or on-demand fault 
> > > > > localisation for the 
> > > > > > network connection (X-to-Y in figure below).
> > > > > > 
> > > > > > On-demand fault localisation OAM (e.g. loopback/ping, 
> > > > > > traceroute) may also 
> > > > > > be sourced/sinked in MPLS test trail termination functions 
> > > > > > (centralised 
> > > > > > function in a node), which may be connected to the MPLS 
> > > > > > serial compound 
> > > > > > link connection (between ingress and egress PE: K-to-L in 
> > > > > > figure below). 
> > > > > > In this case the connections through the first and last 
> > > > > > fabrics ((a) in 
> > > > > > MPLS connection functions in figure below) are not 
> monitored.
> > > > > > 
> > > > > > 
> > > > > >              Ingress PE
> > > > > > <-------------------------------->
> > > > > >               -----------
> > > > > >                \  MPLS /  on-demand
> > > > > >                 \ Test/   MPLS OAM
> > > > > >                  \   /
> > > > > >                   \ /
> > > > > >                    |
> > > > > >     pro-act.       O
> > > > > >     MPLS OAM       |
> > > > > >      |\     -----------   |\
> > > > > >      |M\    |   (b)|  | K | \
> > > > > >      |P \ X |      \  |-O-|  |     MPLS
> > > > > >   -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
> > > > > >      |S /   |  (a)    |-O-|  |             |
> > > > > >      | /    |         |   | /              |
> > > > > >      |/     -----------   |/               |
> > > > > >          MPLS Conn. funct.                 |
> > > > > >                                            |
> > > > > >                                            |
> > > > > >          MPLS Conn. funct.                 |
> > > > > >      |\     -----------   |\               |
> > > > > >      |M\    |         | L | \              |
> > > > > >      |P \ Y |  (a)    |-O-|  |     MPLS    |
> > > > > >   -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
> > > > > >      |S /   |       / |-O-|  |
> > > > > >      | /    |   (b)|  |   | /
> > > > > >      |/     -----------   |/
> > > > > >     pro-act.       |
> > > > > >     MPLS OAM       O
> > > > > >                    |
> > > > > >                   / \
> > > > > >                  /   \
> > > > > >                 / MPLS\   on-demand
> > > > > >                /  Test \  MPLS OAM
> > > > > >               -----------
> > > > > > <--------------------------------> 
> > > > > >               Egress PE
> > > > > > 
> > > > > > 
> > > > > > Based on the functional model of a pseudowire, the presence 
> > > > > > of Y.1711 as 
> > > > > > MPLS OAM standard and the default allocation of certains 
> > > > > > types of [MPLS] 
> > > > > > OAM to [MPLS] trail termination functions, one may conclude 
> > > > > > that Y.1711 is 
> > > > > > already an existing alternative in the fault management and 
> > > > > > performance 
> > > > > > monitoring of a MPLS based pseudowire (which is a client 
> > > > > > layer-network 
> > > > > > link supported by a MPLS trail).
> > > > > > 
> > > > > > Regards,
> > > > > > Maarten
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > > > > Maarten Vissers
> > > > > > Network and Product Strategy - Optical Networks Division
> > > > > > Alcatel SEL AG 
> > > > > > Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
> > > > > > Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The 
> > > > > Netherlands
> > > > > > Mobile: +31 65 141 8140
> > > > > > Email:Maarten.Vissers@alcatel.de
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Stewart Bryant <stbryant@cisco.com>
> > > > > > Sent by: pwe3-admin@ietf.org
> > > > > > 01-12-2003 11:31
> > > > > > Please respond to stbryant
> > > > > > 
> > > > > >  
> > > > > >         To:     neil.2.harrison@bt.com
> > > > > >         cc:     pwe3@ietf.org
> > > > > >         Subject:        Re: [PWE3] FCS retention in PWE3
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > neil.2.harrison@bt.com wrote:
> > > > > > 
> > > > > > > Stwart,
> > > > > > > 
> > > > > > > In general I agree with you.  But what you are 
> > > actually saying 
> > > > > > > here is that we want independent OAM in each layer 
> > > > network (simply
> > > > > > > has to be independent....one reason being that we want 
> > > > the *same*
> > > > > > > OAM solution in the server irrespective of its client). 
> > > > > > 
> > > > > > Independent yes. Same depends on whether there are any 
> > > differences
> > > > > > in the requirement that suggest otherwise, but I agree 
> > > same would
> > > > > > be a good thing.
> > > > > > 
> > > > > > > But please note this:
> > > > > > > -              a PW is not a layer network, ie we do not 
> > > > > > network/switch 
> > > > > > PW entities;
> > > > > > 
> > > > > > I am not sure about this. Logically what we are doing is 
> > > > to recurse
> > > > > > back to a lower layer, over which we could run for example 
> > > > > a new IGP.
> > > > > > In as much as we network/switch wires, we 
> network/switch PWs.
> > > > > > 
> > > > > > > -              an LSP is a layer network, ie we do 
> > > > > > network/switch LSP 
> > > > > > entities;
> > > > > > > -              why can't we use Y.1711 OAM on the top 
> > > > > level p2p LSP?
> > > > > > 
> > > > > > VCCV is the only method that has been formally accepted 
> > > > bt the PWE3
> > > > > > WG for further study. If you think that Y.1711 is more 
> > > > appropriate,
> > > > > > please write a draft explaining how this works in the PWE3 
> > > > > context and
> > > > > > why it is better. The WG will then decide the way 
> > > forward through
> > > > > > our normal process.
> > > > > > 
> > > > > > > -              Y.1711 is sparse/simple/complete, ie all 
> > > > > defects are 
> > > > > > defined 
> > > > > >          with entry-exit criteria and consequent 
> > > > actions.....it even
> > > > > >          defines availability and does so in order it can 
> > > > be used a
> > > > > >          single-ended way, ie behaviour of both 
> > > directions can be
> > > > > >          observed from 1 end.
> > > > > > 
> > > > > > > -              MPLS and ATM OAM layer I/W is already 
> > > defined in 
> > > > > > Y.1712.....
> > > > > >          and again its really simple.
> > > > > > 
> > > > > >          I thought that we were talking about Ethernet here?
> > > > > > > 
> > > > > > > None of this is done (and in some cases is not 
> > > appropriate) for 
> > > > > > > the VCCV approach. 
> > > > > > 
> > > > > > I which case the VCCV team need to either provide these 
> > > or explain
> > > > > > why they are not needed.
> > > > > > 
> > > > > > > 
> > > > > > > So what is wrong with this solution?
> > > > > > 
> > > > > > There is no WG draft describing the applicability of 
> > > > Y.1711 to PWE3.
> > > > > > If you want that solution, then you have to run the 
> > normal IETF
> > > > > > process to get it adopted, which will involve 
> writing a draft,
> > > > > > getting it accepted by the WG, and going through a 
> > > point by point
> > > > > > analysis of the advantages and disadvantages of 
> > Y.1711 and VCCV.
> > > > > > 
> > > > > > Regards
> > > > > > 
> > > > > > Stewart
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > pwe3 mailing list
> > > > > > pwe3@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > pwe3 mailing list
> > > > > > pwe3@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > pwe3 mailing list
> > > > > pwe3@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > > > 
> > > > 
> > > 
> > 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Maarten.Vissers@alcatel.de
Subject: Next Generation CO-PS layer network technology?
Date: Fri, 12 Dec 2003 14:04:57 +0100
Lines: 203
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-From: pwe3-admin@ietf.org Fri Dec 12 14:06:06 2003
Return-path: <pwe3-admin@ietf.org>
To: stds-802-1@ieee.org, tsg15q12@itu.int, pwe3@ietf.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
X-MIMETrack: Serialize by Router on DEMAIL02/DE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 12/12/2003 14:04:59,
	Serialize complete at 12/12/2003 14:04:59
X-Alcanet-virus-scanned: hBCD4xV4017718 at mailrelay1.alcatel.de
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

As we are approaching the end of the year 2003 and many of use looking
forward to one or more weeks of vacation (to get rid of all left over
vacation days), I would like to provide some food for your thoughts 
under the Christmas tree.

INTRODUCTION
------------
I have the feeling that 2004 will become known in history as the year
in which we selected/developed the Next Generation Connection Oriented
Packet Switched (NG CO-PS) layer network technology, which will be the
successor of FR and ATM. I would therefore like to initiate a discussion
on this topic.

CURRENT LANDSCAPE
-----------------
When I look at the current NG CO-PS landscape, I see four alternatives
that are being considered, discussed, investigated, developped and/or
installed:

1) CO-PS MPLS (switched MPLS)
2) CO-PS ETH/VLAN (switched Ethernet/switched VLAN)
3) CO-PS GFP (switched GFP)
4) something new.

The first three alternatives have as starting point the 
re-use/multi-use of existing popular frame/packet formats:
1) MPLS packet with its shim header (label, EXP, S, TTL):
2) tagged MAC frame (ethertype, VLAN ID, priority, CFI)
3) GFP-F frame with linear extension header (Channel ID, spare).

BASIC NG CO-PS CHARACTERISTICS
------------------------------
NG CO-PS frame/packet format needs to support the following fields:
a) tributary slot identifier (label, VLAN ID, channel ID)
b) class of service/dropping precedence (EXP, priority)

NG CO-PS frame/packet format needs to support the following 
networking capability:
c) multi-level hierarchy (tunneling) capability to allow it to
   be used in (metro-)access, metro(-core) and core networks.

NG CO_PS technology needs to support connection monitoring according
the G.805 paradigm; this includes:
d) connection monitoring for each (tunnel) level in the hierarchy
e) multi-level (nested) connection monitoring capability for user 
   connections, to allow dedicated connection monitoring for user,
   service provider and network operator(s) as well as for protection
   and restoration.
f) pro-active fault management and performance monitoring OAM for 
   user connections and hierarchy levels (tunnels)
g) on-demand fault localisation OAM for user connections and
   hierarchy levels. 

Note: Non intrusive monitoring of any connection monitoring level at
an intermediate point in the connection for the service provider is a
requirement for today's SDH/SONET and OTH networks, in the absence of a
standard "service management" architecture. With the work on the 
Architecture for Services Management (G.asm) being started in Q.12/15,
the NG CO-PS may not require this non-intrusive connection monitoring 
of any connection monitoring level. This removes a significant 
requirement.

NG CO-PS technology needs to support connection oriented protection
and restoration; this includes:
h) subnetwork connection protection (SNCP)
i) ring protection (SPRing).

NG CO-PS layer network needs to support:
j) client/server relationships (mapping, network interworking)
k) G.805 layer network interworking (service interworking)
with existing CO-PS layer network technologies.


EVALUATION OF CURRENT FRAME FORMATS
-----------------------------------
The MPLS packet format is considered as it provides the closest match with
the basic characteristics required for the NG CO-PS technology.
        a) trib slot id: 20-bit label
        b) CoS/DP: 3-bit EXP
        c) hierarchy: infinite tunneling capability
        d) tunnel conn. mon.: MPLS OAM
        e) nested conn. mon.: MPLS OAM
        f) pro-active fm/pm: MPLS OAM (CV, FFD, FDI, BDI)
        g) on-demand fault loc.: MPLS OAM (ping)
        h) SNCP: MPLS protection switching
           Further enhancements/extensions are required.
        i) SPRing: to be developed
        j) mapping: IP: available, ATM, FR, ETH: under development
        k) LN IW: MPLS/ATM, MPLS/FR under development.
By using MPLS as the NG CO-PS packet format, the "M" in MPLS gets a second
meaning; this "M" originally referred to it being a protocol that can ride
over multiple server layer protocols, with the deployment as NG CO-PS it 
also refers to multiple client layer protocols that can ride over it.


The Ethernet MAC tagged frame format is considered due to the low cost
of today's ethernet interface ports. The Ethernet MAC frame is developed
for use in bridged-ethernet networks; its use as NG CO-PS would require a
number of extensions:
        a) trib slot id: 12-bit VLAN ID
        b) CoS/DP: 3-bit priority
        c) hierarchy: potential VLAN stacking capability
           Requires new CO-PS VLAN tags to be defined; QTag and
           STag should not be used as these are for bridged-ethernet, not
           for switched-ethernet/VLAN.
        d) tunnel conn. mon.: to be developed
        e) nested conn. mon.: to be developed
        f) pro-active fm/pm: to be developed
        g) on-demand fault loc.: to be developed.
           The current bridged-ETH OAM development in Q.3/13 may be
           the basis for d) to f)
        h) SNCP: to be developed
        i) SPRing: to be developed
        j) mapping: IP, MPLS: available, ATM, FR: ?
        k) LN IW: ETH/ATM, ETH/FR, ETH/MPLS to be developed?
        x) development of connection oriented VLAN switching.
Switched-Ethernet/VLAN will use the ethernet MAC frame as encapsulation
format for multiple client signals. The implication of this is to be
understood.


The GFP-F frame format is considered as it is the latest frame format
developed within the standards organisation (ITU-T) that traditionally
defines connection oriented layer technologies. GFP-F is an encapsulation
frame format and its use as NG CO-PS would require a number of extensions:
        a) trib slot id: 8-bit channel ID
           D.371 (SG15, 04/02) proposes a 20-bit Flow ID.
        b) CoS/DP: to be developed
           D.370 (SG15, 04/02) proposes a 3-bit Priority field.
        c) hierarchy: to be developed
           Requires capability to support stacking in the extension 
header.
           58 bytes are available in the extension header area for such
           purpose. With e.g. 3-bytes per level (20-bit label, 3-bit 
CoS/DP, 
           1-bit bottom of stack), 19 levels can be supported.
        d) tunnel conn. mon.: to be developed
        e) nested conn. mon.: to be developed
        f) pro-active fm/pm: to be developed
        g) on-demand fault loc.: to be developed.
        h) SNCP: to be developed
        i) SPRing: to be developed
        j) mapping: to be developed
        k) LN IW: to be developed
        x) development of connection oriented GFP switching.


CO-EXISTENCE
------------
For the case we will select one of the three existing frame/packet formats 

as basis for the NG CO-PS layer network, it will have to peacefully 
co-exist
with the original application; i.e. the NG CO-PS development should not 
hijack
the frame/packet format. This requires cooperation and recognition of the 
needs
of both the original and the new NG CO-PS application.

If the current "owners" of the frame/packet formats (MPLS: IEFT, MAC: IEEE 
802,
GFP-F: ITU-T SG15) are not able/do not want to share their frame/packet 
format
with the new NG CO-PS application, that frame/packet format should not be
considered as a NG CO-PS frame/packet format candidate.

I am therefore very interested to hear the opinion of the participants of 
IETF, 
IEEE 802 and ITU-T SG15 on the multi-use of their frame/packet format as 
NG CO-PS
frame/packet format.


EQUIPMENT
---------
The NG CO-PS layer network will introduce one additional switching 
technology or
switching technology profile in the multi service switching platforms 
(MSSPs).

Some existing MSSPs may already support elements of the NG CO-PS and/or 
may be
upgradable to support NG CO-PS. Others may not support any element of the 
NG CO-PS
and may not be upgradable. That's just how life is; it should not play a 
major role
in the decision process for the NG CO-PS in my opinion.


Up to so far. Looking forward to your opinions on this item.

Regards,
Maarten


---------------------------------------------------------------------
Maarten Vissers
Network and Product Strategy - Optical Networks Division
Alcatel SEL AG 
Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
Mobile: +31 65 141 8140
Email:Maarten.Vissers@alcatel.de


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: mark seery <mark@interflect.com>
Subject: Re: Next Generation CO-PS layer network technology?
Date: Fri, 12 Dec 2003 06:27:07 -0800
Lines: 55
Sender: pwe3-admin@ietf.org
References: <OFBD3826F0.E2FDB5A7-ONC1256DFA.00459C92@netfr.alcatel.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stds-802-1@ieee.org, tsg15q12@itu.int, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Fri Dec 12 15:34:04 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
To: Maarten.Vissers@alcatel.de
In-Reply-To: <OFBD3826F0.E2FDB5A7-ONC1256DFA.00459C92@netfr.alcatel.fr>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Maarten.Vissers@alcatel.de wrote:

><snip>
>As we are approaching the end of the year 2003 and many of use looking
>forward to one or more weeks of vacation (to get rid of all left over
>vacation days), I would like to provide some food for your thoughts 
>under the Christmas tree.
>
>INTRODUCTION
>------------
>I have the feeling that 2004 will become known in history as the year
>in which we selected/developed the Next Generation Connection Oriented
>Packet Switched (NG CO-PS) layer network technology, which will be the
>successor of FR and ATM. I would therefore like to initiate a discussion
>on this topic.
>
>  
>
Hi Maarten,

This is unquestionably a worthwhile discussion to have, though in what 
forum or in what way I am not sure.

I think you have started down a syncratic road (worthy of an Alexander 
the great or a Joseph Campbell) that provides the most benefit by 
illuminating commonalities and differences (see also: 
http://www.interflect.com/app/overview.html).

Two of the organizations you have copied on this email have a core 
competency in developing connectionless protocols, so IMO the more 
beneficial starting place is to discuss why:

1) There needs to be a NG CO-PS mode at any layer of the network
2) More importantly why there needs to be a NG CO-PS mode above the 
transmission layer (whether it be SONET/SDH or WDM).
3) What are the essential characteristics of a NG CO-PS *and I don't 
mean fields as you have described, but I mean attributes that are for 
example missing from CLNS).

With respect to point 3) there are some large conceptual issues that 
keep getting in the way of thought convergence. For example, you are 
probably aware that historical Internet architectures have pursued the 
notion that a simple datagram service provides the foundation for 
developing any number of transport services over them (e.g. TCP and 
UDP), and that this is useful because it pushes state to the end-points 
and therefore makes the network more robust, more adaptable, and more 
flexible. This basic concept impacts, I believe, basic approaches to 
engineering within the IETF/PWE even today.  So unless we can discuss 
and converge on such issues, I am not sure how fruitful a discussion 
about NG CO-PS is going to be, because we will be talking past each 
other because of our world views.

My 2 cents.

-mark


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: neil.2.harrison@bt.com
Subject: RE: PW functional model and its OAM [was: FCS retention in PWE3]
Date: Sat, 13 Dec 2003 16:34:11 -0000
Lines: 243
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Sat Dec 13 17:35:17 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
Thread-Topic: [PWE3] PW functional model and its OAM [was: FCS retention in PWE3]
Thread-Index: AcPAVdE0zY8ZFnM7RwigTUtwGFvu8QBHPHtg
To: <busschbach@lucent.com>, <Maarten.Vissers@alcatel.de>,
        <stbryant@cisco.com>
X-OriginalArrivalTime: 13 Dec 2003 16:34:12.0129 (UTC) FILETIME=[F0894910:01C3C196]
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Peter,  I apologise up-front that this is a longish response....however =
there are some key points in here.

<snipped>
>=20
> You have stated many times that MPLS would have been a better=20
> protocol if it didn't have PHP, MTP and ECMP.
NH=3D> Let's be clear here please.  I don't care which specific =
technology is being discussed, as the only thing that is relevant is the =
architecture allowed for the network mode that the technology concerned =
belongs to.  There are but three networking modes and they are all L3 =
'peers' in an OSI sense.....the L1, L2 and L3 classifications some use =
mean absolutely nothing, only the modal classification is useful.  In a =
functional architecture sense the co-cs and co-ps modes are increasing =
constraints on the cnls mode....and the reason we impose these =
constraints is because they provide (i) major simplification benefits =
wrt network operation/management, and (ii) a 'connection' is essential =
for some network services (this also has QoS semantic implications of =
'urgency' vs 'importance', especially in private network =
services.....but that is a story in itself which I do not wish to get =
into here).

Now, to obtain these benefits you have to stay within the allowed =
architecture of the mode, and for the co-cs/ps modes this means the only =
allowed constructs are p2p and mp2p.   If one uses labels on =
link-connections and breaks the architecture by doing mp2p merging say, =
you have no choice but to run p2p constructions above these if the =
client is not cnls.  That is simply a fact. And you can see this in all =
the PW stuff, ie in a simple client/server relationship one only needs 1 =
server trail level to form the link-connections of the client.....in the =
PW stuff there are always 2 server layer LSPs doing this job.  And the =
role of the inner LSP is to recover any merging on the outer LSP, ie to =
provide the identity of the source which otherwise would be lost.  The =
PW adaptation sits above all this.

Now we pay a complexity/opex price for the merging (eg only a madman =
would tell me LSP-Ping is not complex) and we *still* have to run p2p =
above it.=20

PHP is also an architectural violation which terminates the trail in the =
wrong place...we have done functional arch modelling of this behaviour =
that shows the operational consequences and we don't like them.

ECMP is something else that is concerned with traffic routing.  Now, it =
is interesting to observe that the whole point of using a server layer =
is to control the routing of the client layer traffic.....some folks =
call this TE.  If one then ignores the server layer constructions on =
routing the traffic by deciding the actual routing to use based on the =
client then you might be able to switch-off the server layer TE function =
as its doing effectively nothing.  However, ECMP together with the arch =
violations of mp2p and PHP do increase the fault-management complexity =
of the server layer.  But why bother with all this anyway?  If all one =
wants is true any-any connectivity and one is prepared to make =
trade-offs here wrt 'soft-SLAs' and the simplicity obtained from using =
the co modes then just use IP.  BTW: ECMP *within* a single layer =
network is fine.....its when its applied over more than 1 layer network =
that the problems arise....and this observation would apply to any =
technology.

Now, we are prepared to live with all this stuff....we have to anyway =
it's out there.   What we find more galling however, is when folks try =
and tell us this stuff is 'correct' when we can show it plainly is not.

We also don't like it when folks continually ignore good work like =
Y.1711 and effectively go about re-inventing it.  Some people say they =
want operator input here but they only listen to it when it suits them =
and ignore it when it doesn't.  Given there must always be p2p LSPs =
above any mp2p LSPs to recover from merging we'd like to see Y.1711 run =
on these top LSPs and use the more complex tools like LSP-Ping to =
fault-find on-demand in the mp2p layer when (i) the p2p LSPs show a =
problem and (ii) any lower layer trails (eg in SDH) show clear.

So please explain to me what is wrong with that approach before going =
and re-inventing OAM is some layer above MPLS that only applies at end =
points and not to the actual network.....and I'll explain later why this =
is not the right solution anyway for the general case.

> Suppose that=20
> such a form of MPLS existed. Then it would have been=20
> straightforward to define encapsulation of client protocols=20
> into this form of MPLS.
NH=3D> I agree.  And we can easily do it....it only takes the will to =
want to.

> Without PHP, only one label would be=20
> required.
NH=3D> Not strictly true.  If you constructed what is going on in =
functional arch terms you would see that 2 labels are required to =
recover from any mp2p merging in a co-ps mode for a non cnls client.  =
PHP terminates the server layer trail one hop too short.  And this has =
its own architectural/operational consequences.  But I do agree it also =
causes a merge behaviour on the last hop.  Again our functional =
modelling of this clearly shows this and its consequences.

> Without ECMP, it would be easy to guarantee that=20
> OAM traffic would fate-share with the client signal. With=20
> such a solution, a PW would be equivalent to an LSP;=20
> Maarten's functional model would apply; and everything would=20
> be fine and dandy.
>=20
> However, with such a solution, one ends up with a vary large=20
> number of LSPs between to PEs. I suspect that fairly soon=20
> Service Providers would decide that it would make sense to=20
> set up one LSP between two PEs and tunnel all PW-LSPs through=20
> that Tunnel LSP. That would require two layers of OAM. There=20
> would be a need for OAM of the Tunnel LSP as well as OAM for=20
> every PW-LSP running through it.
NH=3D> You are now talking about the benefits of using hierarchy...we =
have been using these techniques for years.  One does not have to =
violate the architecture of the co modes to gain benefits from =
hierarchy.  And yes you are right you can now run OAM on each =
hierarchical level since these are layer networks in their own =
right......you don't have to, but the ability to do so is important.  =
Also consider the situation when the client and server LSPs are owned by =
different administrations.  This is nothing new either.  This can exist =
in ATM between the VP and VC layers, and in SDH between the STM-N/VC4 =
and VC12 layers for example.  One has to cater for this situation in the =
general case....and this is fundamentally what is wrong with the PW/VCCV =
approach that I will come on to shortly.
>=20
> In your emails, you have made clear that you believe that PW=20
> is broken because it should only be an adaptation function=20
> and instead (because of PHP, MTP and ECMP) it almost seems a=20
> layer in and of itself.
NH=3D> Well PWs are for sure *not* a layer network...we do not 'network' =
PWs....we could, but then this would place a load of extra requirements =
on them, ie they would need a full functional component set that defines =
a layer network.  Compare to GFP or AALs in ATM, ie these are also not =
layer networks.
>=20
> In seems to me that the situation is actually not that much=20
> worse than what I described above for the "ideal" two-layer=20
> case. Personally, I don't have a problem with seeing the PW=20
> as layer on top of an MPLS or IP infrastructure and I don't=20
> see a problem with defining VCCV as the OAM mechanism within=20
> that layer. Philosophically, it might not be pure, but=20
> pragmatically, it seems equivalent to purer solutions.
>=20
> I believe that with VCCV, and especially with the adition of=20
> BFD, we are on the right way to meet Service Provider needs.
NH=3D> Do you?   And are you truly considering the general case here?  =
There are some serious problems with this idea IMO.  If we don't have =
*networked* OAM within each layer network that is independent and can =
automatically detect defects (as close to origin as possible, within the =
scope of the trail termination CI flows) and take appropriate consequent =
actions, esp FDI generation, we are going to get alarms raised at the =
wrong locations.  This is not a good idea and I don't think you'll find =
many operators asking for this behaviour.  You may not have consciously =
thought about this, but all the stuff I have seen coming from IETF in =
this area takes for granted the fact that the transport networks, such =
as SDH/Sonet, are properly specified wrt these OAM functions.  I see =
various drafts with remarks like 'when a fault is detected.....', but =
never actually saying *how* this works.....and what they all take for =
granted is that the transport networks have proper OAM and are going to =
provide an FDI indication (usually called AIS in co-cs networks).  The =
main purpose of this function is suppress alarms in higher layer =
networks.....and it needs to be recursively mapped upwards though nested =
layers.  Now lets look at some interworking cases wrt to what you are =
advocating:

Problem 1 - Vertical layer network ownership:

Suppose we have a set of nested trails where each trail is owned by =
different operators.  It should be very clear that *each* trail requires =
its own OAM/fault-management.  And that's exactly what you will find in =
SDH/Sonet for example.  Now consider the case that the nested trails are =
MPLS LSPs.  It should now also be clear that the OAM *must* be a =
function of the LSP and not some higher level PW adaptation process =
right at the top of the stack.  So clearly if we are going to have MPLS =
used as the target convergence technology (as many operators/vendors =
show) it must take this kind of international/multi-party networking =
scenario into account.  This is only possible if the OAM is associated =
with the entity that is *networked* (ie the LSP) and not some entity =
that sits above the top-level adaptation function.

Problem 2 - Horizontal layer partitioning:

Suppose we have a trail that is owned by some party X that is carried on =
leased lower layer transport trails within the domains of operators A, B =
and C.  Now the operators A, B and C can monitor their server layers =
*iff* these have their own OAM, eg if SDH VC4s say.  But suppose that X =
wants an MPLS layer LSP carried and suppose the operators wants to also =
provide the lower layer transport service using MPLS.  One of the =
beauties of MPLS is that is has no fixed hierarchy, ie it is a true =
'digital wrapper' technology.  This means each operator can construct a =
lower layer LSP across their domain and monitor this.  This technique is =
not possible in fixed hierarchy networks, eg ATM....and one has to =
construct (so-called) 'tandem connection monitoring' segments for such a =
case....and these have architectural limitations in stacking due to the =
fixed hierarchy.  So once again, we clearly see that the OAM required =
*must* be a function of the network LSP entity and not some entity that =
sits above the top-level adaptation function.

I trust you can agree with these observations.......which are, IMO, =
quite general requirements of any technology and something that =
operators would want to see addressed.  Y.1711 takes the above cases =
into account, ie it works at the LSP level.=20

> The current drafts are not perfect and need additional work.=20
> In earlier emails you mentioned the need to define how=20
> Sequence Number errors are translated to failure conditions.=20
> That is a valid criticism and I agree that it should be=20
> addressed.
NH=3D> The issue here is this:  OAM should be generic and agnostic of =
the application above some given server layer, and from the above the =
OAM *must* be an intrinsic function of the networked entity.....so we =
must have the same solutions in all cases.  Sequence numbers on the =
other hand are client-application specific and not a general requirement =
of the network.  So in the TDM client-application case I can see a role =
for Seq Numbers.....but as I stated these should be a function of the =
adaptation of *that* client-application not the general case.  As you =
also noted, in an earlier mail, that the algorithm is currently flawed =
anyway;  but in any case the required 're-ordering' behaviour is =
client-application specific.....this should *not* be a concern of a =
server layer network as it should not know or care about specific client =
applications.  These should be designed (via a suitable adaptation say) =
to cater for specific client needs.  Now, if Seq No.s are left in there =
for the general case (which I still maintain is wrong) you cannot simply =
leave them open-ended wrt defect behaviour.  At some point of Seq No =
corruption a defect will need to be declared and consequent actions =
taken.  So if these stay when are we going to see this addressed?

>  On the other hand, blanket statements like "VCCV=20
> is not client-layer independent" are not very helpful,=20
> especially since they are wrong.
NH=3D> Well, I hope you understood my earlier arguments than the OAM =
*must* be a function of the networked entity and why this important.
>=20
> I hope that we can work our way through the real problems and=20
> come up with a good solution.
NH=3D> We certainly can but *iff* we:
-	start to acknowledge the stuff that is architecturally not =
right.....yes we have to live with it and we are fine with that;
-	start to acknowledge we need all 3 networking modes and allow them to =
work together in a complimentary manner......you can't crunch them all =
together like the GMPLS peer-model stuff, its simply a commercial =
non-starter;
-	stop ignoring good work like Y.1711 simply because its been done in =
ITU and by an operator.

I still remain hopeful for MPLS....but we will see what happens.

regards, Neil


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: mark seery <mark@interflect.com>
Subject: Re: PW functional model and its OAM [was: FCS retention in
 PWE3]
Date: Sat, 13 Dec 2003 10:36:36 -0800
Lines: 110
Sender: pwe3-admin@ietf.org
References: <0536FC9B908BEC4597EE721BE6A3538904EF2F7A@i2km07-ukbr.domain1.systemhost.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: busschbach@lucent.com, Maarten.Vissers@alcatel.de, stbryant@cisco.com,
        pwe3@ietf.org
X-From: pwe3-admin@ietf.org Sat Dec 13 19:44:10 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
To: neil.2.harrison@bt.com
In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2F7A@i2km07-ukbr.domain1.systemhost.net>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Hi Neil, a few comments inline.

Regards,
mark

neil.2.harrison@bt.com wrote:

>Peter,  I apologise up-front that this is a longish response....however there are some key points in here.
>
><snipped>
>  
>
>>You have stated many times that MPLS would have been a better 
>>protocol if it didn't have PHP, MTP and ECMP.
>>    
>>
>NH=> Let's be clear here please.  I don't care which specific technology is being discussed, as the only thing that is relevant is the architecture allowed for the network mode that the technology concerned belongs to.  There are but three networking modes and they are all L3 'peers' in an OSI sense.....the L1, L2 and L3 classifications some use mean absolutely nothing, only the modal classification is useful.
>
ms=> I do believe the point you make is not grokked as much as it could 
be, but I also think that in making your point you have emphasized one 
aspect of a more complex issue.

L3 does mean something, specifically within the context of this 
organization. There is a well-honed, well understood concept of an 
Internetwork layer (IP, ICMP, IGMP, etc.) within the IETF. A concept 
which suggests there is one layer that exists rather ignorantly 
(intentionally) of the "network" layers below it. There is great utility 
from this concept which has served this community well. So while I agree 
with your essential intent to illuminate the fact that the OSI model 
does not describe the myriad of server layers that might (depending on 
network design/architecture) exist in a network, there are aspects of 
the OSI model / Internet architecture model that have utility as well.

The model I keep in my own confused head is an amalgomation of the 
Internet layered model and the point you make. It is important to keep 
both in mind because of the historical concern with the Internet 
architecture of end-to-end issues.

><snip>
>
>ECMP is something else that is concerned with traffic routing.  Now, it is interesting to observe that the whole point of using a server layer is to control the routing of the client layer traffic.....some folks call this TE.  If one then ignores the server layer constructions on routing the traffic by deciding the actual routing to use based on the client then you might be able to switch-off the server layer TE function as its doing effectively nothing.
>
ms=> So I think there is an interesting issue here. All IP routing 
essentially ignores the server layer construction. Specifically, in a 
native IP network, ECMP views the server layer as little more than a 
construct for creating successive bandwidth conduits (maybe there are 
other advantages as well) between routers. In this context, the server 
layer really serves the resource allocation/management requirements of 
the bandwidth provider and have little other importance WRT the client 
layer (that the server layer might provide reliability checks, 
protection etc is nice, but not of prominent importance or necessity to 
the client layer).

This is fairly clear I think in an environment where an IP layer is 
running over a circuit layer. It is up to the server layer to define 
itself in a way that is independent of the client layer and meets the 
server layers needs - an issue which the PW WG has no control over.

>  However, ECMP together with the arch violations of mp2p and PHP do increase the fault-management complexity of the server layer.  But why bother with all this anyway?  If all one wants is true any-any connectivity and one is prepared to make trade-offs here wrt 'soft-SLAs' and the simplicity obtained from using the co modes then just use IP.  BTW: ECMP *within* a single layer network is fine.....its when its applied over more than 1 layer network that the problems arise....and this observation would apply to any technology.
>
ms=> I suspect you are making an important point here, but not sure how 
to respond as my own analysis does not conclude definitively whether 
MPLS is a layer in and of itself WRT how it is used and implemented in 
current form, for example it is possible IMO to consider either IP+MPLS 
or MPLS+PW as the full set of semantics necessary to create a layer.

>
>Now, we are prepared to live with all this stuff....we have to anyway it's out there.   What we find more galling however, is when folks try and tell us this stuff is 'correct' when we can show it plainly is not.
>
>We also don't like it when folks continually ignore good work like Y.1711 and effectively go about re-inventing it.  Some people say they want operator input here but they only listen to it when it suits them and ignore it when it doesn't.  Given there must always be p2p LSPs above any mp2p LSPs to recover from merging we'd like to see Y.1711 run on these top LSPs and use the more complex tools like LSP-Ping to fault-find on-demand in the mp2p layer when (i) the p2p LSPs show a problem and (ii) any lower layer trails (eg in SDH) show clear.
>
>So please explain to me what is wrong with that approach before going and re-inventing OAM is some layer above MPLS that only applies at end points and not to the actual network.....and I'll explain later why this is not the right solution anyway for the general case.
>
>  
>
>>Suppose that 
>>such a form of MPLS existed. Then it would have been 
>>straightforward to define encapsulation of client protocols 
>>into this form of MPLS.
>>    
>>
>NH=> I agree.  And we can easily do it....it only takes the will to want to.
>
>  
>
>>Without PHP, only one label would be 
>>required.
>>    
>>
>NH=> Not strictly true.  If you constructed what is going on in functional arch terms you would see that 2 labels are required to recover from any mp2p merging in a co-ps mode for a non cnls client.  PHP terminates the server layer trail one hop too short.  And this has its own architectural/operational consequences.  But I do agree it also causes a merge behaviour on the last hop.  Again our functional modelling of this clearly shows this and its consequences.
>  
>
>>In your emails, you have made clear that you believe that PW 
>>is broken because it should only be an adaptation function 
>>and instead (because of PHP, MTP and ECMP) it almost seems a 
>>layer in and of itself.
>>    
>>
>NH=> Well PWs are for sure *not* a layer network...we do not 'network' PWs....we could, but then this would place a load of extra requirements on them, ie they would need a full functional component set that defines a layer network.  Compare to GFP or AALs in ATM, ie these are also not layer networks.
>
ms=> So I don't believe this is the complete story. Take for example 
1490 over FR IWF 1483 over ATM. Interworking/translation is required at 
both the server layer and adaptation functions. That we might one day 
take PW+MPLS and interwork it to 1483+ATM is conceivable and doable. 
What makes the PW model a little more interesting is that the adaptation 
function by model occurs on a service provider's service facing 
interface, where commonly in FR/ATM networks it occurs on the customers 
network facing interface, thus moving the point in a system where OAM 
coverage might need to be extended to (which I understand we have argued 
about before).


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Maarten.Vissers@alcatel.de
Subject: RE: PW functional model and its OAM [was: FCS retention in PWE3]
Date: Sun, 14 Dec 2003 10:53:48 +0100
Lines: 314
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: pwe3@ietf.org, stbryant@cisco.com
X-From: pwe3-admin@ietf.org Sun Dec 14 10:55:16 2003
Return-path: <pwe3-admin@ietf.org>
To: <tnadeau@cisco.com>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
X-MIMETrack: Serialize by Router on DEMAIL02/DE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 12/14/2003 10:53:53,
	Serialize complete at 12/14/2003 10:53:53
X-Alcanet-virus-scanned: hBE9rrV4013931 at mailrelay1.alcatel.de
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Tom,

Thank you for rasing this question. Find below some further considerations 
and a question:

We may be having a different starting point when we speak about MPLS. For 
me MPLS can be used as a CO-PS technology that is deployed on 
CL-PS/CO-PS/CO-CS multi service switching/provisioning platforms; i.e. 
transport network elements (SDH,OTH) with strong packet support (CL-PS: 
provider bridged Ethernet, CO-PS: e.g. MPLS). This is the direction the 
market is pushing these transport network elements.

I am aware that MPLS has not been developed as a CO-PS technology (a last 
call comment for G.809 stated that MPLS was a CL-PS technology). RFC3031 
states that it focusses on the use of IP as the network layer protocol 
(i.e. client signal), which if I understand it well gives MPLS the CL-PS 
flavour. In the multi service transport network elements it will initially 
be ETH and FR that will be the client signals for the CO-PS layer (e.g. 
MPLS); i.e. not (directly) IP. In the further future I can also see that 
the multi service transport network must support native CO-PS (e.g. MPLS) 
connections (between CO-PS UNIs (e.g. MPLS UNIs)).

Looking at the current set of MPLS specifications most elements for a 
CO-PS usage are present, making it an ideal candidate for use within the 
multi service transport network elements. MPLS would then be transported 
over e.g. (virtual concatenated) SDH VC-n/OTH ODUk signals.

In this transport network environment, G.805/809 models are a basic 
starting point. It would be very helpful if PWE3 would be able to accept 
the G.805 model as an additional (CO-PS) architecture model (in addition 
to the existing CL-PS IP/MPLS based architecture model). 

In this transport network environment with strong connection monitoring 
requirements, PHP would not be required (due to requirement of OAM 
processing at ingress/egress interface ports), MTP would not be required 
(due to connection monitoring and alarm suppression requirements) and ECMP 
would not be required either (feature is provided by VCAT/LCAS). 

As neither of these three (PHP, MTP, ECMP) constructs seem to be mandatory 
(as far as I have understood) in the MPLS architecture in RFC3031, a CO-PS 
MPLS profile seems to be within the boundaries of RFC3031. Is this a 
correct understanding in your opinion?

Regards,
Maarten









"Thomas D. Nadeau" <tnadeau@cisco.com>
11-12-2003 17:27
Please respond to tnadeau

 
        To:     Maarten VISSERS/DE/ALCATEL@ALCATEL, <stbryant@cisco.com>
        cc:     <pwe3@ietf.org>
        Subject:        RE: [PWE3] PW functional model and its OAM [was: FCS retention in PWE3]



                 Martin,

                 It seems that you are claiming that the
G.805/809 model should be our reference model for
PWE3 as you are pointing out deficiencies in the 
coverage of current OAM tools created by the PWE3 WG. 
I think the larger question we should be asking
is whether or not the IETF PWE3 WG accepts the model from 
G.805/809 to be the model we will use for the PWE3 architecture. 
Since we already have an architecture document that last
time I checked, was pretty complete, I think it is worth hearing 
from the chairs/ADs on this issue to give us some direction 
on how to consider the G.805 model in the context of PWE3.

                 --Tom



>-----Original Message-----
>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On 
>Behalf Of Maarten.Vissers@alcatel.de
>Sent: Thursday, December 11, 2003 6:45 AM
>To: stbryant@cisco.com
>Cc: pwe3@ietf.org
>Subject: [PWE3] PW functional model and its OAM [was: FCS 
>retention in PWE3]
>
>
>Stewart,
>
>> VCCV is the only method that has been formally accepted bt the PWE3
>> WG for further study. If you think that Y.1711 is more appropriate,
>> please write a draft explaining how this works in the PWE3 
>context and
>> why it is better. The WG will then decide the way forward through
>> our normal process.
>
>
>The G.805/G.809 based functional model for an Ethernet over MPLS 
>connection will [likely] contain: an MPLS/ETH_A (adaptation) 
>function that 
>is connected to an MPLS_TT (trail termination) function:
>
>                   |
>                   O ETH_FP (flow point, see G.8010)
>                   |
>           ----------------
>            \ MPLS/ETH_A /  Encapsulation of ETH MAC frame
>             ------------   into MPLS packet payload
>                   |
>                   O MPLS_AP (access point)
>                   |
>              -----------
>               \MPLS_TT/    Y.1711 OAM (e.g. CV, BDI, FDI)
>                \     /
>                 \   /
>                  \ /
>                   |
>                   O MPLS_TCP (termination connecction point)
>                   |
>       other MPLS functions, or
>       Server/MPLS_A function
> 
>The MPLS/ETH adaptation function encapsulates the ETH MAC 
>frames into the 
>MPLS packet payload (PW). The MPLS trail termination function is the 
>endpoint of the MPLS Maintenance Entity (i.e. trail) and has 
>associated 
>with it MPLS OAM to perform pro-active fault management (e.g. 
>using Y.1711 
>MPLS-CV, MPLS-BDI, MPLS-FDI) or on-demand fault localisation for the 
>network connection (X-to-Y in figure below).
>
>On-demand fault localisation OAM (e.g. loopback/ping, 
>traceroute) may also 
>be sourced/sinked in MPLS test trail termination functions 
>(centralised 
>function in a node), which may be connected to the MPLS serial 
>compound 
>link connection (between ingress and egress PE: K-to-L in 
>figure below). 
>In this case the connections through the first and last 
>fabrics ((a) in 
>MPLS connection functions in figure below) are not monitored.
>
>
>             Ingress PE
><-------------------------------->
>              -----------
>               \  MPLS /  on-demand
>                \ Test/   MPLS OAM
>                 \   /
>                  \ /
>                   |
>    pro-act.       O
>    MPLS OAM       |
>     |\     -----------   |\
>     |M\    |   (b)|  | K | \
>     |P \ X |      \  |-O-|  |     MPLS
>  -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
>     |S /   |  (a)    |-O-|  |             |
>     | /    |         |   | /              |
>     |/     -----------   |/               |
>         MPLS Conn. funct.                 |
>                                           |
>                                           |
>         MPLS Conn. funct.                 |
>     |\     -----------   |\               |
>     |M\    |         | L | \              |
>     |P \ Y |  (a)    |-O-|  |     MPLS    |
>  -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
>     |S /   |       / |-O-|  |
>     | /    |   (b)|  |   | /
>     |/     -----------   |/
>    pro-act.       |
>    MPLS OAM       O
>                   |
>                  / \
>                 /   \
>                / MPLS\   on-demand
>               /  Test \  MPLS OAM
>              -----------
><--------------------------------> 
>              Egress PE
>
>
>Based on the functional model of a pseudowire, the presence of 
>Y.1711 as 
>MPLS OAM standard and the default allocation of certains types 
>of [MPLS] 
>OAM to [MPLS] trail termination functions, one may conclude 
>that Y.1711 is 
>already an existing alternative in the fault management and 
>performance 
>monitoring of a MPLS based pseudowire (which is a client layer-network 
>link supported by a MPLS trail).
>
>Regards,
>Maarten
>
>
>
>---------------------------------------------------------------------
>Maarten Vissers
>Network and Product Strategy - Optical Networks Division
>Alcatel SEL AG 
>Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
>Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
>Mobile: +31 65 141 8140
>Email:Maarten.Vissers@alcatel.de
>
>
>
>
>
>Stewart Bryant <stbryant@cisco.com>
>Sent by: pwe3-admin@ietf.org
>01-12-2003 11:31
>Please respond to stbryant
>
> 
>        To:     neil.2.harrison@bt.com
>        cc:     pwe3@ietf.org
>        Subject:        Re: [PWE3] FCS retention in PWE3
>
>
>
>
>neil.2.harrison@bt.com wrote:
>
>> Stwart,
>> 
>> In general I agree with you.  But what you are actually saying 
>> here is that we want independent OAM in each layer network (simply
>> has to be independent....one reason being that we want the *same*
>> OAM solution in the server irrespective of its client). 
>
>Independent yes. Same depends on whether there are any differences
>in the requirement that suggest otherwise, but I agree same would
>be a good thing.
>
>> But please note this:
>> -              a PW is not a layer network, ie we do not 
>network/switch 
>PW entities;
>
>I am not sure about this. Logically what we are doing is to recurse
>back to a lower layer, over which we could run for example a new IGP.
>In as much as we network/switch wires, we network/switch PWs.
>
>> -              an LSP is a layer network, ie we do 
>network/switch LSP 
>entities;
>> -              why can't we use Y.1711 OAM on the top level p2p LSP?
>
>VCCV is the only method that has been formally accepted bt the PWE3
>WG for further study. If you think that Y.1711 is more appropriate,
>please write a draft explaining how this works in the PWE3 context and
>why it is better. The WG will then decide the way forward through
>our normal process.
>
>> -              Y.1711 is sparse/simple/complete, ie all defects are 
>defined 
>         with entry-exit criteria and consequent actions.....it even
>         defines availability and does so in order it can be used a
>         single-ended way, ie behaviour of both directions can be
>         observed from 1 end.
>
>> -              MPLS and ATM OAM layer I/W is already defined in 
>Y.1712.....
>         and again its really simple.
>
>         I thought that we were talking about Ethernet here?
>> 
>> None of this is done (and in some cases is not appropriate) for 
>> the VCCV approach. 
>
>I which case the VCCV team need to either provide these or explain
>why they are not needed.
>
>> 
>> So what is wrong with this solution?
>
>There is no WG draft describing the applicability of Y.1711 to PWE3.
>If you want that solution, then you have to run the normal IETF
>process to get it adopted, which will involve writing a draft,
>getting it accepted by the WG, and going through a point by point
>analysis of the advantages and disadvantages of Y.1711 and VCCV.
>
>Regards
>
>Stewart
>
>
>
>
>_______________________________________________
>pwe3 mailing list
>pwe3@ietf.org
>https://www1.ietf.org/mailman/listinfo/pwe3
>
>
>
>
>_______________________________________________
>pwe3 mailing list
>pwe3@ietf.org
>https://www1.ietf.org/mailman/listinfo/pwe3
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Kumar Kovvali <Kumar@coriolisnet.com>
Subject: re: Next Generation CO-PS layer network technology
Date: Fri, 12 Dec 2003 16:02:10 -0500
Lines: 224
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-From: pwe3-admin@ietf.org Mon Dec 15 03:40:17 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Maarten.Vissers@alcatel.de'" <Maarten.Vissers@alcatel.de>,
        "'stds-802-1@ieee.org'" <stds-802-1@ieee.org>,
        "'tsg15q12@itu.int'"
	 <tsg15q12@itu.int>,
        "'pwe3@ietf.org'" <pwe3@ietf.org>
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Maarteen,
Your NG CO-PS summary is very interesting.  I am wondering about the
following 2 additional needs in the list of "Basic NG CO-PS
Characteristics".

(1) User signalling channel within the MPLS tunnel that facilitates
forwarding any control info between the two service termination points.   
(2) Flow control to propagate congestion for interworking between
dis-similar technologies.

Regards
-Kumar Kovvali
Coriolis Networks   

-----Original Message-----
From: Maarten.Vissers@alcatel.de [mailto:Maarten.Vissers@alcatel.de]
Sent: Friday, December 12, 2003 8:05 AM
To: stds-802-1@ieee.org; tsg15q12@itu.int; pwe3@ietf.org
Subject: [PWE3] Next Generation CO-PS layer network technology?


As we are approaching the end of the year 2003 and many of use looking
forward to one or more weeks of vacation (to get rid of all left over
vacation days), I would like to provide some food for your thoughts 
under the Christmas tree.

INTRODUCTION
------------
I have the feeling that 2004 will become known in history as the year
in which we selected/developed the Next Generation Connection Oriented
Packet Switched (NG CO-PS) layer network technology, which will be the
successor of FR and ATM. I would therefore like to initiate a discussion
on this topic.

CURRENT LANDSCAPE
-----------------
When I look at the current NG CO-PS landscape, I see four alternatives
that are being considered, discussed, investigated, developped and/or
installed:

1) CO-PS MPLS (switched MPLS)
2) CO-PS ETH/VLAN (switched Ethernet/switched VLAN)
3) CO-PS GFP (switched GFP)
4) something new.

The first three alternatives have as starting point the 
re-use/multi-use of existing popular frame/packet formats:
1) MPLS packet with its shim header (label, EXP, S, TTL):
2) tagged MAC frame (ethertype, VLAN ID, priority, CFI)
3) GFP-F frame with linear extension header (Channel ID, spare).

BASIC NG CO-PS CHARACTERISTICS
------------------------------
NG CO-PS frame/packet format needs to support the following fields:
a) tributary slot identifier (label, VLAN ID, channel ID)
b) class of service/dropping precedence (EXP, priority)

NG CO-PS frame/packet format needs to support the following 
networking capability:
c) multi-level hierarchy (tunneling) capability to allow it to
   be used in (metro-)access, metro(-core) and core networks.

NG CO_PS technology needs to support connection monitoring according
the G.805 paradigm; this includes:
d) connection monitoring for each (tunnel) level in the hierarchy
e) multi-level (nested) connection monitoring capability for user 
   connections, to allow dedicated connection monitoring for user,
   service provider and network operator(s) as well as for protection
   and restoration.
f) pro-active fault management and performance monitoring OAM for 
   user connections and hierarchy levels (tunnels)
g) on-demand fault localisation OAM for user connections and
   hierarchy levels. 

Note: Non intrusive monitoring of any connection monitoring level at
an intermediate point in the connection for the service provider is a
requirement for today's SDH/SONET and OTH networks, in the absence of a
standard "service management" architecture. With the work on the 
Architecture for Services Management (G.asm) being started in Q.12/15,
the NG CO-PS may not require this non-intrusive connection monitoring 
of any connection monitoring level. This removes a significant 
requirement.

NG CO-PS technology needs to support connection oriented protection
and restoration; this includes:
h) subnetwork connection protection (SNCP)
i) ring protection (SPRing).

NG CO-PS layer network needs to support:
j) client/server relationships (mapping, network interworking)
k) G.805 layer network interworking (service interworking)
with existing CO-PS layer network technologies.


EVALUATION OF CURRENT FRAME FORMATS
-----------------------------------
The MPLS packet format is considered as it provides the closest match with
the basic characteristics required for the NG CO-PS technology.
        a) trib slot id: 20-bit label
        b) CoS/DP: 3-bit EXP
        c) hierarchy: infinite tunneling capability
        d) tunnel conn. mon.: MPLS OAM
        e) nested conn. mon.: MPLS OAM
        f) pro-active fm/pm: MPLS OAM (CV, FFD, FDI, BDI)
        g) on-demand fault loc.: MPLS OAM (ping)
        h) SNCP: MPLS protection switching
           Further enhancements/extensions are required.
        i) SPRing: to be developed
        j) mapping: IP: available, ATM, FR, ETH: under development
        k) LN IW: MPLS/ATM, MPLS/FR under development.
By using MPLS as the NG CO-PS packet format, the "M" in MPLS gets a second
meaning; this "M" originally referred to it being a protocol that can ride
over multiple server layer protocols, with the deployment as NG CO-PS it 
also refers to multiple client layer protocols that can ride over it.


The Ethernet MAC tagged frame format is considered due to the low cost
of today's ethernet interface ports. The Ethernet MAC frame is developed
for use in bridged-ethernet networks; its use as NG CO-PS would require a
number of extensions:
        a) trib slot id: 12-bit VLAN ID
        b) CoS/DP: 3-bit priority
        c) hierarchy: potential VLAN stacking capability
           Requires new CO-PS VLAN tags to be defined; QTag and
           STag should not be used as these are for bridged-ethernet, not
           for switched-ethernet/VLAN.
        d) tunnel conn. mon.: to be developed
        e) nested conn. mon.: to be developed
        f) pro-active fm/pm: to be developed
        g) on-demand fault loc.: to be developed.
           The current bridged-ETH OAM development in Q.3/13 may be
           the basis for d) to f)
        h) SNCP: to be developed
        i) SPRing: to be developed
        j) mapping: IP, MPLS: available, ATM, FR: ?
        k) LN IW: ETH/ATM, ETH/FR, ETH/MPLS to be developed?
        x) development of connection oriented VLAN switching.
Switched-Ethernet/VLAN will use the ethernet MAC frame as encapsulation
format for multiple client signals. The implication of this is to be
understood.


The GFP-F frame format is considered as it is the latest frame format
developed within the standards organisation (ITU-T) that traditionally
defines connection oriented layer technologies. GFP-F is an encapsulation
frame format and its use as NG CO-PS would require a number of extensions:
        a) trib slot id: 8-bit channel ID
           D.371 (SG15, 04/02) proposes a 20-bit Flow ID.
        b) CoS/DP: to be developed
           D.370 (SG15, 04/02) proposes a 3-bit Priority field.
        c) hierarchy: to be developed
           Requires capability to support stacking in the extension 
header.
           58 bytes are available in the extension header area for such
           purpose. With e.g. 3-bytes per level (20-bit label, 3-bit 
CoS/DP, 
           1-bit bottom of stack), 19 levels can be supported.
        d) tunnel conn. mon.: to be developed
        e) nested conn. mon.: to be developed
        f) pro-active fm/pm: to be developed
        g) on-demand fault loc.: to be developed.
        h) SNCP: to be developed
        i) SPRing: to be developed
        j) mapping: to be developed
        k) LN IW: to be developed
        x) development of connection oriented GFP switching.


CO-EXISTENCE
------------
For the case we will select one of the three existing frame/packet formats 

as basis for the NG CO-PS layer network, it will have to peacefully 
co-exist
with the original application; i.e. the NG CO-PS development should not 
hijack
the frame/packet format. This requires cooperation and recognition of the 
needs
of both the original and the new NG CO-PS application.

If the current "owners" of the frame/packet formats (MPLS: IEFT, MAC: IEEE 
802,
GFP-F: ITU-T SG15) are not able/do not want to share their frame/packet 
format
with the new NG CO-PS application, that frame/packet format should not be
considered as a NG CO-PS frame/packet format candidate.

I am therefore very interested to hear the opinion of the participants of 
IETF, 
IEEE 802 and ITU-T SG15 on the multi-use of their frame/packet format as 
NG CO-PS
frame/packet format.


EQUIPMENT
---------
The NG CO-PS layer network will introduce one additional switching 
technology or
switching technology profile in the multi service switching platforms 
(MSSPs).

Some existing MSSPs may already support elements of the NG CO-PS and/or 
may be
upgradable to support NG CO-PS. Others may not support any element of the 
NG CO-PS
and may not be upgradable. That's just how life is; it should not play a 
major role
in the decision process for the NG CO-PS in my opinion.


Up to so far. Looking forward to your opinions on this item.

Regards,
Maarten


---------------------------------------------------------------------
Maarten Vissers
Network and Product Strategy - Optical Networks Division
Alcatel SEL AG 
Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
Mobile: +31 65 141 8140
Email:Maarten.Vissers@alcatel.de


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: [Fwd: IESG review of pwe3 architecture document]
Date: Mon, 15 Dec 2003 16:27:41 +0000
Organization: Cisco Systems, Inc.
Lines: 71
Sender: pwe3-admin@ietf.org
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Mon Dec 15 17:29:05 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: "pwe3@ietf.org" <pwe3@ietf.org>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

One round of comments from the IESG

Stewart



-------- Original Message --------
Subject: IESG review of pwe3 architecture document
Date: Tue, 9 Dec 2003 18:55:59 -0600
From: Peterson, Jon <jon.peterson@neustar.biz>
To: 'danny@tcb.net' <danny@tcb.net>,        'Stewart Bryant'	 <stbryant@cisco.com>


The comments below are preliminary - Bert Wijnen has asked for a little more
time to let the MIB doctors look over the draft. I wanted to get these back
to you now, though, to get any necessary dialog started.

<IANA>

I saw your response, Stewart, on the question from IANA. I'm not sure that
overloading existing values of the IP version numbers in:

http://www.iana.org/assignments/version-numbers

is really going to fly. Was this really the only way that packets could be
marked? That isn't a registry that we really change very often... it would
strike people as very odd that an architecture document wanted to muck
around with IP versioning.

Another comment that came up verbally on the telechat was the general
question of how much protocol work has been done in the architecture
document - it's unusual for us to see bit fields and so on in an
Informational RFC (it makes the status of these fields as a normative
reference for a Proposed Standard suspect). So just FYI, any more detailed
protocol specification that goes through PWE3 as a Proposed Standard would
probably have to replicate the field specifications in pwe3-arch - it
couldn't just be referenced.

<Russ>

    Section 10, 4th paragraph says:

       IPSec MAY provide authentication, integrity, non-repudiation, and
       confidentiality of data transferred between two PEs. It cannot
       provide the equivalent services to the native service.

    IPsec does not, and cannot, provide non-repudiation.  IPsec can be used
    to provide integrity, authentication, confidentiality, and access
    control.

    Once this correction is made, I am concerned that the IPsec-related
    access controls will be confused with the access controls being
    discussed in the last paragraph of section 10.  I belive some
    clarifying language is needed.

<Steve>

I was a bit surprised to see the pwe3 architecture document handle TDM,
when we did not see the TDM requirements document.

Nit: 5.4.4: bits 4-11 MUST be ignored by the receiver

10: IPsec does not provide non-repudiation.  A better definition of how
to use IPsec will be necessary in the protocol document; I strongly
suspect that they will *not* find it easy.  This is mostly a heads-up
to the WG to start thinking about it now, and to read
draft-bellovin-useipsec-02.txt (which I've requested publication on as
a BCP).  Perhaps they should consider the RTP security mechanisms,
given that they're apparently leaning towards RTP in any event?

- J


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "David Allan" <dallan@nortelnetworks.com>
Subject: Question on VCCV
Date: Tue, 16 Dec 2003 13:14:17 -0500
Lines: 29
Sender: pwe3-admin@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 16 19:15:08 2003
Return-path: <pwe3-admin@ietf.org>
To: pwe3@ietf.org
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Looking at the current draft, a few questions come to mind.

1) VCCV appears to only allow exclusive selection of one OAM protocol to be
used on the OAM channel. If more than one optional VCCV parameter can be
carried, this is not clear. This does not seem consistent with the text in
section 6 in which the egress advertises capability DU and lets the ingress
choose. Therefore the CC type and CV type fields should be bitmaps not
enums, and the values range 1,2,4,8 etc. So one could specify being able to
accept some number of protocols via some number of mechanisms, and the
ingress picks one. 

2) The draft references the PW PID but does not provide a means of
designating it as an OAM channel. (needs an additional code point in the CC
field). IMHO the next should also simply state "type of control channel" vs.
"type of IP control channel" as PW PID uses a PPP DLL and self identifies
the content.

3) Does the appearance of a private draft in a WG document mean PWE3 has
formally adopted BFD? If so, should the katz draft be renamed?

4) Why are the references to FRF8, Y.17fw, I.555, I.620, Q.933, GTTP, PWREQ,
PWE3FW, and L2SIG included as they have no relevance to the document. IMHO
the Martinisig reference should be updated and actually referenced in the
document if the procedures for VCCV piggyback on it.

cheers
Dave

Quick aside, current posted draft has a few formatting problems ....;-)


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: Question on VCCV
Date: Tue, 16 Dec 2003 15:33:31 -0500
Organization: Cisco Systems, inc.
Lines: 79
Sender: pwe3-admin@ietf.org
References: <FFFC48AEAA5F7447929F4F0D93FCC12D05D09C23@zcard031.ca.nortel.com>
Reply-To: <tnadeau@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Tue Dec 16 21:35:06 2003
Return-path: <pwe3-admin@ietf.org>
To: "'David Allan'" <dallan@nortelnetworks.com>, <pwe3@ietf.org>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D05D09C23@zcard031.ca.nortel.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


>Looking at the current draft, a few questions come to mind.
>
>1) VCCV appears to only allow exclusive selection of one OAM 
>protocol to be used on the OAM channel. If more than one optional VCCV 
>parameter can be
>carried, this is not clear. This does not seem consistent with 
>the text in section 6 in which the egress advertises capability DU and 
>lets the ingress
>choose. Therefore the CC type and CV type fields should be bitmaps not
>enums, and the values range 1,2,4,8 etc. 
>
>So one could specify being able to
>accept some number of protocols via some number of mechanisms, and the
>ingress picks one. 

	Yes, you are correct, the CC and CV types are a bitmask. I
thought I had made that clear before, but it looks like I left
it out. :(

>2) The draft references the PW PID but does not provide a means of
>designating it as an OAM channel. (needs an additional code 
>point in the CC field). IMHO the next should also simply state "type of

>control channel" vs.
>"type of IP control channel" as PW PID uses a PPP DLL and self 
>identifies the content.

	We will make this clearer.

>3) Does the appearance of a private draft in a WG document 
>mean PWE3 has formally adopted BFD? 

> If so, should the katz draft be renamed?

	As far as I know, there is no formal rule
stating that WG drafts cannot reference non-WG
drafts, but I will leave it up to the chairs to
clarify.

>4) Why are the references to FRF8, Y.17fw, I.555, I.620, 
>Q.933, GTTP, PWREQ,
>PWE3FW, and L2SIG included as they have no relevance to the 
>document. 

	I disagree. The PWE3FW is relevant, as it defines the 
architecture onto which this mechanism fits into. 
Y.17fw is a relevant informative reference, as is PWEREQ. 
We need to reorg the references into Informative and 
Normative sections; however.

	I do agree that FRF8, I.555, I.620, and
Q.933 should be removed as they are not referenced. These are
relics from the initial version of the draft that included
the OAM Msg mapping stuff that we pulled out into a
separate draft.

>IMHO
>the Martinisig reference should be updated and actually 
>referenced in the document if the procedures for VCCV piggyback on it.

	Agreed..

	--Tom



>
>cheers
>Dave
>
>Quick aside, current posted draft has a few formatting problems ....;-)
>
>
>_______________________________________________
>pwe3 mailing list
>pwe3@ietf.org
>https://www1.ietf.org/mailman/listinfo/pwe3
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pwe3-atm-encap-04.txt
Date: Tue, 16 Dec 2003 16:02:51 -0500
Lines: 82
Sender: pwe3-admin@ietf.org
Reply-To: Internet-Drafts@ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 16 22:03:05 2003
Return-path: <pwe3-admin@ietf.org>
To: IETF-Announce: ;
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

	Title		: Encapsulation Methods for Transport of ATM 
			  Cells/Frame Over IP and MPLS Networks
	Author(s)	: L. Martini
	Filename	: draft-ietf-pwe3-atm-encap-04.txt
	Pages		: 36
	Date		: 2003-12-16
	
A framework for providing various Layer 1 and Layer 2 services over a
Packet Switched Network has been described in [3]. This draft
provides encapsulation formats and guidelines for transporting a
variety of ATM services over a PSN.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-atm-encap-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-atm-encap-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-atm-encap-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pwe3-control-protocol-05.txt
Date: Tue, 16 Dec 2003 16:03:03 -0500
Lines: 85
Sender: pwe3-admin@ietf.org
Reply-To: Internet-Drafts@ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 16 22:04:02 2003
Return-path: <pwe3-admin@ietf.org>
To: IETF-Announce: ;
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

	Title		: Pseudowire Setup and Maintenance using LDP
	Author(s)	: L. Martini, N. El-Aawar, E. Rosen
	Filename	: draft-ietf-pwe3-control-protocol-05.txt
	Pages		: 31
	Date		: 2003-12-16
	
Layer 2 services (such as Frame Relay, ATM, ethernet) can be
'emulated' over an IP and/or MPLS backbone by encapsulating the layer
2 PDUs and then transmitting them over 'pseudowires'.  It is also
possible to use pseudowires to provide SONET circuit emulation over
an IP and/or MPLS network. This document specifies a protocol for
establishing and maintaining the pseudowires, using extensions to
LDP.  Procedures for encapsulating layer 2 PDUs are specified in a
set of companion documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-control-protocol-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-control-protocol-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pwe3-ethernet-encap-05.txt
Date: Tue, 16 Dec 2003 16:02:57 -0500
Lines: 83
Sender: pwe3-admin@ietf.org
Reply-To: Internet-Drafts@ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 16 22:04:05 2003
Return-path: <pwe3-admin@ietf.org>
To: IETF-Announce: ;
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

	Title		: Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks
	Author(s)	: L. Martini
	Filename	: draft-ietf-pwe3-ethernet-encap-05.txt
	Pages		: 19
	Date		: 2003-12-16
	
An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol
Data Units over an IP or MPLS network. This enables service providers
to offer 'emulated' ethernet services over existing IP or MPLS
networks. This document specifies the encapsulation of Ethernet/802.3
PDUs within a pseudowire. It also specifies the procedures for using
a PW to provide a 'point-to-point ethernet' service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-ethernet-encap-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-ethernet-encap-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Akiva Sadovski <akiva@AXERRA.com>
Subject: RE: Next Generation CO-PS layer network technology?
Date: Wed, 17 Dec 2003 08:33:02 +0200
Lines: 251
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-8"
X-From: pwe3-admin@ietf.org Wed Dec 17 07:36:10 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Maarten.Vissers@alcatel.de'" <Maarten.Vissers@alcatel.de>,
        stds-802-1@ieee.org, tsg15q12@itu.int, pwe3@ietf.org
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Hi Maarten,
  thank you for very interesting NG CO-PS summary. 
1) However i'm wondering whether we really need *both* SNCP and SPRing at
initial stages of
NG CO-PS development.
2) As far as i know, there were some SNCP-like mechanisms for Ethernet under
development, like draft-shah-extreme-eaps-00.txt

My 2c,
  Akiva Sadovski

> -----Original Message-----
> From: Maarten.Vissers@alcatel.de [mailto:Maarten.Vissers@alcatel.de]
> Sent: Friday, December 12, 2003 3:05 PM
> To: stds-802-1@ieee.org; tsg15q12@itu.int; pwe3@ietf.org
> Subject: [PWE3] Next Generation CO-PS layer network technology?
> 
> 
> As we are approaching the end of the year 2003 and many of use looking
> forward to one or more weeks of vacation (to get rid of all left over
> vacation days), I would like to provide some food for your thoughts 
> under the Christmas tree.
> 
> INTRODUCTION
> ------------
> I have the feeling that 2004 will become known in history as the year
> in which we selected/developed the Next Generation Connection Oriented
> Packet Switched (NG CO-PS) layer network technology, which will be the
> successor of FR and ATM. I would therefore like to initiate a 
> discussion
> on this topic.
> 
> CURRENT LANDSCAPE
> -----------------
> When I look at the current NG CO-PS landscape, I see four alternatives
> that are being considered, discussed, investigated, developped and/or
> installed:
> 
> 1) CO-PS MPLS (switched MPLS)
> 2) CO-PS ETH/VLAN (switched Ethernet/switched VLAN)
> 3) CO-PS GFP (switched GFP)
> 4) something new.
> 
> The first three alternatives have as starting point the 
> re-use/multi-use of existing popular frame/packet formats:
> 1) MPLS packet with its shim header (label, EXP, S, TTL):
> 2) tagged MAC frame (ethertype, VLAN ID, priority, CFI)
> 3) GFP-F frame with linear extension header (Channel ID, spare).
> 
> BASIC NG CO-PS CHARACTERISTICS
> ------------------------------
> NG CO-PS frame/packet format needs to support the following fields:
> a) tributary slot identifier (label, VLAN ID, channel ID)
> b) class of service/dropping precedence (EXP, priority)
> 
> NG CO-PS frame/packet format needs to support the following 
> networking capability:
> c) multi-level hierarchy (tunneling) capability to allow it to
>    be used in (metro-)access, metro(-core) and core networks.
> 
> NG CO_PS technology needs to support connection monitoring according
> the G.805 paradigm; this includes:
> d) connection monitoring for each (tunnel) level in the hierarchy
> e) multi-level (nested) connection monitoring capability for user 
>    connections, to allow dedicated connection monitoring for user,
>    service provider and network operator(s) as well as for protection
>    and restoration.
> f) pro-active fault management and performance monitoring OAM for 
>    user connections and hierarchy levels (tunnels)
> g) on-demand fault localisation OAM for user connections and
>    hierarchy levels. 
> 
> Note: Non intrusive monitoring of any connection monitoring level at
> an intermediate point in the connection for the service provider is a
> requirement for today's SDH/SONET and OTH networks, in the 
> absence of a
> standard "service management" architecture. With the work on the 
> Architecture for Services Management (G.asm) being started in Q.12/15,
> the NG CO-PS may not require this non-intrusive connection monitoring 
> of any connection monitoring level. This removes a significant 
> requirement.
> 
> NG CO-PS technology needs to support connection oriented protection
> and restoration; this includes:
> h) subnetwork connection protection (SNCP)
> i) ring protection (SPRing).
> 
> NG CO-PS layer network needs to support:
> j) client/server relationships (mapping, network interworking)
> k) G.805 layer network interworking (service interworking)
> with existing CO-PS layer network technologies.
> 
> 
> EVALUATION OF CURRENT FRAME FORMATS
> -----------------------------------
> The MPLS packet format is considered as it provides the 
> closest match with
> the basic characteristics required for the NG CO-PS technology.
>         a) trib slot id: 20-bit label
>         b) CoS/DP: 3-bit EXP
>         c) hierarchy: infinite tunneling capability
>         d) tunnel conn. mon.: MPLS OAM
>         e) nested conn. mon.: MPLS OAM
>         f) pro-active fm/pm: MPLS OAM (CV, FFD, FDI, BDI)
>         g) on-demand fault loc.: MPLS OAM (ping)
>         h) SNCP: MPLS protection switching
>            Further enhancements/extensions are required.
>         i) SPRing: to be developed
>         j) mapping: IP: available, ATM, FR, ETH: under development
>         k) LN IW: MPLS/ATM, MPLS/FR under development.
> By using MPLS as the NG CO-PS packet format, the "M" in MPLS 
> gets a second
> meaning; this "M" originally referred to it being a protocol 
> that can ride
> over multiple server layer protocols, with the deployment as 
> NG CO-PS it 
> also refers to multiple client layer protocols that can ride over it.
> 
> 
> The Ethernet MAC tagged frame format is considered due to the low cost
> of today's ethernet interface ports. The Ethernet MAC frame 
> is developed
> for use in bridged-ethernet networks; its use as NG CO-PS 
> would require a
> number of extensions:
>         a) trib slot id: 12-bit VLAN ID
>         b) CoS/DP: 3-bit priority
>         c) hierarchy: potential VLAN stacking capability
>            Requires new CO-PS VLAN tags to be defined; QTag and
>            STag should not be used as these are for 
> bridged-ethernet, not
>            for switched-ethernet/VLAN.
>         d) tunnel conn. mon.: to be developed
>         e) nested conn. mon.: to be developed
>         f) pro-active fm/pm: to be developed
>         g) on-demand fault loc.: to be developed.
>            The current bridged-ETH OAM development in Q.3/13 may be
>            the basis for d) to f)
>         h) SNCP: to be developed
>         i) SPRing: to be developed
>         j) mapping: IP, MPLS: available, ATM, FR: ?
>         k) LN IW: ETH/ATM, ETH/FR, ETH/MPLS to be developed?
>         x) development of connection oriented VLAN switching.
> Switched-Ethernet/VLAN will use the ethernet MAC frame as 
> encapsulation
> format for multiple client signals. The implication of this is to be
> understood.
> 
> 
> The GFP-F frame format is considered as it is the latest frame format
> developed within the standards organisation (ITU-T) that traditionally
> defines connection oriented layer technologies. GFP-F is an 
> encapsulation
> frame format and its use as NG CO-PS would require a number 
> of extensions:
>         a) trib slot id: 8-bit channel ID
>            D.371 (SG15, 04/02) proposes a 20-bit Flow ID.
>         b) CoS/DP: to be developed
>            D.370 (SG15, 04/02) proposes a 3-bit Priority field.
>         c) hierarchy: to be developed
>            Requires capability to support stacking in the extension 
> header.
>            58 bytes are available in the extension header 
> area for such
>            purpose. With e.g. 3-bytes per level (20-bit label, 3-bit 
> CoS/DP, 
>            1-bit bottom of stack), 19 levels can be supported.
>         d) tunnel conn. mon.: to be developed
>         e) nested conn. mon.: to be developed
>         f) pro-active fm/pm: to be developed
>         g) on-demand fault loc.: to be developed.
>         h) SNCP: to be developed
>         i) SPRing: to be developed
>         j) mapping: to be developed
>         k) LN IW: to be developed
>         x) development of connection oriented GFP switching.
> 
> 
> CO-EXISTENCE
> ------------
> For the case we will select one of the three existing 
> frame/packet formats 
> 
> as basis for the NG CO-PS layer network, it will have to peacefully 
> co-exist
> with the original application; i.e. the NG CO-PS development 
> should not 
> hijack
> the frame/packet format. This requires cooperation and 
> recognition of the 
> needs
> of both the original and the new NG CO-PS application.
> 
> If the current "owners" of the frame/packet formats (MPLS: 
> IEFT, MAC: IEEE 
> 802,
> GFP-F: ITU-T SG15) are not able/do not want to share their 
> frame/packet 
> format
> with the new NG CO-PS application, that frame/packet format 
> should not be
> considered as a NG CO-PS frame/packet format candidate.
> 
> I am therefore very interested to hear the opinion of the 
> participants of 
> IETF, 
> IEEE 802 and ITU-T SG15 on the multi-use of their 
> frame/packet format as 
> NG CO-PS
> frame/packet format.
> 
> 
> EQUIPMENT
> ---------
> The NG CO-PS layer network will introduce one additional switching 
> technology or
> switching technology profile in the multi service switching platforms 
> (MSSPs).
> 
> Some existing MSSPs may already support elements of the NG 
> CO-PS and/or 
> may be
> upgradable to support NG CO-PS. Others may not support any 
> element of the 
> NG CO-PS
> and may not be upgradable. That's just how life is; it should 
> not play a 
> major role
> in the decision process for the NG CO-PS in my opinion.
> 
> 
> Up to so far. Looking forward to your opinions on this item.
> 
> Regards,
> Maarten
> 
> 
> ---------------------------------------------------------------------
> Maarten Vissers
> Network and Product Strategy - Optical Networks Division
> Alcatel SEL AG 
> Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
> Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
> Mobile: +31 65 141 8140
> Email:Maarten.Vissers@alcatel.de
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: Next Generation CO-PS layer network technology?
Date: Wed, 17 Dec 2003 10:29:00 +0000
Organization: Cisco Systems, Inc.
Lines: 277
Sender: pwe3-admin@ietf.org
References: <AF5018AC03D1D411ABB70002A5091326B29B3A@TLV1>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stds-802-1@ieee.org, tsg15q12@itu.int, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 17 11:30:12 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: "'Maarten.Vissers@alcatel.de'" <Maarten.Vissers@alcatel.de>
In-Reply-To: <AF5018AC03D1D411ABB70002A5091326B29B3A@TLV1>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Maarten

Although this is interesting work, it does not seem to fall
within the charter of PWE3.

The PWE3 charter is concerned with the emulation of services
over the PSN infrastructure for which the IETF is the design
authority. PWE3 would be the right place to consider EMULATING
CO-MPLS over an IETF specified PSN, but it is not the right
place to design CO-MPLS.

This work would seem to be better directed at the MPLS or
TEWG working groups.

- Stewart

Akiva Sadovski wrote:
> Hi Maarten,
>   thank you for very interesting NG CO-PS summary. 
> 1) However i'm wondering whether we really need *both* SNCP and SPRing at
> initial stages of
> NG CO-PS development.
> 2) As far as i know, there were some SNCP-like mechanisms for Ethernet under
> development, like draft-shah-extreme-eaps-00.txt
> 
> My 2c,
>   Akiva Sadovski
> 
> 
>>-----Original Message-----
>>From: Maarten.Vissers@alcatel.de [mailto:Maarten.Vissers@alcatel.de]
>>Sent: Friday, December 12, 2003 3:05 PM
>>To: stds-802-1@ieee.org; tsg15q12@itu.int; pwe3@ietf.org
>>Subject: [PWE3] Next Generation CO-PS layer network technology?
>>
>>
>>As we are approaching the end of the year 2003 and many of use looking
>>forward to one or more weeks of vacation (to get rid of all left over
>>vacation days), I would like to provide some food for your thoughts 
>>under the Christmas tree.
>>
>>INTRODUCTION
>>------------
>>I have the feeling that 2004 will become known in history as the year
>>in which we selected/developed the Next Generation Connection Oriented
>>Packet Switched (NG CO-PS) layer network technology, which will be the
>>successor of FR and ATM. I would therefore like to initiate a 
>>discussion
>>on this topic.
>>
>>CURRENT LANDSCAPE
>>-----------------
>>When I look at the current NG CO-PS landscape, I see four alternatives
>>that are being considered, discussed, investigated, developped and/or
>>installed:
>>
>>1) CO-PS MPLS (switched MPLS)
>>2) CO-PS ETH/VLAN (switched Ethernet/switched VLAN)
>>3) CO-PS GFP (switched GFP)
>>4) something new.
>>
>>The first three alternatives have as starting point the 
>>re-use/multi-use of existing popular frame/packet formats:
>>1) MPLS packet with its shim header (label, EXP, S, TTL):
>>2) tagged MAC frame (ethertype, VLAN ID, priority, CFI)
>>3) GFP-F frame with linear extension header (Channel ID, spare).
>>
>>BASIC NG CO-PS CHARACTERISTICS
>>------------------------------
>>NG CO-PS frame/packet format needs to support the following fields:
>>a) tributary slot identifier (label, VLAN ID, channel ID)
>>b) class of service/dropping precedence (EXP, priority)
>>
>>NG CO-PS frame/packet format needs to support the following 
>>networking capability:
>>c) multi-level hierarchy (tunneling) capability to allow it to
>>   be used in (metro-)access, metro(-core) and core networks.
>>
>>NG CO_PS technology needs to support connection monitoring according
>>the G.805 paradigm; this includes:
>>d) connection monitoring for each (tunnel) level in the hierarchy
>>e) multi-level (nested) connection monitoring capability for user 
>>   connections, to allow dedicated connection monitoring for user,
>>   service provider and network operator(s) as well as for protection
>>   and restoration.
>>f) pro-active fault management and performance monitoring OAM for 
>>   user connections and hierarchy levels (tunnels)
>>g) on-demand fault localisation OAM for user connections and
>>   hierarchy levels. 
>>
>>Note: Non intrusive monitoring of any connection monitoring level at
>>an intermediate point in the connection for the service provider is a
>>requirement for today's SDH/SONET and OTH networks, in the 
>>absence of a
>>standard "service management" architecture. With the work on the 
>>Architecture for Services Management (G.asm) being started in Q.12/15,
>>the NG CO-PS may not require this non-intrusive connection monitoring 
>>of any connection monitoring level. This removes a significant 
>>requirement.
>>
>>NG CO-PS technology needs to support connection oriented protection
>>and restoration; this includes:
>>h) subnetwork connection protection (SNCP)
>>i) ring protection (SPRing).
>>
>>NG CO-PS layer network needs to support:
>>j) client/server relationships (mapping, network interworking)
>>k) G.805 layer network interworking (service interworking)
>>with existing CO-PS layer network technologies.
>>
>>
>>EVALUATION OF CURRENT FRAME FORMATS
>>-----------------------------------
>>The MPLS packet format is considered as it provides the 
>>closest match with
>>the basic characteristics required for the NG CO-PS technology.
>>        a) trib slot id: 20-bit label
>>        b) CoS/DP: 3-bit EXP
>>        c) hierarchy: infinite tunneling capability
>>        d) tunnel conn. mon.: MPLS OAM
>>        e) nested conn. mon.: MPLS OAM
>>        f) pro-active fm/pm: MPLS OAM (CV, FFD, FDI, BDI)
>>        g) on-demand fault loc.: MPLS OAM (ping)
>>        h) SNCP: MPLS protection switching
>>           Further enhancements/extensions are required.
>>        i) SPRing: to be developed
>>        j) mapping: IP: available, ATM, FR, ETH: under development
>>        k) LN IW: MPLS/ATM, MPLS/FR under development.
>>By using MPLS as the NG CO-PS packet format, the "M" in MPLS 
>>gets a second
>>meaning; this "M" originally referred to it being a protocol 
>>that can ride
>>over multiple server layer protocols, with the deployment as 
>>NG CO-PS it 
>>also refers to multiple client layer protocols that can ride over it.
>>
>>
>>The Ethernet MAC tagged frame format is considered due to the low cost
>>of today's ethernet interface ports. The Ethernet MAC frame 
>>is developed
>>for use in bridged-ethernet networks; its use as NG CO-PS 
>>would require a
>>number of extensions:
>>        a) trib slot id: 12-bit VLAN ID
>>        b) CoS/DP: 3-bit priority
>>        c) hierarchy: potential VLAN stacking capability
>>           Requires new CO-PS VLAN tags to be defined; QTag and
>>           STag should not be used as these are for 
>>bridged-ethernet, not
>>           for switched-ethernet/VLAN.
>>        d) tunnel conn. mon.: to be developed
>>        e) nested conn. mon.: to be developed
>>        f) pro-active fm/pm: to be developed
>>        g) on-demand fault loc.: to be developed.
>>           The current bridged-ETH OAM development in Q.3/13 may be
>>           the basis for d) to f)
>>        h) SNCP: to be developed
>>        i) SPRing: to be developed
>>        j) mapping: IP, MPLS: available, ATM, FR: ?
>>        k) LN IW: ETH/ATM, ETH/FR, ETH/MPLS to be developed?
>>        x) development of connection oriented VLAN switching.
>>Switched-Ethernet/VLAN will use the ethernet MAC frame as 
>>encapsulation
>>format for multiple client signals. The implication of this is to be
>>understood.
>>
>>
>>The GFP-F frame format is considered as it is the latest frame format
>>developed within the standards organisation (ITU-T) that traditionally
>>defines connection oriented layer technologies. GFP-F is an 
>>encapsulation
>>frame format and its use as NG CO-PS would require a number 
>>of extensions:
>>        a) trib slot id: 8-bit channel ID
>>           D.371 (SG15, 04/02) proposes a 20-bit Flow ID.
>>        b) CoS/DP: to be developed
>>           D.370 (SG15, 04/02) proposes a 3-bit Priority field.
>>        c) hierarchy: to be developed
>>           Requires capability to support stacking in the extension 
>>header.
>>           58 bytes are available in the extension header 
>>area for such
>>           purpose. With e.g. 3-bytes per level (20-bit label, 3-bit 
>>CoS/DP, 
>>           1-bit bottom of stack), 19 levels can be supported.
>>        d) tunnel conn. mon.: to be developed
>>        e) nested conn. mon.: to be developed
>>        f) pro-active fm/pm: to be developed
>>        g) on-demand fault loc.: to be developed.
>>        h) SNCP: to be developed
>>        i) SPRing: to be developed
>>        j) mapping: to be developed
>>        k) LN IW: to be developed
>>        x) development of connection oriented GFP switching.
>>
>>
>>CO-EXISTENCE
>>------------
>>For the case we will select one of the three existing 
>>frame/packet formats 
>>
>>as basis for the NG CO-PS layer network, it will have to peacefully 
>>co-exist
>>with the original application; i.e. the NG CO-PS development 
>>should not 
>>hijack
>>the frame/packet format. This requires cooperation and 
>>recognition of the 
>>needs
>>of both the original and the new NG CO-PS application.
>>
>>If the current "owners" of the frame/packet formats (MPLS: 
>>IEFT, MAC: IEEE 
>>802,
>>GFP-F: ITU-T SG15) are not able/do not want to share their 
>>frame/packet 
>>format
>>with the new NG CO-PS application, that frame/packet format 
>>should not be
>>considered as a NG CO-PS frame/packet format candidate.
>>
>>I am therefore very interested to hear the opinion of the 
>>participants of 
>>IETF, 
>>IEEE 802 and ITU-T SG15 on the multi-use of their 
>>frame/packet format as 
>>NG CO-PS
>>frame/packet format.
>>
>>
>>EQUIPMENT
>>---------
>>The NG CO-PS layer network will introduce one additional switching 
>>technology or
>>switching technology profile in the multi service switching platforms 
>>(MSSPs).
>>
>>Some existing MSSPs may already support elements of the NG 
>>CO-PS and/or 
>>may be
>>upgradable to support NG CO-PS. Others may not support any 
>>element of the 
>>NG CO-PS
>>and may not be upgradable. That's just how life is; it should 
>>not play a 
>>major role
>>in the decision process for the NG CO-PS in my opinion.
>>
>>
>>Up to so far. Looking forward to your opinions on this item.
>>
>>Regards,
>>Maarten
>>
>>
>>---------------------------------------------------------------------
>>Maarten Vissers
>>Network and Product Strategy - Optical Networks Division
>>Alcatel SEL AG 
>>Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
>>Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
>>Mobile: +31 65 141 8140
>>Email:Maarten.Vissers@alcatel.de
>>
>>_______________________________________________
>>pwe3 mailing list
>>pwe3@ietf.org
>>https://www1.ietf.org/mailman/listinfo/pwe3
>>
> 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "David Allan" <dallan@nortelnetworks.com>
Subject: RE: Question on VCCV
Date: Wed, 17 Dec 2003 10:13:03 -0500
Lines: 81
Sender: pwe3-admin@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 17 16:14:05 2003
Return-path: <pwe3-admin@ietf.org>
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, pwe3@ietf.org
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Hi Tom:

> >So one could specify being able to
> >accept some number of protocols via some number of 
> mechanisms, and the 
> >ingress picks one.
> 
> 	Yes, you are correct, the CC and CV types are a 
> bitmask. I thought I had made that clear before, but it looks 
> like I left it out. :(

Current value for BFD is a 3 (does that mean BFD is a hybrid of LSP-PING and
ICMP? ;-) or are these bit offsets....(if so why start at 1?)

> 
> >2) The draft references the PW PID but does not provide a means of 
> >designating it as an OAM channel. (needs an additional code point in 
> >the CC field). IMHO the next should also simply state "type of
> 
> >control channel" vs.
> >"type of IP control channel" as PW PID uses a PPP DLL and self
> >identifies the content.
> 
> 	We will make this clearer.
OK

> 
> >3) Does the appearance of a private draft in a WG document
> >mean PWE3 has formally adopted BFD? 
> 
> > If so, should the katz draft be renamed?
> 
> 	As far as I know, there is no formal rule
> stating that WG drafts cannot reference non-WG
> drafts, but I will leave it up to the chairs to
> clarify.

As you've introduced a reference to non-WG technology that is not in any
other WG, t'would seem to me that it's now a PW thing. Process wise I
beleive this would have to be resolved before publication as an RFC.


> 
> >4) Why are the references to FRF8, Y.17fw, I.555, I.620,
> >Q.933, GTTP, PWREQ,
> >PWE3FW, and L2SIG included as they have no relevance to the 
> >document. 
> 
> 	I disagree. The PWE3FW is relevant, as it defines the 
> architecture onto which this mechanism fits into. 

OK, but it's not explicitly referenced so should be informative....

> Y.17fw is a relevant informative reference, as is PWEREQ. 

OK, then they also should be moved from the normative references to the
informative section.

> We need to reorg the references into Informative and 
> Normative sections; however.

Well the section titles are there ;-)

> 
> 	I do agree that FRF8, I.555, I.620, and
> Q.933 should be removed as they are not referenced. These are 
> relics from the initial version of the draft that included 
> the OAM Msg mapping stuff that we pulled out into a separate draft.

OK

> >IMHO
> >the Martinisig reference should be updated and actually
> >referenced in the document if the procedures for VCCV 
> piggyback on it.
> 
> 	Agreed..

Great

Dave


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: Question on VCCV
Date: Wed, 17 Dec 2003 10:28:01 -0500
Organization: Cisco Systems, inc.
Lines: 103
Sender: pwe3-admin@ietf.org
References: <FFFC48AEAA5F7447929F4F0D93FCC12D05D09C31@zcard031.ca.nortel.com>
Reply-To: <tnadeau@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Wed Dec 17 16:31:08 2003
Return-path: <pwe3-admin@ietf.org>
To: "'David Allan'" <dallan@nortelnetworks.com>, <pwe3@ietf.org>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D05D09C31@zcard031.ca.nortel.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



>-----Original Message-----
>From: David Allan [mailto:dallan@nortelnetworks.com] 
>Sent: Wednesday, December 17, 2003 10:13 AM
>To: 'tnadeau@cisco.com'; pwe3@ietf.org
>Subject: RE: [PWE3] Question on VCCV
>
>
>Hi Tom:
>
>> >So one could specify being able to
>> >accept some number of protocols via some number of 
>> mechanisms, and the 
>> >ingress picks one.
>> 
>> 	Yes, you are correct, the CC and CV types are a 
>> bitmask. I thought I had made that clear before, but it looks 
>> like I left it out. :(
>
>Current value for BFD is a 3 (does that mean BFD is a hybrid 
>of LSP-PING and ICMP? ;-) or are these bit offsets....(if so why start
at 1?)

	They are bit positions.

>> >2) The draft references the PW PID but does not provide a means of 
>> >designating it as an OAM channel. (needs an additional code 
>point in 
>> >the CC field). IMHO the next should also simply state "type of
>> 
>> >control channel" vs.
>> >"type of IP control channel" as PW PID uses a PPP DLL and self
>> >identifies the content.
>> 
>> 	We will make this clearer.
>OK
>
>> 
>> >3) Does the appearance of a private draft in a WG document
>> >mean PWE3 has formally adopted BFD? 
>> 
>> > If so, should the katz draft be renamed?
>> 
>> 	As far as I know, there is no formal rule
>> stating that WG drafts cannot reference non-WG
>> drafts, but I will leave it up to the chairs to
>> clarify.
>
>As you've introduced a reference to non-WG technology that is 
>not in any
>other WG, t'would seem to me that it's now a PW thing. Process wise I
>beleive this would have to be resolved before publication as an RFC.

	Yes, of course all normative references need
resolution prior to being assigned an RFC number.

>> >4) Why are the references to FRF8, Y.17fw, I.555, I.620,
>> >Q.933, GTTP, PWREQ,
>> >PWE3FW, and L2SIG included as they have no relevance to the 
>> >document. 
>> 
>> 	I disagree. The PWE3FW is relevant, as it defines the 
>> architecture onto which this mechanism fits into. 
>
>OK, but it's not explicitly referenced so should be informative....
>
>> Y.17fw is a relevant informative reference, as is PWEREQ. 
>
>OK, then they also should be moved from the normative references to the
>informative section.
	
	Yup.

>> We need to reorg the references into Informative and 
>> Normative sections; however.
>
>Well the section titles are there ;-)

	*)

	--Tom


>> 
>> 	I do agree that FRF8, I.555, I.620, and
>> Q.933 should be removed as they are not referenced. These are 
>> relics from the initial version of the draft that included 
>> the OAM Msg mapping stuff that we pulled out into a separate draft.
>
>OK
>
>> >IMHO
>> >the Martinisig reference should be updated and actually
>> >referenced in the document if the procedures for VCCV 
>> piggyback on it.
>> 
>> 	Agreed..
>
>Great
>
>Dave
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in
	 PWE3]
Date: Thu, 18 Dec 2003 00:16:01 -0500
Lines: 363
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Thu Dec 18 06:18:14 2003
Return-path: <pwe3-admin@ietf.org>
To: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        Maarten.Vissers@alcatel.de, stbryant@cisco.com
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Neil,

Your email gives me hope that we come to a common understanding. Please see comments in-line.

Peter

> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Saturday, December 13, 2003 11:34 AM
> To: busschbach@lucent.com; Maarten.Vissers@alcatel.de;
> stbryant@cisco.com
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> retention
> in PWE3]
> 
> 
> Peter,  I apologise up-front that this is a longish 
> response....however there are some key points in here.
> 
> <snipped>
> > 
> > You have stated many times that MPLS would have been a better 
> > protocol if it didn't have PHP, MTP and ECMP.
> NH=> Let's be clear here please.  I don't care which specific 
> technology is being discussed, as the only thing that is 
> relevant is the architecture allowed for the network mode 
> that the technology concerned belongs to.  There are but 
> three networking modes and they are all L3 'peers' in an OSI 
> sense.....the L1, L2 and L3 classifications some use mean 
> absolutely nothing, only the modal classification is useful.  
> In a functional architecture sense the co-cs and co-ps modes 
> are increasing constraints on the cnls mode....and the reason 
> we impose these constraints is because they provide (i) major 
> simplification benefits wrt network operation/management, and 
> (ii) a 'connection' is essential for some network services 
> (this also has QoS semantic implications of 'urgency' vs 
> 'importance', especially in private network services.....but 
> that is a story in itself which I do not wish to get into here).
> 
> Now, to obtain these benefits you have to stay within the 
> allowed architecture of the mode, and for the co-cs/ps modes 
> this means the only allowed constructs are p2p and mp2p.   If 
> one uses labels on link-connections and breaks the 
> architecture by doing mp2p merging say, you have no choice 
> but to run p2p constructions above these if the client is not 
> cnls.  That is simply a fact. And you can see this in all the 
> PW stuff, ie in a simple client/server relationship one only 
> needs 1 server trail level to form the link-connections of 
> the client.....in the PW stuff there are always 2 server 
> layer LSPs doing this job.  And the role of the inner LSP is 
> to recover any merging on the outer LSP, ie to provide the 
> identity of the source which otherwise would be lost.  The PW 
> adaptation sits above all this.
> 
> Now we pay a complexity/opex price for the merging (eg only a 
> madman would tell me LSP-Ping is not complex) and we *still* 
> have to run p2p above it. 
> 
> PHP is also an architectural violation which terminates the 
> trail in the wrong place...we have done functional arch 
> modelling of this behaviour that shows the operational 
> consequences and we don't like them.
> 
> ECMP is something else that is concerned with traffic 
> routing.  Now, it is interesting to observe that the whole 
> point of using a server layer is to control the routing of 
> the client layer traffic.....some folks call this TE.  If one 
> then ignores the server layer constructions on routing the 
> traffic by deciding the actual routing to use based on the 
> client then you might be able to switch-off the server layer 
> TE function as its doing effectively nothing.  However, ECMP 
> together with the arch violations of mp2p and PHP do increase 
> the fault-management complexity of the server layer.  But why 
> bother with all this anyway?  If all one wants is true 
> any-any connectivity and one is prepared to make trade-offs 
> here wrt 'soft-SLAs' and the simplicity obtained from using 
> the co modes then just use IP.  BTW: ECMP *within* a single 
> layer network is fine.....its when its applied over more than 
> 1 layer network that the problems arise....and this 
> observation would apply to any technology.
> 
> Now, we are prepared to live with all this stuff....we have 
> to anyway it's out there.   What we find more galling 
> however, is when folks try and tell us this stuff is 
> 'correct' when we can show it plainly is not.


Good! Yes,  the stuff is out there and we need to live with it. If everyone can agree on that, we have a basis for moving forward.

But how about the 'incorrect' design decisions?

I don't think MPLS was designed as a connection-oriented technology. It was designed as a network layer optimized for efficient packet forwarding, emulating characteristics of IP and ATM networks. Given that goal, I think the current MPLS standards meet the objective and in that sense are 'correct'.

But, as you observed before, the fact that MPLS uses labels instead of network-wide unique addresses means by definition that it is a connection-oriented technology. That assertion is debatable. Because of PHP, MPLS is not end-to-end connection-oriented. It wasn't designed to be. So the better question is:

Should MPLS have been designed as a full-blown connection-oriented protocol?

Your observations are right. OAM in a full-blown connection-oriented network is much more straightforward than in MPLS.  However, every engineering effort is a matter of tradeoffs. In this case there is a tradeoff between data plane efficiency and OAM. You clearly value OAM higher than data plane efficiency and given BT's business priorities you may be right. But other people in the past either never considered the tradeoff or they came to different conclusions.

I agree with you that different design decisions would have had their advantages, but I don't think it is fruitful to dwell on that. MPLS may not have been optimized for OAM, but the existing infrastructure provides a platform on top of which other structures (like PWs) can be build that do exhibit the characteristics you need for connection-oriented services and related OAM.


> 
> We also don't like it when folks continually ignore good work 
> like Y.1711 and effectively go about re-inventing it.  Some 
> people say they want operator input here but they only listen 
> to it when it suits them and ignore it when it doesn't.  
> Given there must always be p2p LSPs above any mp2p LSPs to 
> recover from merging we'd like to see Y.1711 run on these top 
> LSPs and use the more complex tools like LSP-Ping to 
> fault-find on-demand in the mp2p layer when (i) the p2p LSPs 
> show a problem and (ii) any lower layer trails (eg in SDH) show clear.


Another step forward! We seem agree that MPLS is not defined as a full-blown connection-oriented protocol; that PWs provide one way to emulate connections; and that we therefore need to run OAM over PWs.

I may have a selective memory, but I don't remember having seen a proposal for running Y.1711 on top of Pseudo Wires. In the past, every email or document that proposed Y.1711 came with a series of objections against the use of PHP, MTP and ECMP. I never got the impression that the proponents of Y.1711 felt that it was usuable in the MPLS networks that exist today.

I think there are two problems with Y.1711 as is:

1) It is defined to be encapsulated with the OAM label. If you do that on top of PWs, it is not guaranteed that the OAM stream follows the same path as the data stream due to ECMP. There have been proposals to introduce a PID, but to me it seems much more straightforward to use the Control Word as proposed in the VCCV draft.

2) Y.1711 defines that messages are sent every second. Given the large number of PWs on a PE, that might be a problem. Therefore I think that the interval should be provisionable by the operator, as is suggested in the BFD draft. Also, I like the "jitter" concept that BFD introduces to avoid synchronization of OAM messages.

I think it would be possible to modify Y.1711 to solve these problems, but I haven't seen much desire to work on this. In my view, Y.1711 has always been presented as a take-it-or-leave-it proposition. In fact, reading the rest of your email I am still not certain whether you consider Y.1711 on top of Pseudo Wires as a sufficient solution.


> 
> So please explain to me what is wrong with that approach 
> before going and re-inventing OAM is some layer above MPLS 
> that only applies at end points and not to the actual 
> network.....and I'll explain later why this is not the right 
> solution anyway for the general case.
> > Suppose that 
> > such a form of MPLS existed. Then it would have been 
> > straightforward to define encapsulation of client protocols 
> > into this form of MPLS.
> NH=> I agree.  And we can easily do it....it only takes the 
> will to want to.
> 
> > Without PHP, only one label would be 
> > required.
> NH=> Not strictly true.  If you constructed what is going on 
> in functional arch terms you would see that 2 labels are 
> required to recover from any mp2p merging in a co-ps mode for 
> a non cnls client.  PHP terminates the server layer trail one 
> hop too short.  And this has its own 
> architectural/operational consequences.  But I do agree it 
> also causes a merge behaviour on the last hop.  Again our 
> functional modelling of this clearly shows this and its consequences.
> 
> > Without ECMP, it would be easy to guarantee that 
> > OAM traffic would fate-share with the client signal. With 
> > such a solution, a PW would be equivalent to an LSP; 
> > Maarten's functional model would apply; and everything would 
> > be fine and dandy.
> > 
> > However, with such a solution, one ends up with a vary large 
> > number of LSPs between to PEs. I suspect that fairly soon 
> > Service Providers would decide that it would make sense to 
> > set up one LSP between two PEs and tunnel all PW-LSPs through 
> > that Tunnel LSP. That would require two layers of OAM. There 
> > would be a need for OAM of the Tunnel LSP as well as OAM for 
> > every PW-LSP running through it.
> NH=> You are now talking about the benefits of using 
> hierarchy...we have been using these techniques for years.  
> One does not have to violate the architecture of the co modes 
> to gain benefits from hierarchy.  And yes you are right you 
> can now run OAM on each hierarchical level since these are 
> layer networks in their own right......you don't have to, but 
> the ability to do so is important.  Also consider the 
> situation when the client and server LSPs are owned by 
> different administrations.  This is nothing new either.  This 
> can exist in ATM between the VP and VC layers, and in SDH 
> between the STM-N/VC4 and VC12 layers for example.  One has 
> to cater for this situation in the general case....and this 
> is fundamentally what is wrong with the PW/VCCV approach that 
> I will come on to shortly.
> > 
> > In your emails, you have made clear that you believe that PW 
> > is broken because it should only be an adaptation function 
> > and instead (because of PHP, MTP and ECMP) it almost seems a 
> > layer in and of itself.
> NH=> Well PWs are for sure *not* a layer network...we do not 
> 'network' PWs....we could, but then this would place a load 
> of extra requirements on them, ie they would need a full 
> functional component set that defines a layer network.  
> Compare to GFP or AALs in ATM, ie these are also not layer networks.
> > 
> > In seems to me that the situation is actually not that much 
> > worse than what I described above for the "ideal" two-layer 
> > case. Personally, I don't have a problem with seeing the PW 
> > as layer on top of an MPLS or IP infrastructure and I don't 
> > see a problem with defining VCCV as the OAM mechanism within 
> > that layer. Philosophically, it might not be pure, but 
> > pragmatically, it seems equivalent to purer solutions.
> > 
> > I believe that with VCCV, and especially with the adition of 
> > BFD, we are on the right way to meet Service Provider needs.
> NH=> Do you?   And are you truly considering the general case 
> here? 


It depends what you mean by "the general case". 

PWs and, as a consequence, VCCV have been defined to run over IP and MPLS networks and, within an MPLS network, do not make any assumptions about the way LSPs between PEs are established. I know you don't agree with that requirement, but within the WG it was accepted as such and within that framework, VCCV provides a general solution.

However, VCCV does not provide a general solution for all connection-oriented services over MPLS networks. The examples of nested and layered LSPs that you give below are obvious cases where PW does not apply. However, in those cases, in all likelyhood, the lower-layer LSPs are setup through RSVP-TE. That has a number of consequences. E.g. the hello and refresh mechanisms that are part of RSVP-TE guarantee detection of the most common network failures. Since this discussion is on the PWE3 mailing list, I don't want to go into more detail, but I am convinced that we have all the tools we need to create sufficiently robust OAM on LSPs that are setup through RSVP-TE. 

I agree with you that we don't have a universal OAM solution that covers all possible cases. After all, MPLS was not designed to enable the simplest possible OAM solution. But we do have solutions for the cases where we need it. 


> There are some serious problems with this idea IMO.  
> If we don't have *networked* OAM within each layer network 
> that is independent and can automatically detect defects (as 
> close to origin as possible, within the scope of the trail 
> termination CI flows) and take appropriate consequent 
> actions, esp FDI generation, we are going to get alarms 
> raised at the wrong locations.  This is not a good idea and I 
> don't think you'll find many operators asking for this 
> behaviour.  You may not have consciously thought about this, 
> but all the stuff I have seen coming from IETF in this area 
> takes for granted the fact that the transport networks, such 
> as SDH/Sonet, are properly specified wrt these OAM functions. 
>  I see various drafts with remarks like 'when a fault is 
> detected.....', but never actually saying *how* this 
> works.....and what they all take for granted is that the 
> transport networks have proper OAM and are going to provide 
> an FDI indication (usually called AIS in co-cs networks).  
> The main purpose of this function is suppress alarms in 
> higher layer networks.....and it needs to be recursively 
> mapped upwards though nested layers.  Now lets look at some 
> interworking cases wrt to what you are advocating:
> 
> Problem 1 - Vertical layer network ownership:
> 
> Suppose we have a set of nested trails where each trail is 
> owned by different operators.  It should be very clear that 
> *each* trail requires its own OAM/fault-management.  And 
> that's exactly what you will find in SDH/Sonet for example.  
> Now consider the case that the nested trails are MPLS LSPs.  
> It should now also be clear that the OAM *must* be a function 
> of the LSP and not some higher level PW adaptation process 
> right at the top of the stack.


Earlier in your email you wrote that you can live with MPLS as is (as long as people acknowledge that it is not perfect). Well, the consequence is that additional constructs are necessary to enable connection-oriented behavior. Pseudo Wire Emulation is one possible construct. Use of RSVP-TE to set up LSPs is another. 

If you use RSVP-TE, the protocol itself provides mechanisms for failure detection that enable the nested fault detection that you describe. And, yes, you need some additional OAM tools, but this mailing list is not the place to discuss that.

My problem with your reasoning is that you use an example where PWE does not apply to demonstrate that the OAM mechanisms defined for PWs are incorrect.

Yes, if MPLS had been defined as a full-blown connection-oriented protocol, then OAM could have been a function of an LSP and it could have been defined in such a way that it applied universally. But that is not the way it is. 

So my question is: are you willing to accept MPLS as is and live with the consequences, or are you going to continue to compare every solution that is proposed with an imaginary alternative that could have been developed if MPLS had been defined differently?


> So clearly if we are going to 
> have MPLS used as the target convergence technology (as many 
> operators/vendors show) it must take this kind of 
> international/multi-party networking scenario into account.  
> This is only possible if the OAM is associated with the 
> entity that is *networked* (ie the LSP) and not some entity 
> that sits above the top-level adaptation function.




> 
> Problem 2 - Horizontal layer partitioning:
> 
> Suppose we have a trail that is owned by some party X that is 
> carried on leased lower layer transport trails within the 
> domains of operators A, B and C.  Now the operators A, B and 
> C can monitor their server layers *iff* these have their own 
> OAM, eg if SDH VC4s say.  But suppose that X wants an MPLS 
> layer LSP carried and suppose the operators wants to also 
> provide the lower layer transport service using MPLS.  One of 
> the beauties of MPLS is that is has no fixed hierarchy, ie it 
> is a true 'digital wrapper' technology.  This means each 
> operator can construct a lower layer LSP across their domain 
> and monitor this.  This technique is not possible in fixed 
> hierarchy networks, eg ATM....and one has to construct 
> (so-called) 'tandem connection monitoring' segments for such 
> a case....and these have architectural limitations in 
> stacking due to the fixed hierarchy.  So once again, we 
> clearly see that the OAM required *must* be a function of the 
> network LSP entity and not some entity that sits above the 
> top-level adaptation function.
> 
> I trust you can agree with these observations.......which 
> are, IMO, quite general requirements of any technology and 
> something that operators would want to see addressed.  Y.1711 
> takes the above cases into account, ie it works at the LSP level. 
> 
> > The current drafts are not perfect and need additional work. 
> > In earlier emails you mentioned the need to define how 
> > Sequence Number errors are translated to failure conditions. 
> > That is a valid criticism and I agree that it should be 
> > addressed.
> NH=> The issue here is this:  OAM should be generic and 
> agnostic of the application above some given server layer, 
> and from the above the OAM *must* be an intrinsic function of 
> the networked entity.....so we must have the same solutions 
> in all cases.  Sequence numbers on the other hand are 
> client-application specific and not a general requirement of 
> the network.  So in the TDM client-application case I can see 
> a role for Seq Numbers.....but as I stated these should be a 
> function of the adaptation of *that* client-application not 
> the general case.  As you also noted, in an earlier mail, 
> that the algorithm is currently flawed anyway;  but in any 
> case the required 're-ordering' behaviour is 
> client-application specific.....this should *not* be a 
> concern of a server layer network as it should not know or 
> care about specific client applications.  These should be 
> designed (via a suitable adaptation say) to cater for 
> specific client needs.  Now, if Seq No.s are left in there 
> for the general case (which I still maintain is wrong) you 
> cannot simply leave them open-ended wrt defect behaviour.  At 
> some point of Seq No corruption a defect will need to be 
> declared and consequent actions taken.  So if these stay when 
> are we going to see this addressed?
> 
> >  On the other hand, blanket statements like "VCCV 
> > is not client-layer independent" are not very helpful, 
> > especially since they are wrong.
> NH=> Well, I hope you understood my earlier arguments than 
> the OAM *must* be a function of the networked entity and why 
> this important.
> > 
> > I hope that we can work our way through the real problems and 
> > come up with a good solution.
> NH=> We certainly can but *iff* we:
> -	start to acknowledge the stuff that is architecturally 
> not right.....yes we have to live with it and we are fine with that;

I acknowledge that in the design of MPLS tradeoffs have been made and I can see why BT believes that some of the consequences are not beneficial for the way BT wants to architect their multi-service core network

> -	start to acknowledge we need all 3 networking modes and 
> allow them to work together in a complimentary manner

No, I don't agree with that. If you truly want three networking modes, you either get three independent networks or an integrated network that runs multiple protocols in a ships-in-the-night fashion. That may be beneficial for OAM, but it has disavantages in other respect.

MPLS has been designed to enable connectionless *behavior* and connection-oriented *behavior* in a network optimized for efficient packet forwarding. It does not incorporate a full-blown connectionless mode and a full-blown connection-oriented mode. This is an important distinction.

I think you are turning things upside down. You want robust OAM and you have concluded that support of the three complimentary networking modes is a straightforward way to achieve that goal. However, you don't seem to realize that such an approach might also have certain disadvantages and that there are other ways to achieve robust OAM (maybe not as elegant, but still good enough). Instead, you claim that the support of three complimentary networking modes is an requirement with universal, undeniable validity. With all due respect, that is simply not the case. It is all a matter of tradeoffs.



> ......you can't crunch them all together like the GMPLS 
> peer-model stuff, its simply a commercial non-starter;
> -	stop ignoring good work like Y.1711 simply because its 
> been done in ITU and by an operator.

As I wrote earlier: I always had the impression that Y.1711 proponents wanted the MPLS network to change so that Y.1711 could be used without modifications. I believe other people had the same impression. Obviously, that didn't help to create much enthousiasm. 


> 
> I still remain hopeful for MPLS....but we will see what happens.
> 
> regards, Neil
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Pattavina, Jeffrey" <jpattavi@harris.com>
Subject: CAS
Date: Thu, 18 Dec 2003 09:40:19 -0500
Lines: 55
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3C574.DBD76330"
X-From: pwe3-admin@ietf.org Thu Dec 18 15:42:15 2003
Return-path: <pwe3-admin@ietf.org>
To: "'pwe3@ietf.org'" <pwe3@ietf.org>
X-Mailer: Internet Mail Service (5.5.2657.72)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3C574.DBD76330
Content-Type: text/plain

What document specifies the method to transport 6.711 voice with CAS ?



Jeffrey S. Pattavina
Chief System Engineer
H A R R I S   CO R P
phone   860-343-9611
efax      501-636-2588


------_=_NextPart_001_01C3C574.DBD76330
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>CAS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">What document specifies the method to =
transport 6.711 voice with CAS ?</FONT>
</P>
<BR>
<BR>

<P><B><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Jeffrey S. =
Pattavina</FONT></B>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 FACE=3D"Arial">Chief System =
Engineer</FONT>
<BR><B><FONT COLOR=3D"#A50021" SIZE=3D2 FACE=3D"Arial">H A R R I =
S&nbsp;&nbsp; CO R P</FONT></B>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">phone&nbsp;&nbsp;</FONT> <FONT COLOR=3D"#0000FF" =
SIZE=3D1 FACE=3D"Arial">860-343-9611</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">efax&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Arial">501-636-2588</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3C574.DBD76330--


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: draft-ietf-pwe3-fragmentation-04.txt - Start of Last Call
Date: Thu, 18 Dec 2003 16:00:53 +0000
Organization: Cisco Systems, Inc.
Lines: 8
Sender: pwe3-admin@ietf.org
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Thu Dec 18 17:02:07 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: "pwe3@ietf.org" <pwe3@ietf.org>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Please consider this the start of last call for

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-04.txt

Because of the long Christmas break here in Europe
we will leave the LC open until 14th January 2004.

- Stewart


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Yaakov Stein" <yaakov_s@rad.com>
Subject: RE: CAS
Date: Thu, 18 Dec 2003 18:26:50 +0200
Lines: 153
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3C583.BD55ADD5"
X-From: pwe3-admin@ietf.org Thu Dec 18 17:29:03 2003
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
Thread-Topic: [PWE3] CAS
Thread-Index: AcPFdTnbSbkf9Jp5RVuTbRbw81oMYQADSOpw
To: "Pattavina, Jeffrey" <jpattavi@harris.com>, <pwe3@ietf.org>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3C583.BD55ADD5
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20
 >  What document specifies the method to transport 6.711 voice with CAS =
?=20
=20
You can transport an entire E1 or T1 with or without CAS using SAToP
( http://www.ietf.org/internet-drafts/draft-ietf-pwe3-satop-00.txt).
However, this method doesn't really know whether there is G.711
or not, or whether or not there is CAS.
=20
You can transport structured n*DS0 with or without CAS using either
the AAL1 mode of=20
http://www.ietf.org/internet-drafts/draft-anavi-tdmoip-06.txt
or=20
http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-07.txt.
=20
In both cases the fractional E1/T1 or n*DS0 is sent
in structured fashion, and CAS is handled via special
signaling substructures.
=20
Finally, you can send N voice (or similar low-rate signals
occupying  64Kbps) channels using the dynamic (AAL2) mode of=20
http://www.ietf.org/internet-drafts/draft-anavi-tdmoip-06.txt .
In this case the transport only takes place when the channel
is "active" (as determined by the CAS signaling).
Optionally one could suppress the channel via VAD.
=20
Y(J)S
=20

------_=_NextPart_001_01C3C583.BD55ADD5
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>CAS</TITLE>

<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2><SPAN =
class=3D230001716-18122003>&nbsp;&gt;=20
&nbsp;</SPAN>What document specifies the method to transport 6.711 voice =
with=20
CAS ?</FONT></FONT></FONT> </DIV>
<DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>You can transport an entire E1 or T1 with or without CAS=20
</FONT></SPAN><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>using SAToP</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>(<A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pwe3-satop-00.txt"=
>http://www.ietf.org/internet-drafts/draft-ietf-pwe3-satop-00.txt</A>).</=
FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>However, this method doesn't really know whether there is=20
G.711</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>or not, or whether or not there is CAS.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>You can transport structured n*DS0 with or without CAS using=20
either</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>the AAL1 mode of </FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-anavi-tdmoip-06.txt">ht=
tp://www.ietf.org/internet-drafts/draft-anavi-tdmoip-06.txt</A></FONT></S=
PAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>or </FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-07.t=
xt">http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-07.txt</=
A>.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>In both cases the fractional E1/T1 or n*DS0 is =
sent</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>in structured fashion, and CAS is handled via =
special</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>signaling substructures.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Finally, you can send N voice (or similar low-rate=20
signals</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>occupying&nbsp; 64Kbps) channels using the dynamic (AAL2)=20
</FONT></SPAN><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>mode of </DIV>
<DIV dir=3Dltr>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-anavi-tdmoip-06.txt">ht=
tp://www.ietf.org/internet-drafts/draft-anavi-tdmoip-06.txt</A>&nbsp;.</F=
ONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003>In this case the =
transport only=20
takes place when the channel</SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003>is "active" (as =
determined by the=20
CAS signaling).</SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003>Optionally one could =
suppress the=20
channel via VAD.</SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D230001716-18122003>Y(J)S</SPAN></DIV>
<DIV dir=3Dltr><SPAN=20
class=3D230001716-18122003></SPAN>&nbsp;</DIV></FONT></SPAN></DIV></BODY>=
</HTML>

------_=_NextPart_001_01C3C583.BD55ADD5--


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "David Allan" <dallan@nortelnetworks.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in
	 PWE3]
Date: Thu, 18 Dec 2003 14:53:28 -0500
Lines: 204
Sender: pwe3-admin@ietf.org
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Thu Dec 18 20:59:08 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Busschbach, Peter B (Peter)'" <busschbach@lucent.com>,
        "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        Maarten.Vissers@alcatel.de, stbryant@cisco.com
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Peter:

Excuse me if I join in on this discussion...

> Good! Yes,  the stuff is out there and we need to live with 
> it. If everyone can agree on that, we have a basis for moving forward.
> 
> But how about the 'incorrect' design decisions?
> 
> I don't think MPLS was designed as a connection-oriented 
> technology. It was designed as a network layer optimized for 
> efficient packet forwarding, emulating characteristics of IP 
> and ATM networks. Given that goal, I think the current MPLS 
> standards meet the objective and in that sense are 'correct'.
> 
> But, as you observed before, the fact that MPLS uses labels 
> instead of network-wide unique addresses means by definition 
> that it is a connection-oriented technology. 

>From a fault management perspective, the artifacts of some classes of MPLS
faults are indistinguishable.

> That assertion 
> is debatable. Because of PHP, MPLS is not end-to-end 
> connection-oriented. 

An LSP has state in each LSR along the path, that would seem to cast a
differing vote. 

Please don't misunderstand me as I debate this topic. I have no religious
convictions as to what MPLS is, I am simply interested in characterizing the
dataplane so I can usefully understand/instrument it. IMHO "control plane
manipulation of a connection oriented dataplane to emulate connectionless
behavior" is the most accurate characterization I've been able to get
comfortable with.

> It wasn't designed to be. So the better 
> question is:
> 
> Should MPLS have been designed as a full-blown 
> connection-oriented protocol?

I think the correct statement is "does such a profile exist?" (and I thought
Maarten expressed that well), IMHO it does. There is nowhere that I've seen
it explicitly stated that one MUST use PHP but it has been presented as an
absolute requirement and regardless of it's merits is now presented as THE
way forward. I would be curious to know if everyone wants to change the MAY
in 3031 to a MUST because that is what I seem to be hearing. I can
understand why some vendors might want the change, but I'd be hard pressed
to understand why providers would want such a change.

To date I've operated on the notion that it is a MAY and implementations may
choose NOT to do PHP with no ill effects. Labelling the LSP e2e has value
independent of the forwarding mode used. 

> Your observations are right. OAM in a full-blown 
> connection-oriented network is much more straightforward than 
> in MPLS.  However, every engineering effort is a matter of 
> tradeoffs. In this case there is a tradeoff between data 
> plane efficiency and OAM. You clearly value OAM higher than 
> data plane efficiency and given BT's business priorities you 
> may be right. But other people in the past either never 
> considered the tradeoff or they came to different conclusions.

I agree that there is a specific trade off in efficiency, nothing is free.
We're interested in 1711 despite the limited applicability (which we saw as
simply low hanging fruit) as the general direction was to keep the
functionality in the data plane and not load the control plane, for any type
of proactive OAM that was a desirable feature, and would enhance determinism
of the OAM component and operations in general. This also meant handling
probes at line rate esp. when considering LDP DU where a large
unsynchronized group could be offering bursts of probes at line rate.

> 
> I agree with you that different design decisions would have 
> had their advantages, but I don't think it is fruitful to 
> dwell on that. MPLS may not have been optimized for OAM, but 
> the existing infrastructure provides a platform on top of 
> which other structures (like PWs) can be build that do 
> exhibit the characteristics you need for connection-oriented 
> services and related OAM.

This seems to be based on the idea that MPLS in general does not benefit
from any additional fault management, only PWs. This I can't agree with. The
difference between an MPLS network and an IP network is an extra control
plane, and extra data plane components (which can break) and it provides
additional on-box instrumentation such as packet counts/FEC. Those extras
need to be accounted for.

> > 
> > We also don't like it when folks continually ignore good work 
> > like Y.1711 and effectively go about re-inventing it.  Some 
> > people say they want operator input here but they only listen 
> > to it when it suits them and ignore it when it doesn't.  
> > Given there must always be p2p LSPs above any mp2p LSPs to 
> > recover from merging we'd like to see Y.1711 run on these top 
> > LSPs and use the more complex tools like LSP-Ping to 
> > fault-find on-demand in the mp2p layer when (i) the p2p LSPs 
> > show a problem and (ii) any lower layer trails (eg in SDH) 
> show clear.
> 
> 
> Another step forward! We seem agree that MPLS is not defined 
> as a full-blown connection-oriented protocol; that PWs 
> provide one way to emulate connections; and that we therefore 
> need to run OAM over PWs.

Not quite parsing, a requirement for OAM is independent of any requirement
for connections....


> 
> I may have a selective memory, but I don't remember having 
> seen a proposal for running Y.1711 on top of Pseudo Wires. 

You are correct in noting you have selective memory...  ;-)
http://www.ietf.org/internet-drafts/draft-allan-y1711-and-lsp-ping-00.txt
http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt
http://www.ietf.org/internet-drafts/draft-allan-y17iw-overview-00.txt
however to be precise it has never been suggested that the WG adopt 1711
explicitly, simply been kept appraised of the work ;-) BTW Y.17iw is now
Y.1712


> In 
> the past, every email or document that proposed Y.1711 came 
> with a series of objections against the use of PHP, MTP and 
> ECMP. I never got the impression that the proponents of 
> Y.1711 felt that it was usuable in the MPLS networks that exist today.
> 
> I think there are two problems with Y.1711 as is:
> 
> 1) It is defined to be encapsulated with the OAM label. If 
> you do that on top of PWs, it is not guaranteed that the OAM 
> stream follows the same path as the data stream due to ECMP. 
> There have been proposals to introduce a PID, but to me it 
> seems much more straightforward to use the Control Word as 
> proposed in the VCCV draft.

You need to separate the functionality from the mechanism to distinguish the
flows. If you draw out the stacks you'd see all proposed mechanisms have
lots of overhead and protocol multiplexing points that could be considered
unnecessary. There is a PID in the IP header a PID in the UDP header, a PID
in the CW. IMHO that is pretty much a wash no matter how you analyze it. 

I suggested to SG13 long ago that we look to obtain either an IP protocol
number or UDP protocol number so that whatever emerged would also apply to
tunnels in general. Unfortunately I did not follow that up with any vigor.

> 
> 2) Y.1711 defines that messages are sent every second. Given 
> the large number of PWs on a PE, that might be a problem. 
> Therefore I think that the interval should be provisionable 
> by the operator, as is suggested in the BFD draft. Also, I 
> like the "jitter" concept that BFD introduces to avoid 
> synchronization of OAM messages.

1711 originates with a specific availability definition, and then defines
the instrumentation to drive the model. That the model does not work under
all modes of MPLS forwarding is understood, no single avalability model
could. Which is why the suite is now getting some other tools.

One problem specific to PWs is that there are clients that have rather
stringent and instrumented availability models (e.g. running ATM I.610 CC).
Simply slowing down the rate of insertion in each PW does not solve this.
Personally I would not want to run one per second over 1000 PWs, I'd rather
run one per second over 1 trunk that carried 1000 PWs and let them inherit
availability state from the trunk so that all clients got what they needed
and probe them uniquely and some very low rate simply for completeness in
coverage, however if I overlay this on ECMP all bets are off as the trunk
probe does not fate share with all the client PWs. The only obvious
conclusion is that not all modes of MPLS forwarding are compatible with all
service requirements....go figure ;-)

Where the jitter capability would help you is if you cannot handle the
messages at line rate therefore pathological and sustained
syncrhonization/clumping is somthing to be ruthlessly avoided. IMO the
requirement to do so is in proportion to message complexity. Our thinking
(some of which is in the old framework draft) was that line rate handling
was an explicit requirement esp. when considering large numbers of unsynched
sources (MP2P ingresses) originating probes. That drove 1711, drives fec-cv
and has other design implications....

> I think it would be possible to modify Y.1711 to solve these 
> problems, but I haven't seen much desire to work on this. In 
> my view, Y.1711 has always been presented as a 
> take-it-or-leave-it proposition. 

Personally I've always seen it as a starting point, not a universal panacea,
and it has been resoundingly criticised as not being a universal panacea.
BTW you have at least one colleague working changes as we speak. 

Unfortunately the whole debate got way too politicized way too early in the
game. Before it was Y1711 it was an internet draft, then a BOF etc. 

BTW OAM is really a very very big topic whereas most of the time we are
discussing fault management and someday may get to performance management.
Can I suggest a blanket text subsititution (FM/PM for OAM) in the mailing
list ;-)

cheers
Dave

<snipped to end>


From owner-mpls@UU.NET  Wed Dec 27 16:41:46 2006
From: Loa Andersson <loa@pi.se>
Subject: Re: [802.1] Re: [PWE3] Next Generation CO-PS layer network technology?
Date: Thu, 18 Dec 2003 23:07:33 +0100
Lines: 294
Sender: owner-mpls@UU.NET
References: <AF5018AC03D1D411ABB70002A5091326B29B3A@TLV1> <3FE02FEC.8020208@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "'Maarten.Vissers@alcatel.de'" <Maarten.Vissers@alcatel.de>,
        stds-802-1@ieee.org, tsg15q12@itu.int, pwe3@ietf.org
X-From: owner-mpls@UU.NET Thu Dec 18 23:20:53 2003
Return-path: <owner-mpls@UU.NET>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: stbryant@cisco.com, MPLS wg <mpls@UU.NET>, te-wg@ops.ietf.org
In-Reply-To: <3FE02FEC.8020208@cisco.com>
Precedence: bulk
Status: O

MPLS and TEWG,

this is a mail that has been on the PWE3 mailings list, since it
concerns the tewg and mpls wg, I'm forwarding it the working
group mailing lists also.

As Stewart says it is interesting, but I often find it more
interesting to read things I disaggree with, than things I aggree with.

My take is that CO-MPLS is out of scope for the MPLS WG also.


/Loa

Stewart Bryant wrote:

>
> Maarten
>
> Although this is interesting work, it does not seem to fall
> within the charter of PWE3.
>
> The PWE3 charter is concerned with the emulation of services
> over the PSN infrastructure for which the IETF is the design
> authority. PWE3 would be the right place to consider EMULATING
> CO-MPLS over an IETF specified PSN, but it is not the right
> place to design CO-MPLS.
>
> This work would seem to be better directed at the MPLS or
> TEWG working groups.
>
> - Stewart
>
> Akiva Sadovski wrote:
>
>> Hi Maarten,
>>   thank you for very interesting NG CO-PS summary. 1) However i'm 
>> wondering whether we really need *both* SNCP and SPRing at
>> initial stages of
>> NG CO-PS development.
>> 2) As far as i know, there were some SNCP-like mechanisms for 
>> Ethernet under
>> development, like draft-shah-extreme-eaps-00.txt
>>
>> My 2c,
>>   Akiva Sadovski
>>
>>
>>> -----Original Message-----
>>> From: Maarten.Vissers@alcatel.de [mailto:Maarten.Vissers@alcatel.de]
>>> Sent: Friday, December 12, 2003 3:05 PM
>>> To: stds-802-1@ieee.org; tsg15q12@itu.int; pwe3@ietf.org
>>> Subject: [PWE3] Next Generation CO-PS layer network technology?
>>>
>>>
>>> As we are approaching the end of the year 2003 and many of use looking
>>> forward to one or more weeks of vacation (to get rid of all left over
>>> vacation days), I would like to provide some food for your thoughts 
>>> under the Christmas tree.
>>>
>>> INTRODUCTION
>>> ------------
>>> I have the feeling that 2004 will become known in history as the year
>>> in which we selected/developed the Next Generation Connection Oriented
>>> Packet Switched (NG CO-PS) layer network technology, which will be the
>>> successor of FR and ATM. I would therefore like to initiate a 
>>> discussion
>>> on this topic.
>>>
>>> CURRENT LANDSCAPE
>>> -----------------
>>> When I look at the current NG CO-PS landscape, I see four alternatives
>>> that are being considered, discussed, investigated, developped and/or
>>> installed:
>>>
>>> 1) CO-PS MPLS (switched MPLS)
>>> 2) CO-PS ETH/VLAN (switched Ethernet/switched VLAN)
>>> 3) CO-PS GFP (switched GFP)
>>> 4) something new.
>>>
>>> The first three alternatives have as starting point the 
>>> re-use/multi-use of existing popular frame/packet formats:
>>> 1) MPLS packet with its shim header (label, EXP, S, TTL):
>>> 2) tagged MAC frame (ethertype, VLAN ID, priority, CFI)
>>> 3) GFP-F frame with linear extension header (Channel ID, spare).
>>>
>>> BASIC NG CO-PS CHARACTERISTICS
>>> ------------------------------
>>> NG CO-PS frame/packet format needs to support the following fields:
>>> a) tributary slot identifier (label, VLAN ID, channel ID)
>>> b) class of service/dropping precedence (EXP, priority)
>>>
>>> NG CO-PS frame/packet format needs to support the following 
>>> networking capability:
>>> c) multi-level hierarchy (tunneling) capability to allow it to
>>>   be used in (metro-)access, metro(-core) and core networks.
>>>
>>> NG CO_PS technology needs to support connection monitoring according
>>> the G.805 paradigm; this includes:
>>> d) connection monitoring for each (tunnel) level in the hierarchy
>>> e) multi-level (nested) connection monitoring capability for user   
>>> connections, to allow dedicated connection monitoring for user,
>>>   service provider and network operator(s) as well as for protection
>>>   and restoration.
>>> f) pro-active fault management and performance monitoring OAM for   
>>> user connections and hierarchy levels (tunnels)
>>> g) on-demand fault localisation OAM for user connections and
>>>   hierarchy levels.
>>> Note: Non intrusive monitoring of any connection monitoring level at
>>> an intermediate point in the connection for the service provider is a
>>> requirement for today's SDH/SONET and OTH networks, in the absence of a
>>> standard "service management" architecture. With the work on the 
>>> Architecture for Services Management (G.asm) being started in Q.12/15,
>>> the NG CO-PS may not require this non-intrusive connection 
>>> monitoring of any connection monitoring level. This removes a 
>>> significant requirement.
>>>
>>> NG CO-PS technology needs to support connection oriented protection
>>> and restoration; this includes:
>>> h) subnetwork connection protection (SNCP)
>>> i) ring protection (SPRing).
>>>
>>> NG CO-PS layer network needs to support:
>>> j) client/server relationships (mapping, network interworking)
>>> k) G.805 layer network interworking (service interworking)
>>> with existing CO-PS layer network technologies.
>>>
>>>
>>> EVALUATION OF CURRENT FRAME FORMATS
>>> -----------------------------------
>>> The MPLS packet format is considered as it provides the closest 
>>> match with
>>> the basic characteristics required for the NG CO-PS technology.
>>>        a) trib slot id: 20-bit label
>>>        b) CoS/DP: 3-bit EXP
>>>        c) hierarchy: infinite tunneling capability
>>>        d) tunnel conn. mon.: MPLS OAM
>>>        e) nested conn. mon.: MPLS OAM
>>>        f) pro-active fm/pm: MPLS OAM (CV, FFD, FDI, BDI)
>>>        g) on-demand fault loc.: MPLS OAM (ping)
>>>        h) SNCP: MPLS protection switching
>>>           Further enhancements/extensions are required.
>>>        i) SPRing: to be developed
>>>        j) mapping: IP: available, ATM, FR, ETH: under development
>>>        k) LN IW: MPLS/ATM, MPLS/FR under development.
>>> By using MPLS as the NG CO-PS packet format, the "M" in MPLS gets a 
>>> second
>>> meaning; this "M" originally referred to it being a protocol that 
>>> can ride
>>> over multiple server layer protocols, with the deployment as NG 
>>> CO-PS it also refers to multiple client layer protocols that can 
>>> ride over it.
>>>
>>>
>>> The Ethernet MAC tagged frame format is considered due to the low cost
>>> of today's ethernet interface ports. The Ethernet MAC frame is 
>>> developed
>>> for use in bridged-ethernet networks; its use as NG CO-PS would 
>>> require a
>>> number of extensions:
>>>        a) trib slot id: 12-bit VLAN ID
>>>        b) CoS/DP: 3-bit priority
>>>        c) hierarchy: potential VLAN stacking capability
>>>           Requires new CO-PS VLAN tags to be defined; QTag and
>>>           STag should not be used as these are for bridged-ethernet, 
>>> not
>>>           for switched-ethernet/VLAN.
>>>        d) tunnel conn. mon.: to be developed
>>>        e) nested conn. mon.: to be developed
>>>        f) pro-active fm/pm: to be developed
>>>        g) on-demand fault loc.: to be developed.
>>>           The current bridged-ETH OAM development in Q.3/13 may be
>>>           the basis for d) to f)
>>>        h) SNCP: to be developed
>>>        i) SPRing: to be developed
>>>        j) mapping: IP, MPLS: available, ATM, FR: ?
>>>        k) LN IW: ETH/ATM, ETH/FR, ETH/MPLS to be developed?
>>>        x) development of connection oriented VLAN switching.
>>> Switched-Ethernet/VLAN will use the ethernet MAC frame as encapsulation
>>> format for multiple client signals. The implication of this is to be
>>> understood.
>>>
>>>
>>> The GFP-F frame format is considered as it is the latest frame format
>>> developed within the standards organisation (ITU-T) that traditionally
>>> defines connection oriented layer technologies. GFP-F is an 
>>> encapsulation
>>> frame format and its use as NG CO-PS would require a number of 
>>> extensions:
>>>        a) trib slot id: 8-bit channel ID
>>>           D.371 (SG15, 04/02) proposes a 20-bit Flow ID.
>>>        b) CoS/DP: to be developed
>>>           D.370 (SG15, 04/02) proposes a 3-bit Priority field.
>>>        c) hierarchy: to be developed
>>>           Requires capability to support stacking in the extension 
>>> header.
>>>           58 bytes are available in the extension header area for such
>>>           purpose. With e.g. 3-bytes per level (20-bit label, 3-bit 
>>> CoS/DP,           1-bit bottom of stack), 19 levels can be supported.
>>>        d) tunnel conn. mon.: to be developed
>>>        e) nested conn. mon.: to be developed
>>>        f) pro-active fm/pm: to be developed
>>>        g) on-demand fault loc.: to be developed.
>>>        h) SNCP: to be developed
>>>        i) SPRing: to be developed
>>>        j) mapping: to be developed
>>>        k) LN IW: to be developed
>>>        x) development of connection oriented GFP switching.
>>>
>>>
>>> CO-EXISTENCE
>>> ------------
>>> For the case we will select one of the three existing frame/packet 
>>> formats
>>> as basis for the NG CO-PS layer network, it will have to peacefully 
>>> co-exist
>>> with the original application; i.e. the NG CO-PS development should 
>>> not hijack
>>> the frame/packet format. This requires cooperation and recognition 
>>> of the needs
>>> of both the original and the new NG CO-PS application.
>>>
>>> If the current "owners" of the frame/packet formats (MPLS: IEFT, 
>>> MAC: IEEE 802,
>>> GFP-F: ITU-T SG15) are not able/do not want to share their 
>>> frame/packet format
>>> with the new NG CO-PS application, that frame/packet format should 
>>> not be
>>> considered as a NG CO-PS frame/packet format candidate.
>>>
>>> I am therefore very interested to hear the opinion of the 
>>> participants of IETF, IEEE 802 and ITU-T SG15 on the multi-use of 
>>> their frame/packet format as NG CO-PS
>>> frame/packet format.
>>>
>>>
>>> EQUIPMENT
>>> ---------
>>> The NG CO-PS layer network will introduce one additional switching 
>>> technology or
>>> switching technology profile in the multi service switching 
>>> platforms (MSSPs).
>>>
>>> Some existing MSSPs may already support elements of the NG CO-PS 
>>> and/or may be
>>> upgradable to support NG CO-PS. Others may not support any element 
>>> of the NG CO-PS
>>> and may not be upgradable. That's just how life is; it should not 
>>> play a major role
>>> in the decision process for the NG CO-PS in my opinion.
>>>
>>>
>>> Up to so far. Looking forward to your opinions on this item.
>>>
>>> Regards,
>>> Maarten
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Maarten Vissers
>>> Network and Product Strategy - Optical Networks Division
>>> Alcatel SEL AG Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
>>> Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
>>> Mobile: +31 65 141 8140
>>> Email:Maarten.Vissers@alcatel.de
>>>
>>> _______________________________________________
>>> pwe3 mailing list
>>> pwe3@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/pwe3
>>>
>>
>>
>> _______________________________________________
>> pwe3 mailing list
>> pwe3@ietf.org
>> https://www1.ietf.org/mailman/listinfo/pwe3
>>
>>
>
>
> =>IEEE 802.1 Email List user information:
> http://www.ieee802.org/1/email-pages/
>
>

-- 

Loa Andersson

mobile +46 739 81 21 64





From owner-mpls@UU.NET  Wed Dec 27 16:41:46 2006
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Subject: RE: [802.1] Re: [PWE3] Next Generation CO-PS layer network techno
	logy?
Date: Fri, 19 Dec 2003 00:13:57 +0100
Lines: 13
Sender: owner-mpls@UU.NET
Mime-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Cc: "'Maarten.Vissers@alcatel.de'" <Maarten.Vissers@alcatel.de>,
        stds-802-1@ieee.org, tsg15q12@itu.int, pwe3@ietf.org
X-From: owner-mpls@UU.NET Fri Dec 19 00:24:09 2003
Return-path: <owner-mpls@UU.NET>
To: Loa Andersson <loa@pi.se>, stbryant@cisco.com, MPLS wg <mpls@UU.NET>,
        te-wg@ops.ietf.org
X-Mailer: Internet Mail Service (5.5.2656.59)
Precedence: bulk
Status: O

The only thing I REALLY HOPE for is that we will NOT GET
a lot of cross-posting on this/these topics. 

I do not believe that the topic belongs on TEWG, but I will
let the TEWG chairs speak too. In any event, the TEWG is
preparing to close down. 

I wish people create a new mlist for this and use that SINGLE
list for discussions.

Thanks,
Bert 



From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in
	 PWE3]
Date: Thu, 18 Dec 2003 16:44:04 -0500
Lines: 62
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Fri Dec 19 01:01:15 2003
Return-path: <pwe3-admin@ietf.org>
To: "'David Allan'" <dallan@nortelnetworks.com>,
        "'neil.2.harrison@bt.com'"
	 <neil.2.harrison@bt.com>,
        Maarten.Vissers@alcatel.de, stbryant@cisco.com
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


> -----Original Message-----
> From: David Allan [mailto:dallan@nortelnetworks.com]
> Sent: Thursday, December 18, 2003 2:53 PM
> To: 'Busschbach, Peter B (Peter)'; 'neil.2.harrison@bt.com';
> Maarten.Vissers@alcatel.de; stbryant@cisco.com
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> retention
> in PWE3]
> 
> 
[snipped]

> One problem specific to PWs is that there are clients that have rather
> stringent and instrumented availability models (e.g. running 
> ATM I.610 CC).
> Simply slowing down the rate of insertion in each PW does not 
> solve this.

Hi Dave,

I have picked one paragraph from your email to illustrate the basic notion that I tried to get across in an earlier email: we will not make any progress on OAM if we make blanket statements. We have to look at specific situations and discuss what works and what doesn't. (BTW: I am not suggesting that your email was full with blanket statements. I just want to further explain my believes)

This is one example: we need to run Y.1711 at a fast rate, because client protocols run at a fast rate.

Why is that? If ATM already runs a connectivity check in every VC and VP at a rate of one CC cell per second, why would you even bother with a connectivity check in the underlying PW or LSP? I understand that it could help with fault isolation, but:

- Service Providers will often use Fault Management systems that are unfazed by a large number of alarms and that take care of alarm correlation and fault isolation.

- The ATM network will start rerouting VCs anyway, whether it is because of AIS and RDI indications, or whether it detected loss of connectivity autonomously.

In fact, given that second point, I think it is much more important that the MPLS core network provides extremely fast protection switching in order to avoid VC restoration (i.e. FRR), than that it supports a Fault Management protocol with a periodic connectivity check.


> Personally I would not want to run one per second over 1000 
> PWs, I'd rather
> run one per second over 1 trunk that carried 1000 PWs and let 
> them inherit
> availability state from the trunk so that all clients got 
> what they needed
> and probe them uniquely and some very low rate simply for 
> completeness in coverage,

In my view VCCV provides tools. It is not a mandate to use it.

It is my expectation that PW emulation of ATM will practically always happen over LSPs that are set up with RSVP-TE. In that case, I think it is fairly straightforward to do Fault Management in the transport LSP. There is no need to worry about ECMP, since RSVP-TE nails down a unique path (unless you use hierarchical LSPs, as Curtis V. pointed out on the MPLS mailing list). As mentioned above, you would probably not need a fast Connectivity Verification, but you could rely on RSVP-TE's ability to rapidly react to network failures. To protect against additional failures like mismerging or misbranching you could run LSP_Ping. In addition, you would have to protect against errors in PW labeling so you would have to run VCCV-Ping as well. However, both LSP-Ping and VCCV-Ping could be run at a low frequence. 

In summary, given the specific implementation chosen by the Service Provider, one can select the tools that work best. 

> however if I overlay this on ECMP all bets are off 
> as the trunk
> probe does not fate share with all the client PWs. The only obvious
> conclusion is that not all modes of MPLS forwarding are 
> compatible with all
> service requirements....go figure ;-)

But that is exactly the issue. If the Service Provider decides to setup Transport LSPs with RSVP-TE, ECMP is not an issue and a set of tools is available to do Fault Management.

If on the other hand the Service Provider runs PWs over a core where LSPs are setup autonomously through LSP, ECMP might be an issue. This might cause the Service Provider to decide to run Fault Management protocols over PWs rather than over the underlying LSPs. In that case VCCV specifies the tools.

[snipped to end]


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Peter Willis <pjw@ip-engineering.bt.com>
Subject: Re: PW functional model and its OAM [was: FCS retention in PWE3]
Date: Fri, 19 Dec 2003 15:01:25 +0000
Lines: 28
Sender: pwe3-admin@ietf.org
References: <B99995113B318D44BBE87DC50092EDA90C0D5612@nj7460exch006u.ho.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        Maarten.Vissers@alcatel.de, stbryant@cisco.com, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Fri Dec 19 16:03:03 2003
Return-path: <pwe3-admin@ietf.org>
X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI]
To: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
In-reply-to: Your message of "Thu, 18 Dec 2003 00:16:01 EST."
             <B99995113B318D44BBE87DC50092EDA90C0D5612@nj7460exch006u.ho.lucent.com> 
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Colleagues,

First a comment on carrier strategy & requirements then comments on VCCV & 
RSVP-TE detail.

In terms of Fault & Performance Management versus efficient packet forwarding 
the message from BT is very clear. Customer experience is the most important 
thing to us. The customer must never see a fault.  Five 9's reliability & sub 50
msec fast reroute is insignificant if it takes us N hours to locate a fault.
We also aim to reduce Operational costs & we can buy a lot of extra-gates in
ASICs for the recurring costs of experts to locate faults. Carriers won't do
PWE3 or core network convergence to only save capex (that's not where the major
costs lie) but they do it to reduce opex as well. The inability to fault manage 
efficiently increase opex costs and negates the reason to do PWE3 or network
convergence. Seems to me the carrier version of PWE3 starts with "how do
we reduce operational expediture?".

Does VCCV detect swapped or merged LSPs e.g. at the egress 2 LSPs have each 
others' labels or 2 LSPs have merged into 1 label by a fault condition? What's 
the risk of an LSP being sent to the wrong egress and the discriminators still 
being valid?

If we are running graceful restart RSVP to protect our forwarding against 
control plane outages then don't we need to run a data plane liveness test 
(like BFD) to check the forwarding plane is still available whilst the 
control-plane is restarting? 

PeterW.


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "David Allan" <dallan@nortelnetworks.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in
	 PWE3]
Date: Fri, 19 Dec 2003 11:03:30 -0500
Lines: 101
Sender: pwe3-admin@ietf.org
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Fri Dec 19 17:11:07 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Busschbach, Peter B (Peter)'" <busschbach@lucent.com>,
        "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        Maarten.Vissers@alcatel.de, stbryant@cisco.com
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Hi Peter:

> I have picked one paragraph from your email to illustrate the 
> basic notion that I tried to get across in an earlier email: 
> we will not make any progress on OAM if we make blanket 
> statements. We have to look at specific situations and 
> discuss what works and what doesn't. (BTW: I am not 
> suggesting that your email was full with blanket statements. 
> I just want to further explain my believes)
> 
> This is one example: we need to run Y.1711 at a fast rate, 
> because client protocols run at a fast rate.
> 
> Why is that? If ATM already runs a connectivity check in 
> every VC and VP at a rate of one CC cell per second, why 
> would you even bother with a connectivity check in the 
> underlying PW or LSP? I understand that it could help with 
> fault isolation, but:
 
As I indicated, my preferred solution is to use hierarchy. If one trunk can
take action and do alarm suppression for its clients you're much better off.
Running CC and probing on a 1:1 VCC-PW basis I would agree is wasteful and
not somthing I would do. If I have a trunk, some client VCCs MAY be running
CC, some may simply depend on getting AIS from the infrastructure.

> - Service Providers will often use Fault Management systems 
> that are unfazed by a large number of alarms and that take 
> care of alarm correlation and fault isolation.

Yes, however IMO that is a lot of churn and stress to propagate upwards.
Plus a reasonable assumption is that the management systems are not
integrated between ATM (for example) and MPLS and the networks MAY be
different operators. Disjoint systems do not correlate faults.
 
> - The ATM network will start rerouting VCs anyway, whether it 
> is because of AIS and RDI indications, or whether it detected 
> loss of connectivity autonomously.

The only way you'll get AIS/RDI from a failure in the PW space is if there
is a detection mechanism that picks off unrecoverable errors and notifies
the egress PE to commence AIS insertion. AIS CAN also act as a hold off
mechanism (please do not adjust your set, someone else has detected the
problem).

> 
> In fact, given that second point, I think it is much more 
> important that the MPLS core network provides extremely fast 
> protection switching in order to avoid VC restoration (i.e. 
> FRR), than that it supports a Fault Management protocol with 
> a periodic connectivity check.

You'll still need resiliency at the ATM layer as the PEs are otherwise
single points of failure that FRR (for example) will not recover from. 

Just to play devils advocate, I could also suggest that by the same logic,
SONET resotration below MPLS would be preferable ;-)

> > Personally I would not want to run one per second over 1000
> > PWs, I'd rather
> > run one per second over 1 trunk that carried 1000 PWs and let 
> > them inherit
> > availability state from the trunk so that all clients got 
> > what they needed
> > and probe them uniquely and some very low rate simply for 
> > completeness in coverage,
> 
> In my view VCCV provides tools. It is not a mandate to use it.

I'm not getting your point.

> It is my expectation that PW emulation of ATM will 
> practically always happen over LSPs that are set up with 
> RSVP-TE. In that case, I think it is fairly straightforward 
> to do Fault Management in the transport LSP. 

Agreed.

> There is no need 
> to worry about ECMP, since RSVP-TE nails down a unique path 
> (unless you use hierarchical LSPs, as Curtis V. pointed out 
> on the MPLS mailing list). As mentioned above, you would 
> probably not need a fast Connectivity Verification, but you 
> could rely on RSVP-TE's ability to rapidly react to network 
> failures. To protect against additional failures like 
> mismerging or misbranching you could run LSP_Ping. In 
> addition, you would have to protect against errors in PW 
> labeling so you would have to run VCCV-Ping as well. However, 
> both LSP-Ping and VCCV-Ping could be run at a low frequence. 

ideally in one way mode as the egress detecting problems is somewhat more
useful ;-)

> 
> In summary, given the specific implementation chosen by the 
> Service Provider, one can select the tools that work best. 

Sounds like we need to write a BCP document instead of discussing
possiblities....:-)

cheers
Dave


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in PWE3]
Date: Fri, 19 Dec 2003 12:36:23 -0500
Organization: Cisco Systems, inc.
Lines: 148
Sender: pwe3-admin@ietf.org
References: <FFFC48AEAA5F7447929F4F0D93FCC12D05D09C5A@zcard031.ca.nortel.com>
Reply-To: <tnadeau@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Fri Dec 19 18:38:06 2003
Return-path: <pwe3-admin@ietf.org>
To: "'David Allan'" <dallan@nortelnetworks.com>,
        "'Busschbach, Peter B \(Peter\)'" <busschbach@lucent.com>,
        <neil.2.harrison@bt.com>, <Maarten.Vissers@alcatel.de>,
        <stbryant@cisco.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D05D09C5A@zcard031.ca.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



> -----Original Message-----
> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On 
> Behalf Of David Allan
> Sent: Friday, December 19, 2003 11:04 AM
> To: 'Busschbach, Peter B (Peter)'; 'neil.2.harrison@bt.com'; 
> Maarten.Vissers@alcatel.de; stbryant@cisco.com
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> retention in PWE3]
> 
> 
> Hi Peter:
> 
> > I have picked one paragraph from your email to illustrate the 
> > basic notion that I tried to get across in an earlier email: 
> > we will not make any progress on OAM if we make blanket 
> > statements. We have to look at specific situations and 
> > discuss what works and what doesn't. (BTW: I am not 
> > suggesting that your email was full with blanket statements. 
> > I just want to further explain my believes)
> > 
> > This is one example: we need to run Y.1711 at a fast rate, 
> > because client protocols run at a fast rate.
> > 
> > Why is that? If ATM already runs a connectivity check in 
> > every VC and VP at a rate of one CC cell per second, why 
> > would you even bother with a connectivity check in the 
> > underlying PW or LSP? I understand that it could help with 
> > fault isolation, but:
>  
> As I indicated, my preferred solution is to use hierarchy. If 
> one trunk can
> take action and do alarm suppression for its clients you're 
> much better off.
> Running CC and probing on a 1:1 VCC-PW basis I would agree is 
> wasteful and
> not somthing I would do. If I have a trunk, some client VCCs 
> MAY be running
> CC, some may simply depend on getting AIS from the infrastructure.

	OTOH, you may wish to periodically verify
imposition/disposition,
which simply checking the transport trunks doesn't achieve.

> > - Service Providers will often use Fault Management systems 
> > that are unfazed by a large number of alarms and that take 
> > care of alarm correlation and fault isolation.
> 
> Yes, however IMO that is a lot of churn and stress to 
> propagate upwards.
> Plus a reasonable assumption is that the management systems are not
> integrated between ATM (for example) and MPLS and the networks MAY be
> different operators. Disjoint systems do not correlate faults.

	In some cases they do not, but in others they do. Be careful
about generalizing. I know providers that have systems in both
areas you describe. There are certainly systems that can handle lots 
of notifications/alarms because of the deployment architecture. 
It is of course, preferred to have fewer alarms, but I have been 
told by some that more are better as long as there are no duplicates
(i.e.: ifDown.1 + ifDown.1).

	--Tom



> > - The ATM network will start rerouting VCs anyway, whether it 
> > is because of AIS and RDI indications, or whether it detected 
> > loss of connectivity autonomously.
> 
> The only way you'll get AIS/RDI from a failure in the PW 
> space is if there
> is a detection mechanism that picks off unrecoverable errors 
> and notifies
> the egress PE to commence AIS insertion. AIS CAN also act as 
> a hold off
> mechanism (please do not adjust your set, someone else has 
> detected the
> problem).
> 
> > 
> > In fact, given that second point, I think it is much more 
> > important that the MPLS core network provides extremely fast 
> > protection switching in order to avoid VC restoration (i.e. 
> > FRR), than that it supports a Fault Management protocol with 
> > a periodic connectivity check.
> 
> You'll still need resiliency at the ATM layer as the PEs are otherwise
> single points of failure that FRR (for example) will not 
> recover from. 
> 
> Just to play devils advocate, I could also suggest that by 
> the same logic,
> SONET resotration below MPLS would be preferable ;-)
> 
> > > Personally I would not want to run one per second over 1000
> > > PWs, I'd rather
> > > run one per second over 1 trunk that carried 1000 PWs and let 
> > > them inherit
> > > availability state from the trunk so that all clients got 
> > > what they needed
> > > and probe them uniquely and some very low rate simply for 
> > > completeness in coverage,
> > 
> > In my view VCCV provides tools. It is not a mandate to use it.
> 
> I'm not getting your point.
> 
> > It is my expectation that PW emulation of ATM will 
> > practically always happen over LSPs that are set up with 
> > RSVP-TE. In that case, I think it is fairly straightforward 
> > to do Fault Management in the transport LSP. 
> 
> Agreed.
> 
> > There is no need 
> > to worry about ECMP, since RSVP-TE nails down a unique path 
> > (unless you use hierarchical LSPs, as Curtis V. pointed out 
> > on the MPLS mailing list). As mentioned above, you would 
> > probably not need a fast Connectivity Verification, but you 
> > could rely on RSVP-TE's ability to rapidly react to network 
> > failures. To protect against additional failures like 
> > mismerging or misbranching you could run LSP_Ping. In 
> > addition, you would have to protect against errors in PW 
> > labeling so you would have to run VCCV-Ping as well. However, 
> > both LSP-Ping and VCCV-Ping could be run at a low frequence. 
> 
> ideally in one way mode as the egress detecting problems is 
> somewhat more
> useful ;-)
> 
> > 
> > In summary, given the specific implementation chosen by the 
> > Service Provider, one can select the tools that work best. 
> 
> Sounds like we need to write a BCP document instead of discussing
> possiblities....:-)
> 
> cheers
> Dave
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "David Allan" <dallan@nortelnetworks.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in
	 PWE3]
Date: Fri, 19 Dec 2003 13:54:25 -0500
Lines: 43
Sender: pwe3-admin@ietf.org
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Fri Dec 19 20:00:06 2003
Return-path: <pwe3-admin@ietf.org>
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>,
        "'Busschbach, Peter B (Peter)'" <busschbach@lucent.com>,
        neil.2.harrison@bt.com, Maarten.Vissers@alcatel.de, stbryant@cisco.com
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Hi Tom:

<snipped>
> 
> 	OTOH, you may wish to periodically verify 
> imposition/disposition, which simply checking the transport 
> trunks doesn't achieve.

Right, but I think we are all discussing the same thing which is how one
instance can proxy for many, and the "many" only needs a much lower level of
verification actitity to achieve near the same degree of robustness. 
 
<more snipping>

> > Plus a reasonable assumption is that the management systems are not
> > integrated between ATM (for example) and MPLS and the 
> networks MAY be
> > different operators. Disjoint systems do not correlate faults.
> 
> 	In some cases they do not, but in others they do. Be 
> careful about generalizing. I know providers that have 
> systems in both areas you describe. There are certainly 
> systems that can handle lots 
> of notifications/alarms because of the deployment architecture. 
> It is of course, preferred to have fewer alarms, but I have been 
> told by some that more are better as long as there are no duplicates
> (i.e.: ifDown.1 + ifDown.1).

If we were to look at the most demanding case, it would be different
providers in which case if I were the MPLS provider, I'd want to know about
problems before my ATM customers did, and ideally that my ATM customers knew
I knew (e.g. via AIS) if they also were detecting the problem. If I were to
look at the least demanding case, I would not care which system detected it,
as we are assuming some piece of automation sorted it all out no matter how
it manifested itself. 

IMHO the first scenario would seem to embody the fewest "acts of faith" and
is the best design practice as alarm minimization right off the bat spends
the fewest cycles on both the data plane boxes and the support systems... no
matter who owns them.

cheers
Dave


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in PWE3]
Date: Fri, 19 Dec 2003 14:59:40 -0500
Organization: Cisco Systems, inc.
Lines: 76
Sender: pwe3-admin@ietf.org
References: <E1AXM85-0007ia-00@celiborn.ip-engineering.bt.com>
Reply-To: <tnadeau@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Fri Dec 19 21:01:16 2003
Return-path: <pwe3-admin@ietf.org>
To: <pwe3@ietf.org>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <E1AXM85-0007ia-00@celiborn.ip-engineering.bt.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



> -----Original Message-----
> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On 
> Behalf Of Peter Willis
> Sent: Friday, December 19, 2003 10:01 AM
> To: Busschbach, Peter B (Peter)
> Cc: 'neil.2.harrison@bt.com'; Maarten.Vissers@alcatel.de; 
> stbryant@cisco.com; pwe3@ietf.org
> Subject: Re: [PWE3] PW functional model and its OAM [was: FCS 
> retention in PWE3] 
> 
> 
> Colleagues,
> 
> First a comment on carrier strategy & requirements then 
> comments on VCCV & 
> RSVP-TE detail.
> 
> In terms of Fault & Performance Management versus efficient 
> packet forwarding 
> the message from BT is very clear. Customer experience is the 
> most important 
> thing to us. The customer must never see a fault.  Five 9's 
> reliability & sub 50
> msec fast reroute is insignificant if it takes us N hours to 
> locate a fault.
> We also aim to reduce Operational costs & we can buy a lot of 
> extra-gates in
> ASICs for the recurring costs of experts to locate faults. 
> Carriers won't do
> PWE3 or core network convergence to only save capex (that's 
> not where the major
> costs lie) but they do it to reduce opex as well. The 
> inability to fault manage 
> efficiently increase opex costs and negates the reason to do 
> PWE3 or network
> convergence. Seems to me the carrier version of PWE3 starts 
> with "how do
> we reduce operational expediture?".
> 
> Does VCCV detect swapped or merged LSPs e.g. at the egress 2 
> LSPs have each 
> others' labels or 2 LSPs have merged into 1 label by a fault 
> condition? What's 
> the risk of an LSP being sent to the wrong egress and the 
> discriminators still being valid?

	No, not in itself. To reiterate Mr. Busschbach's original
point, the IETF is working on a set of tools that can
be used together to solve a variety of problems in order
to not reinvent the wheel for each application. There are
other tools used to detect mismerging that can be used
in concert with VCCV, ICMP IP ping, VRF-aware ping, etc... 
to form a complete solution.

> If we are running graceful restart RSVP to protect our 
> forwarding against 
> control plane outages then don't we need to run a data plane 
> liveness test (like BFD) to check the forwarding plane is still 
> available whilst the control-plane is restarting? 

	I agree that some folks may find this a desirable thing 
to do.

	--Tom


> PeterW.
> 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "David Allan" <dallan@nortelnetworks.com>
Subject: VCCV, RA and PID
Date: Mon, 22 Dec 2003 11:46:33 -0500
Lines: 9
Sender: pwe3-admin@ietf.org
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Dec 22 17:49:08 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Thomas D. Nadeau'" <tnadeau@cisco.com>
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Hi Tom:

One item not clear in the draft is if you are using Router Alert to indicate
a control channel, it indicates the presence of a PW PID. Would be worth
clarifying in the next version. (esp. considering you need to support the
PID under all curcumstances).

cheers
Dave


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Sasha Vainshtein <Sasha@AXERRA.com>
Subject: RE: draft-ietf-pwe3-fragmentation-04.txt - Start of Last C
	all
Date: Tue, 23 Dec 2003 09:44:44 +0200
Lines: 54
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-8"
Cc: "'stbryant@cisco.com'" <stbryant@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 23 09:03:08 2003
Return-path: <pwe3-admin@ietf.org>
To: "Mark Townsley (E-mail)" <townsley@cisco.com>,
        "Andrew G. Malis (E-mail)" <Andy.Malis@tellabs.com>
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Andy, Mark and all,
I have a brief comment on Into section of the fragmentation draft.

IMO, structure-aware TDM emulation provides an additional
use case for fragmentation - namely, when the structures
to be preserved take too much time to packetize.

This case differs from the Path MTU considerations discussed
in the Intro section of the draft for low-speed TDM circuits:
e.g., the size of the T1/ESF multiframe structure used in structure-
aware emulation of NxDS0 circuits with CAS is 24*N + (N+1)/2 and
hence does not exceeed 588 bytes (for N=24), while the 3 ms delay
required to packetize this structure (for any N) may be too much
for some applications.

The fragmentation mechanism defined in 
draft-ietf-pwe3-fragmentation-04.txt is fully applicable 
for this case as shown in draft-vainshtein-cesopsn-07.txt.

Hopefully this note will be useful.

With best regards,
                                   Sasha Vainshtein
email:     sasha@axerra.com <mailto:sasha@axerra.com> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)
 


> -----Original Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com]
> Sent: Thursday, December 18, 2003 6:01 PM
> To: pwe3@ietf.org
> Subject: [PWE3] draft-ietf-pwe3-fragmentation-04.txt - Start 
> of Last Call
> 
> 
> Please consider this the start of last call for
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentat
> ion-04.txt
> 
> Because of the long Christmas break here in Europe
> we will leave the LC open until 14th January 2004.
> 
> - Stewart
> 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Peter Willis <pjw@ip-engineering.bt.com>
Subject: Re: PW functional model and its OAM [was: FCS retention in PWE3]
Date: Tue, 23 Dec 2003 10:58:22 +0000
Lines: 17
Sender: pwe3-admin@ietf.org
References: <012f01c3c66a$a80b9430$6701a8c0@amer.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 23 12:04:07 2003
Return-path: <pwe3-admin@ietf.org>
X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI]
To: tnadeau@cisco.com
In-reply-to: Your message of "Fri, 19 Dec 2003 14:59:40 EST."
             <012f01c3c66a$a80b9430$6701a8c0@amer.cisco.com> 
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


> There are
> other tools used to detect mismerging that can be used
> in concert with VCCV, ICMP IP ping, VRF-aware ping, etc... 
> to form a complete solution.

Concerned about the remoteness and speed of detection of mismerging with 
these tools. That is if we have a mismerge fault in the core that fault won't 
be detected until much later and at a location where nothing can be done to 
fix the fault. Where as if the mismerge was detected in the core we could fast 
reroute (or whatever) around the fault.

I get even more nervous when graceful restart mechanisms are used because then 
one is assuming that whilst the control plane was crashing it didn't wreck the 
forwarding tables e.g. create a mismerge.

Peter.


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Andew G. Malis" <Andy.Malis@tellabs.com>
Subject: RE: draft-ietf-pwe3-fragmentation-04.txt - Start of
  Last C all
Date: Tue, 23 Dec 2003 13:05:34 -0500
Lines: 64
Sender: pwe3-admin@ietf.org
References: <AF5018AC03D1D411ABB70002A5091326D319F1@TLV1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: "Mark Townsley (E-mail)" <townsley@cisco.com>,
        "Andrew G. Malis (E-mail)" <Andy.Malis@tellabs.com>,
        "'stbryant@cisco.com'" <stbryant@cisco.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 23 19:11:13 2003
Return-path: <pwe3-admin@ietf.org>
X-Sender: (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1
To: Sasha Vainshtein <Sasha@axerra.com>
In-Reply-To: <AF5018AC03D1D411ABB70002A5091326D319F1@TLV1>
References: <AF5018AC03D1D411ABB70002A5091326D319F1@TLV1>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Sasha,

Thanks for your comment.  We can add this note to the intro as well.

Cheers,
Andy

----------

At 12/23/2003 09:44 AM +0200, Sasha Vainshtein wrote:
>Andy, Mark and all,
>I have a brief comment on Into section of the fragmentation draft.
>
>IMO, structure-aware TDM emulation provides an additional
>use case for fragmentation - namely, when the structures
>to be preserved take too much time to packetize.
>
>This case differs from the Path MTU considerations discussed
>in the Intro section of the draft for low-speed TDM circuits:
>e.g., the size of the T1/ESF multiframe structure used in structure-
>aware emulation of NxDS0 circuits with CAS is 24*N + (N+1)/2 and
>hence does not exceeed 588 bytes (for N=24), while the 3 ms delay
>required to packetize this structure (for any N) may be too much
>for some applications.
>
>The fragmentation mechanism defined in
>draft-ietf-pwe3-fragmentation-04.txt is fully applicable
>for this case as shown in draft-vainshtein-cesopsn-07.txt.
>
>Hopefully this note will be useful.
>
>With best regards,
>                                    Sasha Vainshtein
>email:     sasha@axerra.com <mailto:sasha@axerra.com>
>tel:       +972-3-7659993 (office)
>            +972-8-9254948 (res.)
>            +972-58-674833 (cell.)
>
>
>
> > -----Original Message-----
> > From: Stewart Bryant [mailto:stbryant@cisco.com]
> > Sent: Thursday, December 18, 2003 6:01 PM
> > To: pwe3@ietf.org
> > Subject: [PWE3] draft-ietf-pwe3-fragmentation-04.txt - Start
> > of Last Call
> >
> >
> > Please consider this the start of last call for
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentat
> > ion-04.txt
> >
> > Because of the long Christmas break here in Europe
> > we will leave the LC open until 14th January 2004.
> >
> > - Stewart
> >
> >
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Luca Martini <lmartini@cisco.com>
Subject: Re: PW Status negotiation procedure
Date: Tue, 23 Dec 2003 12:27:33 -0700
Organization: Cisco Systems
Lines: 82
Sender: pwe3-admin@ietf.org
References: <Pine.LNX.4.44.0312230431310.25595-100000@redcs6.procket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tob@laurelnetworks.com, Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li <renwei@procket.com>, Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 23 20:34:04 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
To: Rex Emmanuel Fernando <rex@procket.com>
In-Reply-To: <Pine.LNX.4.44.0312230431310.25595-100000@redcs6.procket.com>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



Rex Emmanuel Fernando wrote:

>Hi, Guys,
>
> It seems
>to me that the text which describes PW Status negotiation is flawed.
>
>This is what it says:
>
>---
>
>   "A PE that supports the PW Status TLV MUST include it in the initial
>   label mapping signaling as part of the PW FEC and following the
>   interface parameters field. The PW Status TLV will be used for the
>   lifetime of the Pseudowire for PEs that support this TLV.
>
>   If the PW Status TLV is not present in the initial PW FEC Message
>   received by a PE, then the PW Status TLV will not be used and both
>   PEs of the pseudowire will revert to the label withdraw procedure for
>   signaling status changes.
>
>   If PW status TLV is sent as part of the initial PW FEC Message, but
>   the remote PE corresponding FEC advertisement does not include a PW
>   status TLV, or the remote PE does not support the PW Status TLV then
>   the PW will revert to the label withdraw method to signal PW status.
>   Note that if the PW Status TLV is not supported it will automatically
>   be ignored since the LDP ignore bit is set."
>
>----
>
>The text says that the "PW Status TLV" should be part of the FEC TLV
>and following the interface parameters. Note that according to LDP spec
>a FEC TLV does not have sub-tlvs and I don't see a provision for
>having sub-tlvs within it. All it has is a contiguous array of different
>FEC types. So I am assuming that the PW Status TLV is *NOT* part of
>the FEC TLV but an additional TLV following the FEC TLV. Also note that
>the text says that old implementations which do not suppor this would
>ignore it - this is possible only if its a separate TLV and is not
>piggybacked on the FEC TLV. The text has to be corrected to relfect this. 
>
>  
>
Yes , I can see there is a problem in the description. And yes the 
status TLV is a separate TLV and MUST immediately follow the FEC TLV.

>The next question I have is, if the PW Status TLV follows the FEC TLV, to
>which FEC does it apply (note that a FEC TLV could have 'n' number of
>FECs). Does the PW status apply to all FECs ?
>  
>
not for the PW case. In IP you can have multiple FEC elements in the FEC 
( sharing of LSP for multiple IP addresses ), but for the PW it's only 
one FEC element per FEC so the status TLV will be only for the FEC 
element present.

>Correct me if I am wrong in any of these points.
>  
>
you are right on most of them :-)

>Also is there an IANA assigned number for the PW Status TLV type ?
>  
>
No. Not yet.

I'll send out a correction for the text above . it really meant to say 
"the PW Status TLV should immediately follow the FEC TLV" as in the 
picture...

Luca


>Thanks for your clarification.
>
>- Rex
>
>
>
>  
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Shah, Himanshu" <hshah@ciena.com>
Subject: RE: Re: PW Status negotiation procedure
Date: Tue, 23 Dec 2003 14:54:29 -0500
Lines: 125
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Cc: tob@laurelnetworks.com, Srihari Ramachandra Sangli
	 <srihari@procket.com>,
        Renwei Li <renwei@procket.com>,
        Avneesh Sachdev
	 <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 23 20:58:02 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Luca Martini'" <lmartini@cisco.com>,
        Rex Emmanuel Fernando
	 <rex@procket.com>
X-Mailer: Internet Mail Service (5.5.2657.72)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

In draft-shah-pwe3-control-protocol-extension-01.txt, 
we have recommended that this status TLV (or for that
matter any additional TLV) should be part of the
"optional parameter" field of the Label Mapping message.


/himanshu


http://www.ietf.org/internet-drafts/draft-shah-pwe3-control-protocol-extension-01.txt


> -----Original Message-----
> From: Luca Martini [mailto:lmartini@cisco.com]
> Sent: Tuesday, December 23, 2003 2:28 PM
> To: Rex Emmanuel Fernando
> Cc: tob@laurelnetworks.com; Srihari Ramachandra Sangli; Renwei Li;
> Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> Subject: [PWE3] Re: PW Status negotiation procedure
> 
> 
> 
> 
> Rex Emmanuel Fernando wrote:
> 
> >Hi, Guys,
> >
> > It seems
> >to me that the text which describes PW Status negotiation is flawed.
> >
> >This is what it says:
> >
> >---
> >
> >   "A PE that supports the PW Status TLV MUST include it in 
> the initial
> >   label mapping signaling as part of the PW FEC and following the
> >   interface parameters field. The PW Status TLV will be used for the
> >   lifetime of the Pseudowire for PEs that support this TLV.
> >
> >   If the PW Status TLV is not present in the initial PW FEC Message
> >   received by a PE, then the PW Status TLV will not be used and both
> >   PEs of the pseudowire will revert to the label withdraw 
> procedure for
> >   signaling status changes.
> >
> >   If PW status TLV is sent as part of the initial PW FEC 
> Message, but
> >   the remote PE corresponding FEC advertisement does not 
> include a PW
> >   status TLV, or the remote PE does not support the PW 
> Status TLV then
> >   the PW will revert to the label withdraw method to signal 
> PW status.
> >   Note that if the PW Status TLV is not supported it will 
> automatically
> >   be ignored since the LDP ignore bit is set."
> >
> >----
> >
> >The text says that the "PW Status TLV" should be part of the FEC TLV
> >and following the interface parameters. Note that according 
> to LDP spec
> >a FEC TLV does not have sub-tlvs and I don't see a provision for
> >having sub-tlvs within it. All it has is a contiguous array 
> of different
> >FEC types. So I am assuming that the PW Status TLV is *NOT* part of
> >the FEC TLV but an additional TLV following the FEC TLV. 
> Also note that
> >the text says that old implementations which do not suppor this would
> >ignore it - this is possible only if its a separate TLV and is not
> >piggybacked on the FEC TLV. The text has to be corrected to 
> relfect this. 
> >
> >  
> >
> Yes , I can see there is a problem in the description. And yes the 
> status TLV is a separate TLV and MUST immediately follow the FEC TLV.
> 
> >The next question I have is, if the PW Status TLV follows 
> the FEC TLV, to
> >which FEC does it apply (note that a FEC TLV could have 'n' number of
> >FECs). Does the PW status apply to all FECs ?
> >  
> >
> not for the PW case. In IP you can have multiple FEC elements 
> in the FEC 
> ( sharing of LSP for multiple IP addresses ), but for the PW 
> it's only 
> one FEC element per FEC so the status TLV will be only for the FEC 
> element present.
> 
> >Correct me if I am wrong in any of these points.
> >  
> >
> you are right on most of them :-)
> 
> >Also is there an IANA assigned number for the PW Status TLV type ?
> >  
> >
> No. Not yet.
> 
> I'll send out a correction for the text above . it really 
> meant to say 
> "the PW Status TLV should immediately follow the FEC TLV" as in the 
> picture...
> 
> Luca
> 
> 
> >Thanks for your clarification.
> >
> >- Rex
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Luca Martini <lmartini@cisco.com>
Subject: PW Status negotiation procedure text issue
Date: Tue, 23 Dec 2003 13:10:07 -0700
Organization: Cisco Systems
Lines: 58
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Tue Dec 23 21:14:04 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
To: pwe3@ietf.org
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Hello!

It has been pointed out that the following text in section "5.3.3. 
Pseudowire Status Negotiation Procedures" has a flaw in it :

---

   "A PE that supports the PW Status TLV MUST include it in the initial
   label mapping signaling as part of the PW FEC and following the
   interface parameters field. The PW Status TLV will be used for the
   lifetime of the Pseudowire for PEs that support this TLV.

   If the PW Status TLV is not present in the initial PW FEC Message
   received by a PE, then the PW Status TLV will not be used and both
   PEs of the pseudowire will revert to the label withdraw procedure for
   signaling status changes.

   If PW status TLV is sent as part of the initial PW FEC Message, but
   the remote PE corresponding FEC advertisement does not include a PW
   status TLV, or the remote PE does not support the PW Status TLV then
   the PW will revert to the label withdraw method to signal PW status.
   Note that if the PW Status TLV is not supported it will automatically
   be ignored since the LDP ignore bit is set."

----

According to the picture following the text the  PW Status TLV MUST 
immediately follow the PE FEC,  and is not actually part of the PW FEC

I will change the text to be :

---

   "A PE that supports the PW Status TLV MUST include it in the initial
   label mapping signaling immediately following the PW FEC and the
   interface parameters field. The PW Status TLV will be used for the
   lifetime of the Pseudowire for PEs that support this TLV.

   If the PW Status TLV is not present immediately following the initial PW FEC Message
   received by a PE, then the PW Status TLV will not be used and both
   PEs supporting the pseudowire will revert to the label withdraw procedure for
   signaling status changes.

   If PW status TLV is sent immediately following the initial PW FEC Message, but
   the remote PE corresponding FEC advertisement does not include a PW
   status TLV, or the remote PE does not support the PW Status TLV, then
   the PW will revert to the label withdraw method to signal PW status.
   Note that if the PW Status TLV is not supported it will automatically
   be ignored since the LDP ignore bit is set."

----

Since the picture is correct , I consider this just correcting the 
english text , and not worth sending out an update now.
( I also corrected about 3 or 4 spelling errors elsewhere in this document )

Thanks.
Luca


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pwe3-enet-mib-03.txt
Date: Tue, 23 Dec 2003 15:35:06 -0500
Lines: 81
Sender: pwe3-admin@ietf.org
Reply-To: Internet-Drafts@ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 23 21:36:07 2003
Return-path: <pwe3-admin@ietf.org>
To: IETF-Announce: ;
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

	Title		: Ethernet Pseudo Wire (PW) Management Information Base
	Author(s)	: D. Zelig, T. Nadeau
	Filename	: draft-ietf-pwe3-enet-mib-03.txt
	Pages		: 21
	Date		: 2003-12-23
	
This memo defines an experimental portion of the Management 
Information Base (MIB) for use with network management protocols in 
the Internet community.  In particular, it describes managed objects 
for modeling of Ethernet Pseudo Wire (PW) services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-enet-mib-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-enet-mib-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-enet-mib-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pwe3-tdm-requirements-03.txt
Date: Tue, 23 Dec 2003 15:35:19 -0500
Lines: 86
Sender: pwe3-admin@ietf.org
Reply-To: Internet-Drafts@ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 23 21:36:07 2003
Return-path: <pwe3-admin@ietf.org>
To: IETF-Announce: ;
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

	Title		: Requirements for Edge-to-Edge Emulation of TDM 
			  Circuits over Packet Switching Networks (PSN)
	Author(s)	: M. Riegel
	Filename	: draft-ietf-pwe3-tdm-requirements-03.txt
	Pages		: 26
	Date		: 2003-12-23
	
This document specifies the particular requirements for
edge-to-edge-emulation of circuits carrying time division multiplexed
digital signals of the PDH as well as the SONET/SDH hierarchy over
packet-switched networks. It is based on the common architecture for
Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [PWE3-ARCH].
It makes references to requirements in [PWE3-REQ] where applicable
and complements [PWE3-REQ] by defining requirements originating from
specifics of TDM circuits.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-requirements-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-tdm-requirements-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-tdm-requirements-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pwe3-cep-mib-04.txt
Date: Tue, 23 Dec 2003 15:35:24 -0500
Lines: 83
Sender: pwe3-admin@ietf.org
Reply-To: Internet-Drafts@ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 23 21:36:14 2003
Return-path: <pwe3-admin@ietf.org>
To: IETF-Announce: ;
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

	Title		: SONET/SDH Circuit Emulation Service Over Packet (CEP)
			  Management Information Base Using SMIv2
	Author(s)	: D. Zelig, A. Malis
	Filename	: draft-ietf-pwe3-cep-mib-04.txt
	Pages		: 57
	Date		: 2003-12-23
	
This memo defines an experimental portion of the Management 
Information Base (MIB) for use with network management protocols in 
the Internet community.  In particular, it describes managed objects 
for modeling Native Service Processing of SONET/SDH circuits over a 
Packet Switch Network (PSN).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cep-mib-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-cep-mib-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-cep-mib-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pwe3-pw-mpls-mib-04.txt
Date: Tue, 23 Dec 2003 15:35:11 -0500
Lines: 82
Sender: pwe3-admin@ietf.org
Reply-To: Internet-Drafts@ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 23 21:36:24 2003
Return-path: <pwe3-admin@ietf.org>
To: IETF-Announce: ;
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

	Title		: Pseudo Wire (PW) over MPLS PSN Management Information Base
	Author(s)	: D. Zelig, T. Nadeau, D. Danenberg
	Filename	: draft-ietf-pwe3-pw-mpls-mib-04.txt
	Pages		: 25
	Date		: 2003-12-23
	
This memo defines an experimental portion of the Management 
Information Base (MIB) for use with network management protocols in 
the Internet community.  In particular, it describes MIB module for 
PW operation over Multi-Protocol Label Switching (MPLS) Label 
Switch Router (LSR).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mpls-mib-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-pw-mpls-mib-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-pw-mpls-mib-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Luca Martini <lmartini@cisco.com>
Subject: Re: Re: PW Status negotiation procedure
Date: Tue, 23 Dec 2003 14:34:17 -0700
Organization: Cisco Systems
Lines: 217
Sender: pwe3-admin@ietf.org
References: <8162DD929D7AD24CAD3FC5317CE41FB06D459A@w2kmaexg02.wavesmithnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Rex Emmanuel Fernando <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li <renwei@procket.com>, Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 23 22:38:09 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
To: "Shah, Himanshu" <hshah@ciena.com>
In-Reply-To: <8162DD929D7AD24CAD3FC5317CE41FB06D459A@w2kmaexg02.wavesmithnet.com>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Himanshu,

When we dicussed this months ago , I had pointed out that putting this 
in the optional parameter field , means that the FEC changes every time 
there is a status change. This would mean a withdraw a, and 
re-advertisement of the PW FEC.
It is too late to change anything now, But I was under the impression 
that the draft below would be amended to include only the IP TLV , and 
other VPLS related informantion.

Luca


Shah, Himanshu wrote:

>In draft-shah-pwe3-control-protocol-extension-01.txt, 
>we have recommended that this status TLV (or for that
>matter any additional TLV) should be part of the
>"optional parameter" field of the Label Mapping message.
>
>
>/himanshu
>
>
>http://www.ietf.org/internet-drafts/draft-shah-pwe3-control-protocol-extension-01.txt
>
>
>  
>
>>-----Original Message-----
>>From: Luca Martini [mailto:lmartini@cisco.com]
>>Sent: Tuesday, December 23, 2003 2:28 PM
>>To: Rex Emmanuel Fernando
>>Cc: tob@laurelnetworks.com; Srihari Ramachandra Sangli; Renwei Li;
>>Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
>>Subject: [PWE3] Re: PW Status negotiation procedure
>>
>>
>>
>>
>>Rex Emmanuel Fernando wrote:
>>
>>    
>>
>>>Hi, Guys,
>>>
>>>It seems
>>>to me that the text which describes PW Status negotiation is flawed.
>>>
>>>This is what it says:
>>>
>>>---
>>>
>>>  "A PE that supports the PW Status TLV MUST include it in 
>>>      
>>>
>>the initial
>>    
>>
>>>  label mapping signaling as part of the PW FEC and following the
>>>  interface parameters field. The PW Status TLV will be used for the
>>>  lifetime of the Pseudowire for PEs that support this TLV.
>>>
>>>  If the PW Status TLV is not present in the initial PW FEC Message
>>>  received by a PE, then the PW Status TLV will not be used and both
>>>  PEs of the pseudowire will revert to the label withdraw 
>>>      
>>>
>>procedure for
>>    
>>
>>>  signaling status changes.
>>>
>>>  If PW status TLV is sent as part of the initial PW FEC 
>>>      
>>>
>>Message, but
>>    
>>
>>>  the remote PE corresponding FEC advertisement does not 
>>>      
>>>
>>include a PW
>>    
>>
>>>  status TLV, or the remote PE does not support the PW 
>>>      
>>>
>>Status TLV then
>>    
>>
>>>  the PW will revert to the label withdraw method to signal 
>>>      
>>>
>>PW status.
>>    
>>
>>>  Note that if the PW Status TLV is not supported it will 
>>>      
>>>
>>automatically
>>    
>>
>>>  be ignored since the LDP ignore bit is set."
>>>
>>>----
>>>
>>>The text says that the "PW Status TLV" should be part of the FEC TLV
>>>and following the interface parameters. Note that according 
>>>      
>>>
>>to LDP spec
>>    
>>
>>>a FEC TLV does not have sub-tlvs and I don't see a provision for
>>>having sub-tlvs within it. All it has is a contiguous array 
>>>      
>>>
>>of different
>>    
>>
>>>FEC types. So I am assuming that the PW Status TLV is *NOT* part of
>>>the FEC TLV but an additional TLV following the FEC TLV. 
>>>      
>>>
>>Also note that
>>    
>>
>>>the text says that old implementations which do not suppor this would
>>>ignore it - this is possible only if its a separate TLV and is not
>>>piggybacked on the FEC TLV. The text has to be corrected to 
>>>      
>>>
>>relfect this. 
>>    
>>
>>> 
>>>
>>>      
>>>
>>Yes , I can see there is a problem in the description. And yes the 
>>status TLV is a separate TLV and MUST immediately follow the FEC TLV.
>>
>>    
>>
>>>The next question I have is, if the PW Status TLV follows 
>>>      
>>>
>>the FEC TLV, to
>>    
>>
>>>which FEC does it apply (note that a FEC TLV could have 'n' number of
>>>FECs). Does the PW status apply to all FECs ?
>>> 
>>>
>>>      
>>>
>>not for the PW case. In IP you can have multiple FEC elements 
>>in the FEC 
>>( sharing of LSP for multiple IP addresses ), but for the PW 
>>it's only 
>>one FEC element per FEC so the status TLV will be only for the FEC 
>>element present.
>>
>>    
>>
>>>Correct me if I am wrong in any of these points.
>>> 
>>>
>>>      
>>>
>>you are right on most of them :-)
>>
>>    
>>
>>>Also is there an IANA assigned number for the PW Status TLV type ?
>>> 
>>>
>>>      
>>>
>>No. Not yet.
>>
>>I'll send out a correction for the text above . it really 
>>meant to say 
>>"the PW Status TLV should immediately follow the FEC TLV" as in the 
>>picture...
>>
>>Luca
>>
>>
>>    
>>
>>>Thanks for your clarification.
>>>
>>>- Rex
>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>pwe3 mailing list
>>pwe3@ietf.org
>>https://www1.ietf.org/mailman/listinfo/pwe3
>>
>>    
>>
>
>_______________________________________________
>pwe3 mailing list
>pwe3@ietf.org
>https://www1.ietf.org/mailman/listinfo/pwe3
>
>  
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Shah, Himanshu" <hshah@ciena.com>
Subject: RE: Re: PW Status negotiation procedure
Date: Tue, 23 Dec 2003 17:01:08 -0500
Lines: 255
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Cc: Rex Emmanuel Fernando <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li
	 <renwei@procket.com>,
        Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 23 23:08:07 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Luca Martini'" <lmartini@cisco.com>
X-Mailer: Internet Mail Service (5.5.2657.72)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

The Status TLV is sent in label mapping message 
in "optional parameter" field as a  "capability learning" mechanism.

The changes in PW status (or others) is subsequently sent as 
LDP notification messages as per rev1 draft (we did listen to you :-).

I still believe that dispatching initial status tlv in optional
parameter field is a better choice than appending to the PW FEC.
Its a suggestion that you may want to consider....

Yes, we are going to update the draft to remove status related
stuff (as you have covered it in your draft) and keep IP TLV
and other stuff. So your impression is correct.

/himanshu

> -----Original Message-----
> From: Luca Martini [mailto:lmartini@cisco.com]
> Sent: Tuesday, December 23, 2003 4:34 PM
> To: Shah, Himanshu
> Cc: Rex Emmanuel Fernando; tob@laurelnetworks.com; Srihari Ramachandra
> Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> Subject: Re: [PWE3] Re: PW Status negotiation procedure
> 
> 
> Himanshu,
> 
> When we dicussed this months ago , I had pointed out that 
> putting this 
> in the optional parameter field , means that the FEC changes 
> every time 
> there is a status change. This would mean a withdraw a, and 
> re-advertisement of the PW FEC.
> It is too late to change anything now, But I was under the impression 
> that the draft below would be amended to include only the IP 
> TLV , and 
> other VPLS related informantion.
> 
> Luca
> 
> 
> Shah, Himanshu wrote:
> 
> >In draft-shah-pwe3-control-protocol-extension-01.txt, 
> >we have recommended that this status TLV (or for that
> >matter any additional TLV) should be part of the
> >"optional parameter" field of the Label Mapping message.
> >
> >
> >/himanshu
> >
> >
> >http://www.ietf.org/internet-drafts/draft-shah-pwe3-control-p
rotocol-extension-01.txt
> >
> >
> >  
> >
> >>-----Original Message-----
> >>From: Luca Martini [mailto:lmartini@cisco.com]
> >>Sent: Tuesday, December 23, 2003 2:28 PM
> >>To: Rex Emmanuel Fernando
> >>Cc: tob@laurelnetworks.com; Srihari Ramachandra Sangli; Renwei Li;
> >>Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> >>Subject: [PWE3] Re: PW Status negotiation procedure
> >>
> >>
> >>
> >>
> >>Rex Emmanuel Fernando wrote:
> >>
> >>    
> >>
> >>>Hi, Guys,
> >>>
> >>>It seems
> >>>to me that the text which describes PW Status negotiation 
> is flawed.
> >>>
> >>>This is what it says:
> >>>
> >>>---
> >>>
> >>>  "A PE that supports the PW Status TLV MUST include it in 
> >>>      
> >>>
> >>the initial
> >>    
> >>
> >>>  label mapping signaling as part of the PW FEC and following the
> >>>  interface parameters field. The PW Status TLV will be 
> used for the
> >>>  lifetime of the Pseudowire for PEs that support this TLV.
> >>>
> >>>  If the PW Status TLV is not present in the initial PW FEC Message
> >>>  received by a PE, then the PW Status TLV will not be 
> used and both
> >>>  PEs of the pseudowire will revert to the label withdraw 
> >>>      
> >>>
> >>procedure for
> >>    
> >>
> >>>  signaling status changes.
> >>>
> >>>  If PW status TLV is sent as part of the initial PW FEC 
> >>>      
> >>>
> >>Message, but
> >>    
> >>
> >>>  the remote PE corresponding FEC advertisement does not 
> >>>      
> >>>
> >>include a PW
> >>    
> >>
> >>>  status TLV, or the remote PE does not support the PW 
> >>>      
> >>>
> >>Status TLV then
> >>    
> >>
> >>>  the PW will revert to the label withdraw method to signal 
> >>>      
> >>>
> >>PW status.
> >>    
> >>
> >>>  Note that if the PW Status TLV is not supported it will 
> >>>      
> >>>
> >>automatically
> >>    
> >>
> >>>  be ignored since the LDP ignore bit is set."
> >>>
> >>>----
> >>>
> >>>The text says that the "PW Status TLV" should be part of 
> the FEC TLV
> >>>and following the interface parameters. Note that according 
> >>>      
> >>>
> >>to LDP spec
> >>    
> >>
> >>>a FEC TLV does not have sub-tlvs and I don't see a provision for
> >>>having sub-tlvs within it. All it has is a contiguous array 
> >>>      
> >>>
> >>of different
> >>    
> >>
> >>>FEC types. So I am assuming that the PW Status TLV is *NOT* part of
> >>>the FEC TLV but an additional TLV following the FEC TLV. 
> >>>      
> >>>
> >>Also note that
> >>    
> >>
> >>>the text says that old implementations which do not suppor 
> this would
> >>>ignore it - this is possible only if its a separate TLV and is not
> >>>piggybacked on the FEC TLV. The text has to be corrected to 
> >>>      
> >>>
> >>relfect this. 
> >>    
> >>
> >>> 
> >>>
> >>>      
> >>>
> >>Yes , I can see there is a problem in the description. And yes the 
> >>status TLV is a separate TLV and MUST immediately follow 
> the FEC TLV.
> >>
> >>    
> >>
> >>>The next question I have is, if the PW Status TLV follows 
> >>>      
> >>>
> >>the FEC TLV, to
> >>    
> >>
> >>>which FEC does it apply (note that a FEC TLV could have 
> 'n' number of
> >>>FECs). Does the PW status apply to all FECs ?
> >>> 
> >>>
> >>>      
> >>>
> >>not for the PW case. In IP you can have multiple FEC elements 
> >>in the FEC 
> >>( sharing of LSP for multiple IP addresses ), but for the PW 
> >>it's only 
> >>one FEC element per FEC so the status TLV will be only for the FEC 
> >>element present.
> >>
> >>    
> >>
> >>>Correct me if I am wrong in any of these points.
> >>> 
> >>>
> >>>      
> >>>
> >>you are right on most of them :-)
> >>
> >>    
> >>
> >>>Also is there an IANA assigned number for the PW Status TLV type ?
> >>> 
> >>>
> >>>      
> >>>
> >>No. Not yet.
> >>
> >>I'll send out a correction for the text above . it really 
> >>meant to say 
> >>"the PW Status TLV should immediately follow the FEC TLV" as in the 
> >>picture...
> >>
> >>Luca
> >>
> >>
> >>    
> >>
> >>>Thanks for your clarification.
> >>>
> >>>- Rex
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>_______________________________________________
> >>pwe3 mailing list
> >>pwe3@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/pwe3
> >>
> >>    
> >>
> >
> >_______________________________________________
> >pwe3 mailing list
> >pwe3@ietf.org
> >https://www1.ietf.org/mailman/listinfo/pwe3
> >
> >  
> >
> 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Shah, Himanshu" <hshah@ciena.com>
Subject: RE: Re: PW Status negotiation procedure
Date: Wed, 24 Dec 2003 07:49:17 -0500
Lines: 308
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Cc: "'Luca Martini'" <lmartini@cisco.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li
	 <renwei@procket.com>,
        Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Dec 24 13:53:10 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Rex Emmanuel Fernando'" <rex@procket.com>
X-Mailer: Internet Mail Service (5.5.2657.72)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

The changes to PWE3-control draft has to be determined
by Luca and his co-authors. We can only make recommendations.....

/himanshu

> -----Original Message-----
> From: Rex Emmanuel Fernando [mailto:rex@procket.com]
> Sent: Wednesday, December 24, 2003 12:25 AM
> To: Shah, Himanshu
> Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
> Ramachandra Sangli;
> Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> Subject: RE: [PWE3] Re: PW Status negotiation procedure
> 
> 
> 
> Himanshu,
> 
> > The Status TLV is sent in label mapping message 
> > in "optional parameter" field as a  "capability learning" mechanism.
> > 
> > The changes in PW status (or others) is subsequently sent as 
> > LDP notification messages as per rev1 draft (we did listen 
> to you :-).
> > 
> > I still believe that dispatching initial status tlv in optional
> > parameter field is a better choice than appending to the PW FEC.
> > Its a suggestion that you may want to consider....
> 
> As Luca seems to concur below the PW Status TLV has to be a 
> separate TLV 
> following the FEC TLV in the label mapping message. Having 
> said that I 
> agree with you that the correct way to carry this information 
> would be in 
> the optional parameters field in the label mapping message. 
> Any subsequent 
> change to the status is conveyed using LDP notification so there is
> no FEC churn. 
> 
> If we all agree on this could the authors make necessary changes to
> the draft so that we (implementors) could make forward progress ?
> 
> Thanks,
> 
> - Rex
> 
> > 
> > Yes, we are going to update the draft to remove status related
> > stuff (as you have covered it in your draft) and keep IP TLV
> > and other stuff. So your impression is correct.
> > 
> > /himanshu
> > 
> > > -----Original Message-----
> > > From: Luca Martini [mailto:lmartini@cisco.com]
> > > Sent: Tuesday, December 23, 2003 4:34 PM
> > > To: Shah, Himanshu
> > > Cc: Rex Emmanuel Fernando; tob@laurelnetworks.com; 
> Srihari Ramachandra
> > > Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > > Subject: Re: [PWE3] Re: PW Status negotiation procedure
> > > 
> > > 
> > > Himanshu,
> > > 
> > > When we dicussed this months ago , I had pointed out that 
> > > putting this 
> > > in the optional parameter field , means that the FEC changes 
> > > every time 
> > > there is a status change. This would mean a withdraw a, and 
> > > re-advertisement of the PW FEC.
> > > It is too late to change anything now, But I was under 
> the impression 
> > > that the draft below would be amended to include only the IP 
> > > TLV , and 
> > > other VPLS related informantion.
> > > 
> > > Luca
> > > 
> > > 
> > > Shah, Himanshu wrote:
> > > 
> > > >In draft-shah-pwe3-control-protocol-extension-01.txt, 
> > > >we have recommended that this status TLV (or for that
> > > >matter any additional TLV) should be part of the
> > > >"optional parameter" field of the Label Mapping message.
> > > >
> > > >
> > > >/himanshu
> > > >
> > > >
> > > >http://www.ietf.org/internet-drafts/draft-shah-pwe3-control-p
> > rotocol-extension-01.txt
> > > >
> > > >
> > > >  
> > > >
> > > >>-----Original Message-----
> > > >>From: Luca Martini [mailto:lmartini@cisco.com]
> > > >>Sent: Tuesday, December 23, 2003 2:28 PM
> > > >>To: Rex Emmanuel Fernando
> > > >>Cc: tob@laurelnetworks.com; Srihari Ramachandra Sangli; 
> Renwei Li;
> > > >>Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > > >>Subject: [PWE3] Re: PW Status negotiation procedure
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>Rex Emmanuel Fernando wrote:
> > > >>
> > > >>    
> > > >>
> > > >>>Hi, Guys,
> > > >>>
> > > >>>It seems
> > > >>>to me that the text which describes PW Status negotiation 
> > > is flawed.
> > > >>>
> > > >>>This is what it says:
> > > >>>
> > > >>>---
> > > >>>
> > > >>>  "A PE that supports the PW Status TLV MUST include it in 
> > > >>>      
> > > >>>
> > > >>the initial
> > > >>    
> > > >>
> > > >>>  label mapping signaling as part of the PW FEC and 
> following the
> > > >>>  interface parameters field. The PW Status TLV will be 
> > > used for the
> > > >>>  lifetime of the Pseudowire for PEs that support this TLV.
> > > >>>
> > > >>>  If the PW Status TLV is not present in the initial 
> PW FEC Message
> > > >>>  received by a PE, then the PW Status TLV will not be 
> > > used and both
> > > >>>  PEs of the pseudowire will revert to the label withdraw 
> > > >>>      
> > > >>>
> > > >>procedure for
> > > >>    
> > > >>
> > > >>>  signaling status changes.
> > > >>>
> > > >>>  If PW status TLV is sent as part of the initial PW FEC 
> > > >>>      
> > > >>>
> > > >>Message, but
> > > >>    
> > > >>
> > > >>>  the remote PE corresponding FEC advertisement does not 
> > > >>>      
> > > >>>
> > > >>include a PW
> > > >>    
> > > >>
> > > >>>  status TLV, or the remote PE does not support the PW 
> > > >>>      
> > > >>>
> > > >>Status TLV then
> > > >>    
> > > >>
> > > >>>  the PW will revert to the label withdraw method to signal 
> > > >>>      
> > > >>>
> > > >>PW status.
> > > >>    
> > > >>
> > > >>>  Note that if the PW Status TLV is not supported it will 
> > > >>>      
> > > >>>
> > > >>automatically
> > > >>    
> > > >>
> > > >>>  be ignored since the LDP ignore bit is set."
> > > >>>
> > > >>>----
> > > >>>
> > > >>>The text says that the "PW Status TLV" should be part of 
> > > the FEC TLV
> > > >>>and following the interface parameters. Note that according 
> > > >>>      
> > > >>>
> > > >>to LDP spec
> > > >>    
> > > >>
> > > >>>a FEC TLV does not have sub-tlvs and I don't see a 
> provision for
> > > >>>having sub-tlvs within it. All it has is a contiguous array 
> > > >>>      
> > > >>>
> > > >>of different
> > > >>    
> > > >>
> > > >>>FEC types. So I am assuming that the PW Status TLV is 
> *NOT* part of
> > > >>>the FEC TLV but an additional TLV following the FEC TLV. 
> > > >>>      
> > > >>>
> > > >>Also note that
> > > >>    
> > > >>
> > > >>>the text says that old implementations which do not suppor 
> > > this would
> > > >>>ignore it - this is possible only if its a separate 
> TLV and is not
> > > >>>piggybacked on the FEC TLV. The text has to be corrected to 
> > > >>>      
> > > >>>
> > > >>relfect this. 
> > > >>    
> > > >>
> > > >>> 
> > > >>>
> > > >>>      
> > > >>>
> > > >>Yes , I can see there is a problem in the description. 
> And yes the 
> > > >>status TLV is a separate TLV and MUST immediately follow 
> > > the FEC TLV.
> > > >>
> > > >>    
> > > >>
> > > >>>The next question I have is, if the PW Status TLV follows 
> > > >>>      
> > > >>>
> > > >>the FEC TLV, to
> > > >>    
> > > >>
> > > >>>which FEC does it apply (note that a FEC TLV could have 
> > > 'n' number of
> > > >>>FECs). Does the PW status apply to all FECs ?
> > > >>> 
> > > >>>
> > > >>>      
> > > >>>
> > > >>not for the PW case. In IP you can have multiple FEC elements 
> > > >>in the FEC 
> > > >>( sharing of LSP for multiple IP addresses ), but for the PW 
> > > >>it's only 
> > > >>one FEC element per FEC so the status TLV will be only 
> for the FEC 
> > > >>element present.
> > > >>
> > > >>    
> > > >>
> > > >>>Correct me if I am wrong in any of these points.
> > > >>> 
> > > >>>
> > > >>>      
> > > >>>
> > > >>you are right on most of them :-)
> > > >>
> > > >>    
> > > >>
> > > >>>Also is there an IANA assigned number for the PW 
> Status TLV type ?
> > > >>> 
> > > >>>
> > > >>>      
> > > >>>
> > > >>No. Not yet.
> > > >>
> > > >>I'll send out a correction for the text above . it really 
> > > >>meant to say 
> > > >>"the PW Status TLV should immediately follow the FEC 
> TLV" as in the 
> > > >>picture...
> > > >>
> > > >>Luca
> > > >>
> > > >>
> > > >>    
> > > >>
> > > >>>Thanks for your clarification.
> > > >>>
> > > >>>- Rex
> > > >>>
> > > >>>
> > > >>>
> > > >>> 
> > > >>>
> > > >>>      
> > > >>>
> > > >>_______________________________________________
> > > >>pwe3 mailing list
> > > >>pwe3@ietf.org
> > > >>https://www1.ietf.org/mailman/listinfo/pwe3
> > > >>
> > > >>    
> > > >>
> > > >
> > > >_______________________________________________
> > > >pwe3 mailing list
> > > >pwe3@ietf.org
> > > >https://www1.ietf.org/mailman/listinfo/pwe3
> > > >
> > > >  
> > > >
> > > 
> > > 
> > 
> 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: Re: PW Status negotiation procedure
Date: Wed, 24 Dec 2003 17:59:19 -0500
Lines: 346
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Cc: "'Luca Martini'" <lmartini@cisco.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li
	 <renwei@procket.com>,
        Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Thu Dec 25 00:03:05 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Shah, Himanshu'" <hshah@ciena.com>,
        "'Rex Emmanuel Fernando'"
	 <rex@procket.com>
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

draft-ietf-pwe3-iana-allocation-02 defines the following PW status codes.

0x00000000 - Pseudo Wire forwarding ( clear all failures)
0x00000001 - Pseudo Wire Not Forwarding
0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault
0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault
0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault
0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault

Could anyone explain what exactly is meant by each of these codes?

Here are the reasons I am uncertain about the semantics:

- Should "customer-facing PW" be read as "attachment circuit"? If not, I don't know what it is meant. From the perspective of a PE, I would think that the PW is always PSN-facing.

- I assume that "PSN-facing transmit fault" is an indication from one PE (PE1) to its peer (PE2) that there is a failure on the PW in the direction from PE1 to PE2. However, if that failure does indeed exist, how is the status indication  supposed to reach PE2?

- What is meant by "Pseudo Wire Not Forwarding"? When is this error code used instead of "PSN-facing PW receive fault" and/or "PSN-facing PW transmit fault"?

Peter

> -----Original Message-----
> From: Shah, Himanshu [mailto:hshah@ciena.com]
> Sent: Wednesday, December 24, 2003 7:49 AM
> To: 'Rex Emmanuel Fernando'
> Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
> Ramachandra Sangli;
> Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> Subject: RE: [PWE3] Re: PW Status negotiation procedure
> 
> 
> The changes to PWE3-control draft has to be determined
> by Luca and his co-authors. We can only make recommendations.....
> 
> /himanshu
> 
> > -----Original Message-----
> > From: Rex Emmanuel Fernando [mailto:rex@procket.com]
> > Sent: Wednesday, December 24, 2003 12:25 AM
> > To: Shah, Himanshu
> > Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
> > Ramachandra Sangli;
> > Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > Subject: RE: [PWE3] Re: PW Status negotiation procedure
> > 
> > 
> > 
> > Himanshu,
> > 
> > > The Status TLV is sent in label mapping message 
> > > in "optional parameter" field as a  "capability learning" 
> mechanism.
> > > 
> > > The changes in PW status (or others) is subsequently sent as 
> > > LDP notification messages as per rev1 draft (we did listen 
> > to you :-).
> > > 
> > > I still believe that dispatching initial status tlv in optional
> > > parameter field is a better choice than appending to the PW FEC.
> > > Its a suggestion that you may want to consider....
> > 
> > As Luca seems to concur below the PW Status TLV has to be a 
> > separate TLV 
> > following the FEC TLV in the label mapping message. Having 
> > said that I 
> > agree with you that the correct way to carry this information 
> > would be in 
> > the optional parameters field in the label mapping message. 
> > Any subsequent 
> > change to the status is conveyed using LDP notification so there is
> > no FEC churn. 
> > 
> > If we all agree on this could the authors make necessary changes to
> > the draft so that we (implementors) could make forward progress ?
> > 
> > Thanks,
> > 
> > - Rex
> > 
> > > 
> > > Yes, we are going to update the draft to remove status related
> > > stuff (as you have covered it in your draft) and keep IP TLV
> > > and other stuff. So your impression is correct.
> > > 
> > > /himanshu
> > > 
> > > > -----Original Message-----
> > > > From: Luca Martini [mailto:lmartini@cisco.com]
> > > > Sent: Tuesday, December 23, 2003 4:34 PM
> > > > To: Shah, Himanshu
> > > > Cc: Rex Emmanuel Fernando; tob@laurelnetworks.com; 
> > Srihari Ramachandra
> > > > Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > > > Subject: Re: [PWE3] Re: PW Status negotiation procedure
> > > > 
> > > > 
> > > > Himanshu,
> > > > 
> > > > When we dicussed this months ago , I had pointed out that 
> > > > putting this 
> > > > in the optional parameter field , means that the FEC changes 
> > > > every time 
> > > > there is a status change. This would mean a withdraw a, and 
> > > > re-advertisement of the PW FEC.
> > > > It is too late to change anything now, But I was under 
> > the impression 
> > > > that the draft below would be amended to include only the IP 
> > > > TLV , and 
> > > > other VPLS related informantion.
> > > > 
> > > > Luca
> > > > 
> > > > 
> > > > Shah, Himanshu wrote:
> > > > 
> > > > >In draft-shah-pwe3-control-protocol-extension-01.txt, 
> > > > >we have recommended that this status TLV (or for that
> > > > >matter any additional TLV) should be part of the
> > > > >"optional parameter" field of the Label Mapping message.
> > > > >
> > > > >
> > > > >/himanshu
> > > > >
> > > > >
> > > > >http://www.ietf.org/internet-drafts/draft-shah-pwe3-control-p
> > > rotocol-extension-01.txt
> > > > >
> > > > >
> > > > >  
> > > > >
> > > > >>-----Original Message-----
> > > > >>From: Luca Martini [mailto:lmartini@cisco.com]
> > > > >>Sent: Tuesday, December 23, 2003 2:28 PM
> > > > >>To: Rex Emmanuel Fernando
> > > > >>Cc: tob@laurelnetworks.com; Srihari Ramachandra Sangli; 
> > Renwei Li;
> > > > >>Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > > > >>Subject: [PWE3] Re: PW Status negotiation procedure
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>Rex Emmanuel Fernando wrote:
> > > > >>
> > > > >>    
> > > > >>
> > > > >>>Hi, Guys,
> > > > >>>
> > > > >>>It seems
> > > > >>>to me that the text which describes PW Status negotiation 
> > > > is flawed.
> > > > >>>
> > > > >>>This is what it says:
> > > > >>>
> > > > >>>---
> > > > >>>
> > > > >>>  "A PE that supports the PW Status TLV MUST include it in 
> > > > >>>      
> > > > >>>
> > > > >>the initial
> > > > >>    
> > > > >>
> > > > >>>  label mapping signaling as part of the PW FEC and 
> > following the
> > > > >>>  interface parameters field. The PW Status TLV will be 
> > > > used for the
> > > > >>>  lifetime of the Pseudowire for PEs that support this TLV.
> > > > >>>
> > > > >>>  If the PW Status TLV is not present in the initial 
> > PW FEC Message
> > > > >>>  received by a PE, then the PW Status TLV will not be 
> > > > used and both
> > > > >>>  PEs of the pseudowire will revert to the label withdraw 
> > > > >>>      
> > > > >>>
> > > > >>procedure for
> > > > >>    
> > > > >>
> > > > >>>  signaling status changes.
> > > > >>>
> > > > >>>  If PW status TLV is sent as part of the initial PW FEC 
> > > > >>>      
> > > > >>>
> > > > >>Message, but
> > > > >>    
> > > > >>
> > > > >>>  the remote PE corresponding FEC advertisement does not 
> > > > >>>      
> > > > >>>
> > > > >>include a PW
> > > > >>    
> > > > >>
> > > > >>>  status TLV, or the remote PE does not support the PW 
> > > > >>>      
> > > > >>>
> > > > >>Status TLV then
> > > > >>    
> > > > >>
> > > > >>>  the PW will revert to the label withdraw method to signal 
> > > > >>>      
> > > > >>>
> > > > >>PW status.
> > > > >>    
> > > > >>
> > > > >>>  Note that if the PW Status TLV is not supported it will 
> > > > >>>      
> > > > >>>
> > > > >>automatically
> > > > >>    
> > > > >>
> > > > >>>  be ignored since the LDP ignore bit is set."
> > > > >>>
> > > > >>>----
> > > > >>>
> > > > >>>The text says that the "PW Status TLV" should be part of 
> > > > the FEC TLV
> > > > >>>and following the interface parameters. Note that according 
> > > > >>>      
> > > > >>>
> > > > >>to LDP spec
> > > > >>    
> > > > >>
> > > > >>>a FEC TLV does not have sub-tlvs and I don't see a 
> > provision for
> > > > >>>having sub-tlvs within it. All it has is a contiguous array 
> > > > >>>      
> > > > >>>
> > > > >>of different
> > > > >>    
> > > > >>
> > > > >>>FEC types. So I am assuming that the PW Status TLV is 
> > *NOT* part of
> > > > >>>the FEC TLV but an additional TLV following the FEC TLV. 
> > > > >>>      
> > > > >>>
> > > > >>Also note that
> > > > >>    
> > > > >>
> > > > >>>the text says that old implementations which do not suppor 
> > > > this would
> > > > >>>ignore it - this is possible only if its a separate 
> > TLV and is not
> > > > >>>piggybacked on the FEC TLV. The text has to be corrected to 
> > > > >>>      
> > > > >>>
> > > > >>relfect this. 
> > > > >>    
> > > > >>
> > > > >>> 
> > > > >>>
> > > > >>>      
> > > > >>>
> > > > >>Yes , I can see there is a problem in the description. 
> > And yes the 
> > > > >>status TLV is a separate TLV and MUST immediately follow 
> > > > the FEC TLV.
> > > > >>
> > > > >>    
> > > > >>
> > > > >>>The next question I have is, if the PW Status TLV follows 
> > > > >>>      
> > > > >>>
> > > > >>the FEC TLV, to
> > > > >>    
> > > > >>
> > > > >>>which FEC does it apply (note that a FEC TLV could have 
> > > > 'n' number of
> > > > >>>FECs). Does the PW status apply to all FECs ?
> > > > >>> 
> > > > >>>
> > > > >>>      
> > > > >>>
> > > > >>not for the PW case. In IP you can have multiple FEC elements 
> > > > >>in the FEC 
> > > > >>( sharing of LSP for multiple IP addresses ), but for the PW 
> > > > >>it's only 
> > > > >>one FEC element per FEC so the status TLV will be only 
> > for the FEC 
> > > > >>element present.
> > > > >>
> > > > >>    
> > > > >>
> > > > >>>Correct me if I am wrong in any of these points.
> > > > >>> 
> > > > >>>
> > > > >>>      
> > > > >>>
> > > > >>you are right on most of them :-)
> > > > >>
> > > > >>    
> > > > >>
> > > > >>>Also is there an IANA assigned number for the PW 
> > Status TLV type ?
> > > > >>> 
> > > > >>>
> > > > >>>      
> > > > >>>
> > > > >>No. Not yet.
> > > > >>
> > > > >>I'll send out a correction for the text above . it really 
> > > > >>meant to say 
> > > > >>"the PW Status TLV should immediately follow the FEC 
> > TLV" as in the 
> > > > >>picture...
> > > > >>
> > > > >>Luca
> > > > >>
> > > > >>
> > > > >>    
> > > > >>
> > > > >>>Thanks for your clarification.
> > > > >>>
> > > > >>>- Rex
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> 
> > > > >>>
> > > > >>>      
> > > > >>>
> > > > >>_______________________________________________
> > > > >>pwe3 mailing list
> > > > >>pwe3@ietf.org
> > > > >>https://www1.ietf.org/mailman/listinfo/pwe3
> > > > >>
> > > > >>    
> > > > >>
> > > > >
> > > > >_______________________________________________
> > > > >pwe3 mailing list
> > > > >pwe3@ietf.org
> > > > >https://www1.ietf.org/mailman/listinfo/pwe3
> > > > >
> > > > >  
> > > > >
> > > > 
> > > > 
> > > 
> > 
> > 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Luca Martini <lmartini@cisco.com>
Subject: Re: Re: PW Status negotiation procedure
Date: Wed, 24 Dec 2003 16:28:57 -0700
Organization: Cisco Systems
Lines: 536
Sender: pwe3-admin@ietf.org
References: <B99995113B318D44BBE87DC50092EDA90C0D564A@nj7460exch006u.ho.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "'Shah, Himanshu'" <hshah@ciena.com>,
        "'Rex Emmanuel Fernando'" <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li <renwei@procket.com>, Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Thu Dec 25 00:33:04 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
To: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
In-Reply-To: <B99995113B318D44BBE87DC50092EDA90C0D564A@nj7460exch006u.ho.lucent.com>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



Busschbach, Peter B (Peter) wrote:

>draft-ietf-pwe3-iana-allocation-02 defines the following PW status codes.
>
>0x00000000 - Pseudo Wire forwarding ( clear all failures)
>0x00000001 - Pseudo Wire Not Forwarding
>0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault
>0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault
>0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault
>0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault
>
>Could anyone explain what exactly is meant by each of these codes?
>
>Here are the reasons I am uncertain about the semantics:
>
>- Should "customer-facing PW" be read as "attachment circuit"? If not, I don't know what it is meant. From the perspective of a PE, I would think that the PW is always PSN-facing.
>  
>
Yes,  It would probably make it easier to read if we corected the 
definition.  I take that attachment circuit does not mean attachment 
interface right ?

>- I assume that "PSN-facing transmit fault" is an indication from one PE (PE1) to its peer (PE2) that there is a failure on the PW in the direction from PE1 to PE2. However, if that failure does indeed exist, how is the status indication  supposed to reach PE2?
>  
>
through the control channel. After all, the MPLS LSP can be broken , but 
IP connectivity can still exist.
I cant remember now, but there was some reason why we did not simply 
call this "Local PSN tunnel" .
we can change this if nobody else objects...

> 
>- What is meant by "Pseudo Wire Not Forwarding"? When is this error code used instead of "PSN-facing PW receive fault" and/or "PSN-facing PW transmit fault"?
>  
>
Somebody purposefully configures it to be administratively down.

Please keep in mind that these are general status singals, and not meant 
to carry the operational status information that a NOC would need.
Luca

>Peter
>
>  
>
>>-----Original Message-----
>>From: Shah, Himanshu [mailto:hshah@ciena.com]
>>Sent: Wednesday, December 24, 2003 7:49 AM
>>To: 'Rex Emmanuel Fernando'
>>Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
>>Ramachandra Sangli;
>>Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
>>Subject: RE: [PWE3] Re: PW Status negotiation procedure
>>
>>
>>The changes to PWE3-control draft has to be determined
>>by Luca and his co-authors. We can only make recommendations.....
>>
>>/himanshu
>>
>>    
>>
>>>-----Original Message-----
>>>From: Rex Emmanuel Fernando [mailto:rex@procket.com]
>>>Sent: Wednesday, December 24, 2003 12:25 AM
>>>To: Shah, Himanshu
>>>Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
>>>Ramachandra Sangli;
>>>Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
>>>Subject: RE: [PWE3] Re: PW Status negotiation procedure
>>>
>>>
>>>
>>>Himanshu,
>>>
>>>      
>>>
>>>>The Status TLV is sent in label mapping message 
>>>>in "optional parameter" field as a  "capability learning" 
>>>>        
>>>>
>>mechanism.
>>    
>>
>>>>The changes in PW status (or others) is subsequently sent as 
>>>>LDP notification messages as per rev1 draft (we did listen 
>>>>        
>>>>
>>>to you :-).
>>>      
>>>
>>>>I still believe that dispatching initial status tlv in optional
>>>>parameter field is a better choice than appending to the PW FEC.
>>>>Its a suggestion that you may want to consider....
>>>>        
>>>>
>>>As Luca seems to concur below the PW Status TLV has to be a 
>>>separate TLV 
>>>following the FEC TLV in the label mapping message. Having 
>>>said that I 
>>>agree with you that the correct way to carry this information 
>>>would be in 
>>>the optional parameters field in the label mapping message. 
>>>Any subsequent 
>>>change to the status is conveyed using LDP notification so there is
>>>no FEC churn. 
>>>
>>>If we all agree on this could the authors make necessary changes to
>>>the draft so that we (implementors) could make forward progress ?
>>>
>>>Thanks,
>>>
>>>- Rex
>>>
>>>      
>>>
>>>>Yes, we are going to update the draft to remove status related
>>>>stuff (as you have covered it in your draft) and keep IP TLV
>>>>and other stuff. So your impression is correct.
>>>>
>>>>/himanshu
>>>>
>>>>        
>>>>
>>>>>-----Original Message-----
>>>>>From: Luca Martini [mailto:lmartini@cisco.com]
>>>>>Sent: Tuesday, December 23, 2003 4:34 PM
>>>>>To: Shah, Himanshu
>>>>>Cc: Rex Emmanuel Fernando; tob@laurelnetworks.com; 
>>>>>          
>>>>>
>>>Srihari Ramachandra
>>>      
>>>
>>>>>Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
>>>>>Subject: Re: [PWE3] Re: PW Status negotiation procedure
>>>>>
>>>>>
>>>>>Himanshu,
>>>>>
>>>>>When we dicussed this months ago , I had pointed out that 
>>>>>putting this 
>>>>>in the optional parameter field , means that the FEC changes 
>>>>>every time 
>>>>>there is a status change. This would mean a withdraw a, and 
>>>>>re-advertisement of the PW FEC.
>>>>>It is too late to change anything now, But I was under 
>>>>>          
>>>>>
>>>the impression 
>>>      
>>>
>>>>>that the draft below would be amended to include only the IP 
>>>>>TLV , and 
>>>>>other VPLS related informantion.
>>>>>
>>>>>Luca
>>>>>
>>>>>
>>>>>Shah, Himanshu wrote:
>>>>>
>>>>>          
>>>>>
>>>>>>In draft-shah-pwe3-control-protocol-extension-01.txt, 
>>>>>>we have recommended that this status TLV (or for that
>>>>>>matter any additional TLV) should be part of the
>>>>>>"optional parameter" field of the Label Mapping message.
>>>>>>
>>>>>>
>>>>>>/himanshu
>>>>>>
>>>>>>
>>>>>>http://www.ietf.org/internet-drafts/draft-shah-pwe3-control-p
>>>>>>            
>>>>>>
>>>>rotocol-extension-01.txt
>>>>        
>>>>
>>>>>> 
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Luca Martini [mailto:lmartini@cisco.com]
>>>>>>>Sent: Tuesday, December 23, 2003 2:28 PM
>>>>>>>To: Rex Emmanuel Fernando
>>>>>>>Cc: tob@laurelnetworks.com; Srihari Ramachandra Sangli; 
>>>>>>>              
>>>>>>>
>>>Renwei Li;
>>>      
>>>
>>>>>>>Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
>>>>>>>Subject: [PWE3] Re: PW Status negotiation procedure
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Rex Emmanuel Fernando wrote:
>>>>>>>
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>Hi, Guys,
>>>>>>>>
>>>>>>>>It seems
>>>>>>>>to me that the text which describes PW Status negotiation 
>>>>>>>>                
>>>>>>>>
>>>>>is flawed.
>>>>>          
>>>>>
>>>>>>>>This is what it says:
>>>>>>>>
>>>>>>>>---
>>>>>>>>
>>>>>>>> "A PE that supports the PW Status TLV MUST include it in 
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>the initial
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>> label mapping signaling as part of the PW FEC and 
>>>>>>>>                
>>>>>>>>
>>>following the
>>>      
>>>
>>>>>>>> interface parameters field. The PW Status TLV will be 
>>>>>>>>                
>>>>>>>>
>>>>>used for the
>>>>>          
>>>>>
>>>>>>>> lifetime of the Pseudowire for PEs that support this TLV.
>>>>>>>>
>>>>>>>> If the PW Status TLV is not present in the initial 
>>>>>>>>                
>>>>>>>>
>>>PW FEC Message
>>>      
>>>
>>>>>>>> received by a PE, then the PW Status TLV will not be 
>>>>>>>>                
>>>>>>>>
>>>>>used and both
>>>>>          
>>>>>
>>>>>>>> PEs of the pseudowire will revert to the label withdraw 
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>procedure for
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>> signaling status changes.
>>>>>>>>
>>>>>>>> If PW status TLV is sent as part of the initial PW FEC 
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>Message, but
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>> the remote PE corresponding FEC advertisement does not 
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>include a PW
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>> status TLV, or the remote PE does not support the PW 
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>Status TLV then
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>> the PW will revert to the label withdraw method to signal 
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>PW status.
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>> Note that if the PW Status TLV is not supported it will 
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>automatically
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>> be ignored since the LDP ignore bit is set."
>>>>>>>>
>>>>>>>>----
>>>>>>>>
>>>>>>>>The text says that the "PW Status TLV" should be part of 
>>>>>>>>                
>>>>>>>>
>>>>>the FEC TLV
>>>>>          
>>>>>
>>>>>>>>and following the interface parameters. Note that according 
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>to LDP spec
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>a FEC TLV does not have sub-tlvs and I don't see a 
>>>>>>>>                
>>>>>>>>
>>>provision for
>>>      
>>>
>>>>>>>>having sub-tlvs within it. All it has is a contiguous array 
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>of different
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>FEC types. So I am assuming that the PW Status TLV is 
>>>>>>>>                
>>>>>>>>
>>>*NOT* part of
>>>      
>>>
>>>>>>>>the FEC TLV but an additional TLV following the FEC TLV. 
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>Also note that
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>the text says that old implementations which do not suppor 
>>>>>>>>                
>>>>>>>>
>>>>>this would
>>>>>          
>>>>>
>>>>>>>>ignore it - this is possible only if its a separate 
>>>>>>>>                
>>>>>>>>
>>>TLV and is not
>>>      
>>>
>>>>>>>>piggybacked on the FEC TLV. The text has to be corrected to 
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>relfect this. 
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>Yes , I can see there is a problem in the description. 
>>>>>>>              
>>>>>>>
>>>And yes the 
>>>      
>>>
>>>>>>>status TLV is a separate TLV and MUST immediately follow 
>>>>>>>              
>>>>>>>
>>>>>the FEC TLV.
>>>>>          
>>>>>
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>The next question I have is, if the PW Status TLV follows 
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>the FEC TLV, to
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>which FEC does it apply (note that a FEC TLV could have 
>>>>>>>>                
>>>>>>>>
>>>>>'n' number of
>>>>>          
>>>>>
>>>>>>>>FECs). Does the PW status apply to all FECs ?
>>>>>>>>
>>>>>>>>
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>not for the PW case. In IP you can have multiple FEC elements 
>>>>>>>in the FEC 
>>>>>>>( sharing of LSP for multiple IP addresses ), but for the PW 
>>>>>>>it's only 
>>>>>>>one FEC element per FEC so the status TLV will be only 
>>>>>>>              
>>>>>>>
>>>for the FEC 
>>>      
>>>
>>>>>>>element present.
>>>>>>>
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>Correct me if I am wrong in any of these points.
>>>>>>>>
>>>>>>>>
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>you are right on most of them :-)
>>>>>>>
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>Also is there an IANA assigned number for the PW 
>>>>>>>>                
>>>>>>>>
>>>Status TLV type ?
>>>      
>>>
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>No. Not yet.
>>>>>>>
>>>>>>>I'll send out a correction for the text above . it really 
>>>>>>>meant to say 
>>>>>>>"the PW Status TLV should immediately follow the FEC 
>>>>>>>              
>>>>>>>
>>>TLV" as in the 
>>>      
>>>
>>>>>>>picture...
>>>>>>>
>>>>>>>Luca
>>>>>>>
>>>>>>>
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>Thanks for your clarification.
>>>>>>>>
>>>>>>>>- Rex
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>pwe3 mailing list
>>>>>>>pwe3@ietf.org
>>>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
>>>>>>>
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>_______________________________________________
>>>>>>pwe3 mailing list
>>>>>>pwe3@ietf.org
>>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
>>>>>>
>>>>>> 
>>>>>>
>>>>>>            
>>>>>>
>>>>>          
>>>>>
>>>      
>>>
>>_______________________________________________
>>pwe3 mailing list
>>pwe3@ietf.org
>>https://www1.ietf.org/mailman/listinfo/pwe3
>>
>>    
>>
>
>  
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Rex Emmanuel Fernando <rex@procket.com>
Subject: RE: Re: PW Status negotiation procedure
Date: Tue, 23 Dec 2003 21:24:52 -0800 (PST)
Lines: 274
Sender: pwe3-admin@ietf.org
References: <8162DD929D7AD24CAD3FC5317CE41FB06D459D@w2kmaexg02.wavesmithnet.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: "'Luca Martini'" <lmartini@cisco.com>, <tob@laurelnetworks.com>,
        Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li <renwei@procket.com>, Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Thu Dec 25 20:39:06 2003
Return-path: <pwe3-admin@ietf.org>
To: "Shah, Himanshu" <hshah@ciena.com>
In-Reply-To: <8162DD929D7AD24CAD3FC5317CE41FB06D459D@w2kmaexg02.wavesmithnet.com>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


Himanshu,

> The Status TLV is sent in label mapping message 
> in "optional parameter" field as a  "capability learning" mechanism.
> 
> The changes in PW status (or others) is subsequently sent as 
> LDP notification messages as per rev1 draft (we did listen to you :-).
> 
> I still believe that dispatching initial status tlv in optional
> parameter field is a better choice than appending to the PW FEC.
> Its a suggestion that you may want to consider....

As Luca seems to concur below the PW Status TLV has to be a separate TLV 
following the FEC TLV in the label mapping message. Having said that I 
agree with you that the correct way to carry this information would be in 
the optional parameters field in the label mapping message. Any subsequent 
change to the status is conveyed using LDP notification so there is
no FEC churn. 

If we all agree on this could the authors make necessary changes to
the draft so that we (implementors) could make forward progress ?

Thanks,

- Rex

> 
> Yes, we are going to update the draft to remove status related
> stuff (as you have covered it in your draft) and keep IP TLV
> and other stuff. So your impression is correct.
> 
> /himanshu
> 
> > -----Original Message-----
> > From: Luca Martini [mailto:lmartini@cisco.com]
> > Sent: Tuesday, December 23, 2003 4:34 PM
> > To: Shah, Himanshu
> > Cc: Rex Emmanuel Fernando; tob@laurelnetworks.com; Srihari Ramachandra
> > Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > Subject: Re: [PWE3] Re: PW Status negotiation procedure
> > 
> > 
> > Himanshu,
> > 
> > When we dicussed this months ago , I had pointed out that 
> > putting this 
> > in the optional parameter field , means that the FEC changes 
> > every time 
> > there is a status change. This would mean a withdraw a, and 
> > re-advertisement of the PW FEC.
> > It is too late to change anything now, But I was under the impression 
> > that the draft below would be amended to include only the IP 
> > TLV , and 
> > other VPLS related informantion.
> > 
> > Luca
> > 
> > 
> > Shah, Himanshu wrote:
> > 
> > >In draft-shah-pwe3-control-protocol-extension-01.txt, 
> > >we have recommended that this status TLV (or for that
> > >matter any additional TLV) should be part of the
> > >"optional parameter" field of the Label Mapping message.
> > >
> > >
> > >/himanshu
> > >
> > >
> > >http://www.ietf.org/internet-drafts/draft-shah-pwe3-control-p
> rotocol-extension-01.txt
> > >
> > >
> > >  
> > >
> > >>-----Original Message-----
> > >>From: Luca Martini [mailto:lmartini@cisco.com]
> > >>Sent: Tuesday, December 23, 2003 2:28 PM
> > >>To: Rex Emmanuel Fernando
> > >>Cc: tob@laurelnetworks.com; Srihari Ramachandra Sangli; Renwei Li;
> > >>Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > >>Subject: [PWE3] Re: PW Status negotiation procedure
> > >>
> > >>
> > >>
> > >>
> > >>Rex Emmanuel Fernando wrote:
> > >>
> > >>    
> > >>
> > >>>Hi, Guys,
> > >>>
> > >>>It seems
> > >>>to me that the text which describes PW Status negotiation 
> > is flawed.
> > >>>
> > >>>This is what it says:
> > >>>
> > >>>---
> > >>>
> > >>>  "A PE that supports the PW Status TLV MUST include it in 
> > >>>      
> > >>>
> > >>the initial
> > >>    
> > >>
> > >>>  label mapping signaling as part of the PW FEC and following the
> > >>>  interface parameters field. The PW Status TLV will be 
> > used for the
> > >>>  lifetime of the Pseudowire for PEs that support this TLV.
> > >>>
> > >>>  If the PW Status TLV is not present in the initial PW FEC Message
> > >>>  received by a PE, then the PW Status TLV will not be 
> > used and both
> > >>>  PEs of the pseudowire will revert to the label withdraw 
> > >>>      
> > >>>
> > >>procedure for
> > >>    
> > >>
> > >>>  signaling status changes.
> > >>>
> > >>>  If PW status TLV is sent as part of the initial PW FEC 
> > >>>      
> > >>>
> > >>Message, but
> > >>    
> > >>
> > >>>  the remote PE corresponding FEC advertisement does not 
> > >>>      
> > >>>
> > >>include a PW
> > >>    
> > >>
> > >>>  status TLV, or the remote PE does not support the PW 
> > >>>      
> > >>>
> > >>Status TLV then
> > >>    
> > >>
> > >>>  the PW will revert to the label withdraw method to signal 
> > >>>      
> > >>>
> > >>PW status.
> > >>    
> > >>
> > >>>  Note that if the PW Status TLV is not supported it will 
> > >>>      
> > >>>
> > >>automatically
> > >>    
> > >>
> > >>>  be ignored since the LDP ignore bit is set."
> > >>>
> > >>>----
> > >>>
> > >>>The text says that the "PW Status TLV" should be part of 
> > the FEC TLV
> > >>>and following the interface parameters. Note that according 
> > >>>      
> > >>>
> > >>to LDP spec
> > >>    
> > >>
> > >>>a FEC TLV does not have sub-tlvs and I don't see a provision for
> > >>>having sub-tlvs within it. All it has is a contiguous array 
> > >>>      
> > >>>
> > >>of different
> > >>    
> > >>
> > >>>FEC types. So I am assuming that the PW Status TLV is *NOT* part of
> > >>>the FEC TLV but an additional TLV following the FEC TLV. 
> > >>>      
> > >>>
> > >>Also note that
> > >>    
> > >>
> > >>>the text says that old implementations which do not suppor 
> > this would
> > >>>ignore it - this is possible only if its a separate TLV and is not
> > >>>piggybacked on the FEC TLV. The text has to be corrected to 
> > >>>      
> > >>>
> > >>relfect this. 
> > >>    
> > >>
> > >>> 
> > >>>
> > >>>      
> > >>>
> > >>Yes , I can see there is a problem in the description. And yes the 
> > >>status TLV is a separate TLV and MUST immediately follow 
> > the FEC TLV.
> > >>
> > >>    
> > >>
> > >>>The next question I have is, if the PW Status TLV follows 
> > >>>      
> > >>>
> > >>the FEC TLV, to
> > >>    
> > >>
> > >>>which FEC does it apply (note that a FEC TLV could have 
> > 'n' number of
> > >>>FECs). Does the PW status apply to all FECs ?
> > >>> 
> > >>>
> > >>>      
> > >>>
> > >>not for the PW case. In IP you can have multiple FEC elements 
> > >>in the FEC 
> > >>( sharing of LSP for multiple IP addresses ), but for the PW 
> > >>it's only 
> > >>one FEC element per FEC so the status TLV will be only for the FEC 
> > >>element present.
> > >>
> > >>    
> > >>
> > >>>Correct me if I am wrong in any of these points.
> > >>> 
> > >>>
> > >>>      
> > >>>
> > >>you are right on most of them :-)
> > >>
> > >>    
> > >>
> > >>>Also is there an IANA assigned number for the PW Status TLV type ?
> > >>> 
> > >>>
> > >>>      
> > >>>
> > >>No. Not yet.
> > >>
> > >>I'll send out a correction for the text above . it really 
> > >>meant to say 
> > >>"the PW Status TLV should immediately follow the FEC TLV" as in the 
> > >>picture...
> > >>
> > >>Luca
> > >>
> > >>
> > >>    
> > >>
> > >>>Thanks for your clarification.
> > >>>
> > >>>- Rex
> > >>>
> > >>>
> > >>>
> > >>> 
> > >>>
> > >>>      
> > >>>
> > >>_______________________________________________
> > >>pwe3 mailing list
> > >>pwe3@ietf.org
> > >>https://www1.ietf.org/mailman/listinfo/pwe3
> > >>
> > >>    
> > >>
> > >
> > >_______________________________________________
> > >pwe3 mailing list
> > >pwe3@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/pwe3
> > >
> > >  
> > >
> > 
> > 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Jiang zhou" <zjiang@photonicbridges.com>
Subject: Test only
Date: Fri, 26 Dec 2003 12:34:10 +0800
Organization: =?gb2312?B?ueLHxb/GvLw=?=
Lines: 9
Sender: pwe3-admin@ietf.org
Reply-To: zjiang@photonicbridges.com
Mime-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Fri Dec 26 05:35:09 2003
Return-path: <pwe3-admin@ietf.org>
To: "pwe3" <pwe3@ietf.org>
X-Mailer: Foxmail 5.0 beta2 [cn]
X-OriginalArrivalTime: 26 Dec 2003 04:34:10.0578 (UTC) FILETIME=[81C67F20:01C3CB69]
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Hi,pwe3


' spamcontrol '

Best Regards
Jiang zhou
Email:zjiang@photonicbridges.com
2003-12-26


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: Re: PW Status negotiation procedure
Date: Mon, 29 Dec 2003 10:23:21 -0500
Lines: 572
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Cc: "'Shah, Himanshu'" <hshah@ciena.com>,
        "'Rex Emmanuel Fernando'"
	 <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli
	 <srihari@procket.com>,
        Renwei Li <renwei@procket.com>,
        Avneesh Sachdev
	 <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Dec 29 16:42:15 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Luca Martini'" <lmartini@cisco.com>
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



> -----Original Message-----
> From: Luca Martini [mailto:lmartini@cisco.com]
> Sent: Wednesday, December 24, 2003 6:29 PM

> Busschbach, Peter B (Peter) wrote:
> 
> >draft-ietf-pwe3-iana-allocation-02 defines the following PW 
> status codes.
> >
> >0x00000000 - Pseudo Wire forwarding ( clear all failures)
> >0x00000001 - Pseudo Wire Not Forwarding
> >0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault
> >0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault
> >0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault
> >0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault
> >
> >Could anyone explain what exactly is meant by each of these codes?
> >
> >Here are the reasons I am uncertain about the semantics:
> >
> >- Should "customer-facing PW" be read as "attachment 
> circuit"? If not, I don't know what it is meant. From the 
> perspective of a PE, I would think that the PW is always PSN-facing.
> >  
> >
> Yes,  It would probably make it easier to read if we corected the 
> definition.  I take that attachment circuit does not mean attachment 
> interface right ?

Luca,

That is a good point. I don't know what was originally intended, but it would make sense to clearly define what fault conditions are covered by these error codes.

Take, for example, a receive failure on an Attachment Circuit. In most cases such a failure indication should be propagated via failure notifications in the emulated protocol and not via the PW control plane. E.g. if the emulated service is ATM, the PE should translate a receive failure on the Attachment Ciruit to an AIS signal that is forwarded over the Pseudo Wire. There would be no need for a failure indication over the PW control plane.

I can see two exceptions:

1) When port-mode encapsulation is used. I.e. if there is no Native ATM Processing in the PE, the PE is not able to generate AIS signals (after all, it doesn't know which VCs are active). In that case, it would make sense to use the PW control plane to indicate a failure on the Attachment Circuit. 

2) When the failure occurs on the interface within the PE between the NSP module and the PW module. In that case, the NSP module is cut off from the PW module and can not be relied on for AIS generation. Hence, the need for a failure indication in the PW control plane so that the egress PE can generate AIS.


I think the OAM Message Mapping draft is the right place to identify under which conditions a PE should generate each of the PW status codes and how its peer should react. However, until a new version of that draft comes out, I would appreciate it if people could give more examples to illustrate when the PW status codes should be used.

Peter



> 
> >- I assume that "PSN-facing transmit fault" is an indication 
> from one PE (PE1) to its peer (PE2) that there is a failure 
> on the PW in the direction from PE1 to PE2. However, if that 
> failure does indeed exist, how is the status indication  
> supposed to reach PE2?
> >  
> >
> through the control channel. After all, the MPLS LSP can be 
> broken , but 
> IP connectivity can still exist.
> I cant remember now, but there was some reason why we did not simply 
> call this "Local PSN tunnel" .
> we can change this if nobody else objects...
> 
> > 
> >- What is meant by "Pseudo Wire Not Forwarding"? When is 
> this error code used instead of "PSN-facing PW receive fault" 
> and/or "PSN-facing PW transmit fault"?
> >  
> >
> Somebody purposefully configures it to be administratively down.
> 
> Please keep in mind that these are general status singals, 
> and not meant 
> to carry the operational status information that a NOC would need.
> Luca
> 
> >Peter
> >
> >  
> >
> >>-----Original Message-----
> >>From: Shah, Himanshu [mailto:hshah@ciena.com]
> >>Sent: Wednesday, December 24, 2003 7:49 AM
> >>To: 'Rex Emmanuel Fernando'
> >>Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
> >>Ramachandra Sangli;
> >>Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> >>Subject: RE: [PWE3] Re: PW Status negotiation procedure
> >>
> >>
> >>The changes to PWE3-control draft has to be determined
> >>by Luca and his co-authors. We can only make recommendations.....
> >>
> >>/himanshu
> >>
> >>    
> >>
> >>>-----Original Message-----
> >>>From: Rex Emmanuel Fernando [mailto:rex@procket.com]
> >>>Sent: Wednesday, December 24, 2003 12:25 AM
> >>>To: Shah, Himanshu
> >>>Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
> >>>Ramachandra Sangli;
> >>>Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> >>>Subject: RE: [PWE3] Re: PW Status negotiation procedure
> >>>
> >>>
> >>>
> >>>Himanshu,
> >>>
> >>>      
> >>>
> >>>>The Status TLV is sent in label mapping message 
> >>>>in "optional parameter" field as a  "capability learning" 
> >>>>        
> >>>>
> >>mechanism.
> >>    
> >>
> >>>>The changes in PW status (or others) is subsequently sent as 
> >>>>LDP notification messages as per rev1 draft (we did listen 
> >>>>        
> >>>>
> >>>to you :-).
> >>>      
> >>>
> >>>>I still believe that dispatching initial status tlv in optional
> >>>>parameter field is a better choice than appending to the PW FEC.
> >>>>Its a suggestion that you may want to consider....
> >>>>        
> >>>>
> >>>As Luca seems to concur below the PW Status TLV has to be a 
> >>>separate TLV 
> >>>following the FEC TLV in the label mapping message. Having 
> >>>said that I 
> >>>agree with you that the correct way to carry this information 
> >>>would be in 
> >>>the optional parameters field in the label mapping message. 
> >>>Any subsequent 
> >>>change to the status is conveyed using LDP notification so there is
> >>>no FEC churn. 
> >>>
> >>>If we all agree on this could the authors make necessary changes to
> >>>the draft so that we (implementors) could make forward progress ?
> >>>
> >>>Thanks,
> >>>
> >>>- Rex
> >>>
> >>>      
> >>>
> >>>>Yes, we are going to update the draft to remove status related
> >>>>stuff (as you have covered it in your draft) and keep IP TLV
> >>>>and other stuff. So your impression is correct.
> >>>>
> >>>>/himanshu
> >>>>
> >>>>        
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Luca Martini [mailto:lmartini@cisco.com]
> >>>>>Sent: Tuesday, December 23, 2003 4:34 PM
> >>>>>To: Shah, Himanshu
> >>>>>Cc: Rex Emmanuel Fernando; tob@laurelnetworks.com; 
> >>>>>          
> >>>>>
> >>>Srihari Ramachandra
> >>>      
> >>>
> >>>>>Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> >>>>>Subject: Re: [PWE3] Re: PW Status negotiation procedure
> >>>>>
> >>>>>
> >>>>>Himanshu,
> >>>>>
> >>>>>When we dicussed this months ago , I had pointed out that 
> >>>>>putting this 
> >>>>>in the optional parameter field , means that the FEC changes 
> >>>>>every time 
> >>>>>there is a status change. This would mean a withdraw a, and 
> >>>>>re-advertisement of the PW FEC.
> >>>>>It is too late to change anything now, But I was under 
> >>>>>          
> >>>>>
> >>>the impression 
> >>>      
> >>>
> >>>>>that the draft below would be amended to include only the IP 
> >>>>>TLV , and 
> >>>>>other VPLS related informantion.
> >>>>>
> >>>>>Luca
> >>>>>
> >>>>>
> >>>>>Shah, Himanshu wrote:
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>In draft-shah-pwe3-control-protocol-extension-01.txt, 
> >>>>>>we have recommended that this status TLV (or for that
> >>>>>>matter any additional TLV) should be part of the
> >>>>>>"optional parameter" field of the Label Mapping message.
> >>>>>>
> >>>>>>
> >>>>>>/himanshu
> >>>>>>
> >>>>>>
> >>>>>>http://www.ietf.org/internet-drafts/draft-shah-pwe3-control-p
> >>>>>>            
> >>>>>>
> >>>>rotocol-extension-01.txt
> >>>>        
> >>>>
> >>>>>> 
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>-----Original Message-----
> >>>>>>>From: Luca Martini [mailto:lmartini@cisco.com]
> >>>>>>>Sent: Tuesday, December 23, 2003 2:28 PM
> >>>>>>>To: Rex Emmanuel Fernando
> >>>>>>>Cc: tob@laurelnetworks.com; Srihari Ramachandra Sangli; 
> >>>>>>>              
> >>>>>>>
> >>>Renwei Li;
> >>>      
> >>>
> >>>>>>>Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> >>>>>>>Subject: [PWE3] Re: PW Status negotiation procedure
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>Rex Emmanuel Fernando wrote:
> >>>>>>>
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>>Hi, Guys,
> >>>>>>>>
> >>>>>>>>It seems
> >>>>>>>>to me that the text which describes PW Status negotiation 
> >>>>>>>>                
> >>>>>>>>
> >>>>>is flawed.
> >>>>>          
> >>>>>
> >>>>>>>>This is what it says:
> >>>>>>>>
> >>>>>>>>---
> >>>>>>>>
> >>>>>>>> "A PE that supports the PW Status TLV MUST include it in 
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>the initial
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>> label mapping signaling as part of the PW FEC and 
> >>>>>>>>                
> >>>>>>>>
> >>>following the
> >>>      
> >>>
> >>>>>>>> interface parameters field. The PW Status TLV will be 
> >>>>>>>>                
> >>>>>>>>
> >>>>>used for the
> >>>>>          
> >>>>>
> >>>>>>>> lifetime of the Pseudowire for PEs that support this TLV.
> >>>>>>>>
> >>>>>>>> If the PW Status TLV is not present in the initial 
> >>>>>>>>                
> >>>>>>>>
> >>>PW FEC Message
> >>>      
> >>>
> >>>>>>>> received by a PE, then the PW Status TLV will not be 
> >>>>>>>>                
> >>>>>>>>
> >>>>>used and both
> >>>>>          
> >>>>>
> >>>>>>>> PEs of the pseudowire will revert to the label withdraw 
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>procedure for
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>> signaling status changes.
> >>>>>>>>
> >>>>>>>> If PW status TLV is sent as part of the initial PW FEC 
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>Message, but
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>> the remote PE corresponding FEC advertisement does not 
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>include a PW
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>> status TLV, or the remote PE does not support the PW 
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>Status TLV then
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>> the PW will revert to the label withdraw method to signal 
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>PW status.
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>> Note that if the PW Status TLV is not supported it will 
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>automatically
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>> be ignored since the LDP ignore bit is set."
> >>>>>>>>
> >>>>>>>>----
> >>>>>>>>
> >>>>>>>>The text says that the "PW Status TLV" should be part of 
> >>>>>>>>                
> >>>>>>>>
> >>>>>the FEC TLV
> >>>>>          
> >>>>>
> >>>>>>>>and following the interface parameters. Note that according 
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>to LDP spec
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>>a FEC TLV does not have sub-tlvs and I don't see a 
> >>>>>>>>                
> >>>>>>>>
> >>>provision for
> >>>      
> >>>
> >>>>>>>>having sub-tlvs within it. All it has is a contiguous array 
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>of different
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>>FEC types. So I am assuming that the PW Status TLV is 
> >>>>>>>>                
> >>>>>>>>
> >>>*NOT* part of
> >>>      
> >>>
> >>>>>>>>the FEC TLV but an additional TLV following the FEC TLV. 
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>Also note that
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>>the text says that old implementations which do not suppor 
> >>>>>>>>                
> >>>>>>>>
> >>>>>this would
> >>>>>          
> >>>>>
> >>>>>>>>ignore it - this is possible only if its a separate 
> >>>>>>>>                
> >>>>>>>>
> >>>TLV and is not
> >>>      
> >>>
> >>>>>>>>piggybacked on the FEC TLV. The text has to be corrected to 
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>relfect this. 
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>Yes , I can see there is a problem in the description. 
> >>>>>>>              
> >>>>>>>
> >>>And yes the 
> >>>      
> >>>
> >>>>>>>status TLV is a separate TLV and MUST immediately follow 
> >>>>>>>              
> >>>>>>>
> >>>>>the FEC TLV.
> >>>>>          
> >>>>>
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>>The next question I have is, if the PW Status TLV follows 
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>the FEC TLV, to
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>>which FEC does it apply (note that a FEC TLV could have 
> >>>>>>>>                
> >>>>>>>>
> >>>>>'n' number of
> >>>>>          
> >>>>>
> >>>>>>>>FECs). Does the PW status apply to all FECs ?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>not for the PW case. In IP you can have multiple FEC elements 
> >>>>>>>in the FEC 
> >>>>>>>( sharing of LSP for multiple IP addresses ), but for the PW 
> >>>>>>>it's only 
> >>>>>>>one FEC element per FEC so the status TLV will be only 
> >>>>>>>              
> >>>>>>>
> >>>for the FEC 
> >>>      
> >>>
> >>>>>>>element present.
> >>>>>>>
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>>Correct me if I am wrong in any of these points.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>you are right on most of them :-)
> >>>>>>>
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>>Also is there an IANA assigned number for the PW 
> >>>>>>>>                
> >>>>>>>>
> >>>Status TLV type ?
> >>>      
> >>>
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>No. Not yet.
> >>>>>>>
> >>>>>>>I'll send out a correction for the text above . it really 
> >>>>>>>meant to say 
> >>>>>>>"the PW Status TLV should immediately follow the FEC 
> >>>>>>>              
> >>>>>>>
> >>>TLV" as in the 
> >>>      
> >>>
> >>>>>>>picture...
> >>>>>>>
> >>>>>>>Luca
> >>>>>>>
> >>>>>>>
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>>Thanks for your clarification.
> >>>>>>>>
> >>>>>>>>- Rex
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>     
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>_______________________________________________
> >>>>>>>pwe3 mailing list
> >>>>>>>pwe3@ietf.org
> >>>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
> >>>>>>>
> >>>>>>>   
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>_______________________________________________
> >>>>>>pwe3 mailing list
> >>>>>>pwe3@ietf.org
> >>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
> >>>>>>
> >>>>>> 
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>          
> >>>>>
> >>>      
> >>>
> >>_______________________________________________
> >>pwe3 mailing list
> >>pwe3@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/pwe3
> >>
> >>    
> >>
> >
> >  
> >
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: Re: PW Status negotiation procedure
Date: Mon, 29 Dec 2003 10:28:16 -0500
Lines: 20
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Cc: "'Shah, Himanshu'" <hshah@ciena.com>,
        "'Rex Emmanuel Fernando'"
	 <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli
	 <srihari@procket.com>,
        Renwei Li <renwei@procket.com>,
        Avneesh Sachdev
	 <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Dec 29 16:52:01 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Luca Martini'" <lmartini@cisco.com>
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



> -----Original Message-----
> From: Luca Martini [mailto:lmartini@cisco.com]
> Sent: Wednesday, December 24, 2003 6:29 PM

[snipped]
> > 
> >- What is meant by "Pseudo Wire Not Forwarding"? When is 
> this error code used instead of "PSN-facing PW receive fault" 
> and/or "PSN-facing PW transmit fault"?
> >  
> >
> Somebody purposefully configures it to be administratively down.
> 

I thought that  "PW administratively down" is normally reflected by releasing PW labels. Is there really a need to keep the PW up in an administrative down state?


[snppied to the end]


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Luca Martini <lmartini@cisco.com>
Subject: Re: Re: PW Status negotiation procedure
Date: Mon, 29 Dec 2003 09:11:52 -0700
Organization: Cisco Systems
Lines: 44
Sender: pwe3-admin@ietf.org
References: <B99995113B318D44BBE87DC50092EDA90C0D564E@nj7460exch006u.ho.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "'Shah, Himanshu'" <hshah@ciena.com>,
        "'Rex Emmanuel Fernando'" <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li <renwei@procket.com>, Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Dec 29 17:17:05 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
To: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
In-Reply-To: <B99995113B318D44BBE87DC50092EDA90C0D564E@nj7460exch006u.ho.lucent.com>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



Busschbach, Peter B (Peter) wrote:

>  
>
>>-----Original Message-----
>>From: Luca Martini [mailto:lmartini@cisco.com]
>>Sent: Wednesday, December 24, 2003 6:29 PM
>>    
>>
>
>[snipped]
>  
>
>>>- What is meant by "Pseudo Wire Not Forwarding"? When is 
>>>      
>>>
>>this error code used instead of "PSN-facing PW receive fault" 
>>and/or "PSN-facing PW transmit fault"?
>>    
>>
>>> 
>>>
>>>      
>>>
>>Somebody purposefully configures it to be administratively down.
>>
>>    
>>
>
>I thought that  "PW administratively down" is normally reflected by releasing PW labels. Is there really a need to keep the PW up in an administrative down state?
>
>
>[snppied to the end]
>  
>

yes. It is usually much more "work" to actually withdraw the label , and 
we thought it necessary to allow an easier mechanism to shut down the 
PW. By sending the status message we avoid having to release labels, 
unprogram hardware , etc.

Luca


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Shah, Himanshu" <hshah@ciena.com>
Subject: RE: Re: PW Status negotiation procedure
Date: Mon, 29 Dec 2003 11:22:05 -0500
Lines: 624
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Cc: "'Rex Emmanuel Fernando'" <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li
	 <renwei@procket.com>,
        Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Dec 29 17:26:14 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Busschbach, Peter B (Peter)'" <busschbach@lucent.com>,
        "'Luca Martini'" <lmartini@cisco.com>
X-Mailer: Internet Mail Service (5.5.2657.72)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Original intent was to relay only "ability/inability to forward 
traffic between AC and PW" as the PW status indication. 
It seems that people wanted additional breakdown (when possible) for
diagnostic purposes.  As we dig deeper, if there is a need to 
further qualify an action per status per PW type, it will complicate
whole PW status handling.

I also think we need clearer rules on PW status handling to
avoid PW status deadlock.

/himanshu

> -----Original Message-----
> From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com]
> Sent: Monday, December 29, 2003 10:23 AM
> To: 'Luca Martini'
> Cc: Shah, Himanshu; 'Rex Emmanuel Fernando'; tob@laurelnetworks.com;
> Srihari Ramachandra Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh;
> pwe3@ietf.org
> Subject: RE: [PWE3] Re: PW Status negotiation procedure
> 
> 
> 
> 
> > -----Original Message-----
> > From: Luca Martini [mailto:lmartini@cisco.com]
> > Sent: Wednesday, December 24, 2003 6:29 PM
> 
> > Busschbach, Peter B (Peter) wrote:
> > 
> > >draft-ietf-pwe3-iana-allocation-02 defines the following PW 
> > status codes.
> > >
> > >0x00000000 - Pseudo Wire forwarding ( clear all failures)
> > >0x00000001 - Pseudo Wire Not Forwarding
> > >0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault
> > >0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault
> > >0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault
> > >0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault
> > >
> > >Could anyone explain what exactly is meant by each of these codes?
> > >
> > >Here are the reasons I am uncertain about the semantics:
> > >
> > >- Should "customer-facing PW" be read as "attachment 
> > circuit"? If not, I don't know what it is meant. From the 
> > perspective of a PE, I would think that the PW is always PSN-facing.
> > >  
> > >
> > Yes,  It would probably make it easier to read if we corected the 
> > definition.  I take that attachment circuit does not mean 
> attachment 
> > interface right ?
> 
> Luca,
> 
> That is a good point. I don't know what was originally 
> intended, but it would make sense to clearly define what 
> fault conditions are covered by these error codes.
> 
> Take, for example, a receive failure on an Attachment 
> Circuit. In most cases such a failure indication should be 
> propagated via failure notifications in the emulated protocol 
> and not via the PW control plane. E.g. if the emulated 
> service is ATM, the PE should translate a receive failure on 
> the Attachment Ciruit to an AIS signal that is forwarded over 
> the Pseudo Wire. There would be no need for a failure 
> indication over the PW control plane.
> 
> I can see two exceptions:
> 
> 1) When port-mode encapsulation is used. I.e. if there is no 
> Native ATM Processing in the PE, the PE is not able to 
> generate AIS signals (after all, it doesn't know which VCs 
> are active). In that case, it would make sense to use the PW 
> control plane to indicate a failure on the Attachment Circuit. 
> 
> 2) When the failure occurs on the interface within the PE 
> between the NSP module and the PW module. In that case, the 
> NSP module is cut off from the PW module and can not be 
> relied on for AIS generation. Hence, the need for a failure 
> indication in the PW control plane so that the egress PE can 
> generate AIS.
> 
> 
> I think the OAM Message Mapping draft is the right place to 
> identify under which conditions a PE should generate each of 
> the PW status codes and how its peer should react. However, 
> until a new version of that draft comes out, I would 
> appreciate it if people could give more examples to 
> illustrate when the PW status codes should be used.
> 
> Peter
> 
> 
> 
> > 
> > >- I assume that "PSN-facing transmit fault" is an indication 
> > from one PE (PE1) to its peer (PE2) that there is a failure 
> > on the PW in the direction from PE1 to PE2. However, if that 
> > failure does indeed exist, how is the status indication  
> > supposed to reach PE2?
> > >  
> > >
> > through the control channel. After all, the MPLS LSP can be 
> > broken , but 
> > IP connectivity can still exist.
> > I cant remember now, but there was some reason why we did 
> not simply 
> > call this "Local PSN tunnel" .
> > we can change this if nobody else objects...
> > 
> > > 
> > >- What is meant by "Pseudo Wire Not Forwarding"? When is 
> > this error code used instead of "PSN-facing PW receive fault" 
> > and/or "PSN-facing PW transmit fault"?
> > >  
> > >
> > Somebody purposefully configures it to be administratively down.
> > 
> > Please keep in mind that these are general status singals, 
> > and not meant 
> > to carry the operational status information that a NOC would need.
> > Luca
> > 
> > >Peter
> > >
> > >  
> > >
> > >>-----Original Message-----
> > >>From: Shah, Himanshu [mailto:hshah@ciena.com]
> > >>Sent: Wednesday, December 24, 2003 7:49 AM
> > >>To: 'Rex Emmanuel Fernando'
> > >>Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
> > >>Ramachandra Sangli;
> > >>Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > >>Subject: RE: [PWE3] Re: PW Status negotiation procedure
> > >>
> > >>
> > >>The changes to PWE3-control draft has to be determined
> > >>by Luca and his co-authors. We can only make recommendations.....
> > >>
> > >>/himanshu
> > >>
> > >>    
> > >>
> > >>>-----Original Message-----
> > >>>From: Rex Emmanuel Fernando [mailto:rex@procket.com]
> > >>>Sent: Wednesday, December 24, 2003 12:25 AM
> > >>>To: Shah, Himanshu
> > >>>Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
> > >>>Ramachandra Sangli;
> > >>>Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > >>>Subject: RE: [PWE3] Re: PW Status negotiation procedure
> > >>>
> > >>>
> > >>>
> > >>>Himanshu,
> > >>>
> > >>>      
> > >>>
> > >>>>The Status TLV is sent in label mapping message 
> > >>>>in "optional parameter" field as a  "capability learning" 
> > >>>>        
> > >>>>
> > >>mechanism.
> > >>    
> > >>
> > >>>>The changes in PW status (or others) is subsequently sent as 
> > >>>>LDP notification messages as per rev1 draft (we did listen 
> > >>>>        
> > >>>>
> > >>>to you :-).
> > >>>      
> > >>>
> > >>>>I still believe that dispatching initial status tlv in optional
> > >>>>parameter field is a better choice than appending to the PW FEC.
> > >>>>Its a suggestion that you may want to consider....
> > >>>>        
> > >>>>
> > >>>As Luca seems to concur below the PW Status TLV has to be a 
> > >>>separate TLV 
> > >>>following the FEC TLV in the label mapping message. Having 
> > >>>said that I 
> > >>>agree with you that the correct way to carry this information 
> > >>>would be in 
> > >>>the optional parameters field in the label mapping message. 
> > >>>Any subsequent 
> > >>>change to the status is conveyed using LDP notification 
> so there is
> > >>>no FEC churn. 
> > >>>
> > >>>If we all agree on this could the authors make necessary 
> changes to
> > >>>the draft so that we (implementors) could make forward progress ?
> > >>>
> > >>>Thanks,
> > >>>
> > >>>- Rex
> > >>>
> > >>>      
> > >>>
> > >>>>Yes, we are going to update the draft to remove status related
> > >>>>stuff (as you have covered it in your draft) and keep IP TLV
> > >>>>and other stuff. So your impression is correct.
> > >>>>
> > >>>>/himanshu
> > >>>>
> > >>>>        
> > >>>>
> > >>>>>-----Original Message-----
> > >>>>>From: Luca Martini [mailto:lmartini@cisco.com]
> > >>>>>Sent: Tuesday, December 23, 2003 4:34 PM
> > >>>>>To: Shah, Himanshu
> > >>>>>Cc: Rex Emmanuel Fernando; tob@laurelnetworks.com; 
> > >>>>>          
> > >>>>>
> > >>>Srihari Ramachandra
> > >>>      
> > >>>
> > >>>>>Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh; 
> pwe3@ietf.org
> > >>>>>Subject: Re: [PWE3] Re: PW Status negotiation procedure
> > >>>>>
> > >>>>>
> > >>>>>Himanshu,
> > >>>>>
> > >>>>>When we dicussed this months ago , I had pointed out that 
> > >>>>>putting this 
> > >>>>>in the optional parameter field , means that the FEC changes 
> > >>>>>every time 
> > >>>>>there is a status change. This would mean a withdraw a, and 
> > >>>>>re-advertisement of the PW FEC.
> > >>>>>It is too late to change anything now, But I was under 
> > >>>>>          
> > >>>>>
> > >>>the impression 
> > >>>      
> > >>>
> > >>>>>that the draft below would be amended to include only the IP 
> > >>>>>TLV , and 
> > >>>>>other VPLS related informantion.
> > >>>>>
> > >>>>>Luca
> > >>>>>
> > >>>>>
> > >>>>>Shah, Himanshu wrote:
> > >>>>>
> > >>>>>          
> > >>>>>
> > >>>>>>In draft-shah-pwe3-control-protocol-extension-01.txt, 
> > >>>>>>we have recommended that this status TLV (or for that
> > >>>>>>matter any additional TLV) should be part of the
> > >>>>>>"optional parameter" field of the Label Mapping message.
> > >>>>>>
> > >>>>>>
> > >>>>>>/himanshu
> > >>>>>>
> > >>>>>>
> > >>>>>>http://www.ietf.org/internet-drafts/draft-shah-pwe3-control-p
> > >>>>>>            
> > >>>>>>
> > >>>>rotocol-extension-01.txt
> > >>>>        
> > >>>>
> > >>>>>> 
> > >>>>>>
> > >>>>>>            
> > >>>>>>
> > >>>>>>>-----Original Message-----
> > >>>>>>>From: Luca Martini [mailto:lmartini@cisco.com]
> > >>>>>>>Sent: Tuesday, December 23, 2003 2:28 PM
> > >>>>>>>To: Rex Emmanuel Fernando
> > >>>>>>>Cc: tob@laurelnetworks.com; Srihari Ramachandra Sangli; 
> > >>>>>>>              
> > >>>>>>>
> > >>>Renwei Li;
> > >>>      
> > >>>
> > >>>>>>>Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > >>>>>>>Subject: [PWE3] Re: PW Status negotiation procedure
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>Rex Emmanuel Fernando wrote:
> > >>>>>>>
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>>Hi, Guys,
> > >>>>>>>>
> > >>>>>>>>It seems
> > >>>>>>>>to me that the text which describes PW Status negotiation 
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>is flawed.
> > >>>>>          
> > >>>>>
> > >>>>>>>>This is what it says:
> > >>>>>>>>
> > >>>>>>>>---
> > >>>>>>>>
> > >>>>>>>> "A PE that supports the PW Status TLV MUST include it in 
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>the initial
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>> label mapping signaling as part of the PW FEC and 
> > >>>>>>>>                
> > >>>>>>>>
> > >>>following the
> > >>>      
> > >>>
> > >>>>>>>> interface parameters field. The PW Status TLV will be 
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>used for the
> > >>>>>          
> > >>>>>
> > >>>>>>>> lifetime of the Pseudowire for PEs that support this TLV.
> > >>>>>>>>
> > >>>>>>>> If the PW Status TLV is not present in the initial 
> > >>>>>>>>                
> > >>>>>>>>
> > >>>PW FEC Message
> > >>>      
> > >>>
> > >>>>>>>> received by a PE, then the PW Status TLV will not be 
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>used and both
> > >>>>>          
> > >>>>>
> > >>>>>>>> PEs of the pseudowire will revert to the label withdraw 
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>procedure for
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>> signaling status changes.
> > >>>>>>>>
> > >>>>>>>> If PW status TLV is sent as part of the initial PW FEC 
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>Message, but
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>> the remote PE corresponding FEC advertisement does not 
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>include a PW
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>> status TLV, or the remote PE does not support the PW 
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>Status TLV then
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>> the PW will revert to the label withdraw method to signal 
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>PW status.
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>> Note that if the PW Status TLV is not supported it will 
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>automatically
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>> be ignored since the LDP ignore bit is set."
> > >>>>>>>>
> > >>>>>>>>----
> > >>>>>>>>
> > >>>>>>>>The text says that the "PW Status TLV" should be part of 
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>the FEC TLV
> > >>>>>          
> > >>>>>
> > >>>>>>>>and following the interface parameters. Note that according 
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>to LDP spec
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>>a FEC TLV does not have sub-tlvs and I don't see a 
> > >>>>>>>>                
> > >>>>>>>>
> > >>>provision for
> > >>>      
> > >>>
> > >>>>>>>>having sub-tlvs within it. All it has is a contiguous array 
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>of different
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>>FEC types. So I am assuming that the PW Status TLV is 
> > >>>>>>>>                
> > >>>>>>>>
> > >>>*NOT* part of
> > >>>      
> > >>>
> > >>>>>>>>the FEC TLV but an additional TLV following the FEC TLV. 
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>Also note that
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>>the text says that old implementations which do not suppor 
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>this would
> > >>>>>          
> > >>>>>
> > >>>>>>>>ignore it - this is possible only if its a separate 
> > >>>>>>>>                
> > >>>>>>>>
> > >>>TLV and is not
> > >>>      
> > >>>
> > >>>>>>>>piggybacked on the FEC TLV. The text has to be corrected to 
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>relfect this. 
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>Yes , I can see there is a problem in the description. 
> > >>>>>>>              
> > >>>>>>>
> > >>>And yes the 
> > >>>      
> > >>>
> > >>>>>>>status TLV is a separate TLV and MUST immediately follow 
> > >>>>>>>              
> > >>>>>>>
> > >>>>>the FEC TLV.
> > >>>>>          
> > >>>>>
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>>The next question I have is, if the PW Status TLV follows 
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>the FEC TLV, to
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>>which FEC does it apply (note that a FEC TLV could have 
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>'n' number of
> > >>>>>          
> > >>>>>
> > >>>>>>>>FECs). Does the PW status apply to all FECs ?
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>not for the PW case. In IP you can have multiple FEC 
> elements 
> > >>>>>>>in the FEC 
> > >>>>>>>( sharing of LSP for multiple IP addresses ), but for the PW 
> > >>>>>>>it's only 
> > >>>>>>>one FEC element per FEC so the status TLV will be only 
> > >>>>>>>              
> > >>>>>>>
> > >>>for the FEC 
> > >>>      
> > >>>
> > >>>>>>>element present.
> > >>>>>>>
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>>Correct me if I am wrong in any of these points.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>you are right on most of them :-)
> > >>>>>>>
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>>Also is there an IANA assigned number for the PW 
> > >>>>>>>>                
> > >>>>>>>>
> > >>>Status TLV type ?
> > >>>      
> > >>>
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>No. Not yet.
> > >>>>>>>
> > >>>>>>>I'll send out a correction for the text above . it really 
> > >>>>>>>meant to say 
> > >>>>>>>"the PW Status TLV should immediately follow the FEC 
> > >>>>>>>              
> > >>>>>>>
> > >>>TLV" as in the 
> > >>>      
> > >>>
> > >>>>>>>picture...
> > >>>>>>>
> > >>>>>>>Luca
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>>>Thanks for your clarification.
> > >>>>>>>>
> > >>>>>>>>- Rex
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>     
> > >>>>>>>>
> > >>>>>>>>                
> > >>>>>>>>
> > >>>>>>>_______________________________________________
> > >>>>>>>pwe3 mailing list
> > >>>>>>>pwe3@ietf.org
> > >>>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
> > >>>>>>>
> > >>>>>>>   
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>>
> > >>>>>>_______________________________________________
> > >>>>>>pwe3 mailing list
> > >>>>>>pwe3@ietf.org
> > >>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
> > >>>>>>
> > >>>>>> 
> > >>>>>>
> > >>>>>>            
> > >>>>>>
> > >>>>>          
> > >>>>>
> > >>>      
> > >>>
> > >>_______________________________________________
> > >>pwe3 mailing list
> > >>pwe3@ietf.org
> > >>https://www1.ietf.org/mailman/listinfo/pwe3
> > >>
> > >>    
> > >>
> > >
> > >  
> > >
> > 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Luca Martini <lmartini@cisco.com>
Subject: Re: Re: PW Status negotiation procedure
Date: Mon, 29 Dec 2003 09:44:40 -0700
Organization: Cisco Systems
Lines: 802
Sender: pwe3-admin@ietf.org
References: <B99995113B318D44BBE87DC50092EDA90C0D564D@nj7460exch006u.ho.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "'Shah, Himanshu'" <hshah@ciena.com>,
        "'Rex Emmanuel Fernando'" <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li <renwei@procket.com>, Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Dec 29 17:53:11 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020
X-Accept-Language: en-us, en
To: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
In-Reply-To: <B99995113B318D44BBE87DC50092EDA90C0D564D@nj7460exch006u.ho.lucent.com>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Peter,

You are correct , however, unlike ATM,  other protocols like ethernet 
etc. lack the ability to propagate the status information.
Also SP like built in SLA down time measurements, which require a status 
code from the remote PE to signal that something went wrong. In this 
case it can be difficult to snoop the data in the PW to glean the status 
of the PW itself.

Luca


Busschbach, Peter B (Peter) wrote:

>  
>
>>-----Original Message-----
>>From: Luca Martini [mailto:lmartini@cisco.com]
>>Sent: Wednesday, December 24, 2003 6:29 PM
>>    
>>
>
>  
>
>>Busschbach, Peter B (Peter) wrote:
>>
>>    
>>
>>>draft-ietf-pwe3-iana-allocation-02 defines the following PW 
>>>      
>>>
>>status codes.
>>    
>>
>>>0x00000000 - Pseudo Wire forwarding ( clear all failures)
>>>0x00000001 - Pseudo Wire Not Forwarding
>>>0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault
>>>0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault
>>>0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault
>>>0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault
>>>
>>>Could anyone explain what exactly is meant by each of these codes?
>>>
>>>Here are the reasons I am uncertain about the semantics:
>>>
>>>- Should "customer-facing PW" be read as "attachment 
>>>      
>>>
>>circuit"? If not, I don't know what it is meant. From the 
>>perspective of a PE, I would think that the PW is always PSN-facing.
>>    
>>
>>> 
>>>
>>>      
>>>
>>Yes,  It would probably make it easier to read if we corected the 
>>definition.  I take that attachment circuit does not mean attachment 
>>interface right ?
>>    
>>
>
>Luca,
>
>That is a good point. I don't know what was originally intended, but it would make sense to clearly define what fault conditions are covered by these error codes.
>
>Take, for example, a receive failure on an Attachment Circuit. In most cases such a failure indication should be propagated via failure notifications in the emulated protocol and not via the PW control plane. E.g. if the emulated service is ATM, the PE should translate a receive failure on the Attachment Ciruit to an AIS signal that is forwarded over the Pseudo Wire. There would be no need for a failure indication over the PW control plane.
>
>I can see two exceptions:
>
>1) When port-mode encapsulation is used. I.e. if there is no Native ATM Processing in the PE, the PE is not able to generate AIS signals (after all, it doesn't know which VCs are active). In that case, it would make sense to use the PW control plane to indicate a failure on the Attachment Circuit. 
>
>2) When the failure occurs on the interface within the PE between the NSP module and the PW module. In that case, the NSP module is cut off from the PW module and can not be relied on for AIS generation. Hence, the need for a failure indication in the PW control plane so that the egress PE can generate AIS.
>
>
>I think the OAM Message Mapping draft is the right place to identify under which conditions a PE should generate each of the PW status codes and how its peer should react. However, until a new version of that draft comes out, I would appreciate it if people could give more examples to illustrate when the PW status codes should be used.
>
>Peter
>
>
>
>  
>
>>>- I assume that "PSN-facing transmit fault" is an indication 
>>>      
>>>
>>from one PE (PE1) to its peer (PE2) that there is a failure 
>>on the PW in the direction from PE1 to PE2. However, if that 
>>failure does indeed exist, how is the status indication  
>>supposed to reach PE2?
>>    
>>
>>> 
>>>
>>>      
>>>
>>through the control channel. After all, the MPLS LSP can be 
>>broken , but 
>>IP connectivity can still exist.
>>I cant remember now, but there was some reason why we did not simply 
>>call this "Local PSN tunnel" .
>>we can change this if nobody else objects...
>>
>>    
>>
>>>- What is meant by "Pseudo Wire Not Forwarding"? When is 
>>>      
>>>
>>this error code used instead of "PSN-facing PW receive fault" 
>>and/or "PSN-facing PW transmit fault"?
>>    
>>
>>> 
>>>
>>>      
>>>
>>Somebody purposefully configures it to be administratively down.
>>
>>Please keep in mind that these are general status singals, 
>>and not meant 
>>to carry the operational status information that a NOC would need.
>>Luca
>>
>>    
>>
>>>Peter
>>>
>>> 
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: Shah, Himanshu [mailto:hshah@ciena.com]
>>>>Sent: Wednesday, December 24, 2003 7:49 AM
>>>>To: 'Rex Emmanuel Fernando'
>>>>Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
>>>>Ramachandra Sangli;
>>>>Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
>>>>Subject: RE: [PWE3] Re: PW Status negotiation procedure
>>>>
>>>>
>>>>The changes to PWE3-control draft has to be determined
>>>>by Luca and his co-authors. We can only make recommendations.....
>>>>
>>>>/himanshu
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>-----Original Message-----
>>>>>From: Rex Emmanuel Fernando [mailto:rex@procket.com]
>>>>>Sent: Wednesday, December 24, 2003 12:25 AM
>>>>>To: Shah, Himanshu
>>>>>Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
>>>>>Ramachandra Sangli;
>>>>>Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
>>>>>Subject: RE: [PWE3] Re: PW Status negotiation procedure
>>>>>
>>>>>
>>>>>
>>>>>Himanshu,
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>The Status TLV is sent in label mapping message 
>>>>>>in "optional parameter" field as a  "capability learning" 
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>mechanism.
>>>>   
>>>>
>>>>        
>>>>
>>>>>>The changes in PW status (or others) is subsequently sent as 
>>>>>>LDP notification messages as per rev1 draft (we did listen 
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>to you :-).
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>I still believe that dispatching initial status tlv in optional
>>>>>>parameter field is a better choice than appending to the PW FEC.
>>>>>>Its a suggestion that you may want to consider....
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>As Luca seems to concur below the PW Status TLV has to be a 
>>>>>separate TLV 
>>>>>following the FEC TLV in the label mapping message. Having 
>>>>>said that I 
>>>>>agree with you that the correct way to carry this information 
>>>>>would be in 
>>>>>the optional parameters field in the label mapping message. 
>>>>>Any subsequent 
>>>>>change to the status is conveyed using LDP notification so there is
>>>>>no FEC churn. 
>>>>>
>>>>>If we all agree on this could the authors make necessary changes to
>>>>>the draft so that we (implementors) could make forward progress ?
>>>>>
>>>>>Thanks,
>>>>>
>>>>>- Rex
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>Yes, we are going to update the draft to remove status related
>>>>>>stuff (as you have covered it in your draft) and keep IP TLV
>>>>>>and other stuff. So your impression is correct.
>>>>>>
>>>>>>/himanshu
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Luca Martini [mailto:lmartini@cisco.com]
>>>>>>>Sent: Tuesday, December 23, 2003 4:34 PM
>>>>>>>To: Shah, Himanshu
>>>>>>>Cc: Rex Emmanuel Fernando; tob@laurelnetworks.com; 
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>Srihari Ramachandra
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>>Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
>>>>>>>Subject: Re: [PWE3] Re: PW Status negotiation procedure
>>>>>>>
>>>>>>>
>>>>>>>Himanshu,
>>>>>>>
>>>>>>>When we dicussed this months ago , I had pointed out that 
>>>>>>>putting this 
>>>>>>>in the optional parameter field , means that the FEC changes 
>>>>>>>every time 
>>>>>>>there is a status change. This would mean a withdraw a, and 
>>>>>>>re-advertisement of the PW FEC.
>>>>>>>It is too late to change anything now, But I was under 
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>the impression 
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>>that the draft below would be amended to include only the IP 
>>>>>>>TLV , and 
>>>>>>>other VPLS related informantion.
>>>>>>>
>>>>>>>Luca
>>>>>>>
>>>>>>>
>>>>>>>Shah, Himanshu wrote:
>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>In draft-shah-pwe3-control-protocol-extension-01.txt, 
>>>>>>>>we have recommended that this status TLV (or for that
>>>>>>>>matter any additional TLV) should be part of the
>>>>>>>>"optional parameter" field of the Label Mapping message.
>>>>>>>>
>>>>>>>>
>>>>>>>>/himanshu
>>>>>>>>
>>>>>>>>
>>>>>>>>http://www.ietf.org/internet-drafts/draft-shah-pwe3-control-p
>>>>>>>>           
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>rotocol-extension-01.txt
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>>           
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: Luca Martini [mailto:lmartini@cisco.com]
>>>>>>>>>Sent: Tuesday, December 23, 2003 2:28 PM
>>>>>>>>>To: Rex Emmanuel Fernando
>>>>>>>>>Cc: tob@laurelnetworks.com; Srihari Ramachandra Sangli; 
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>Renwei Li;
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>>>>Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
>>>>>>>>>Subject: [PWE3] Re: PW Status negotiation procedure
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Rex Emmanuel Fernando wrote:
>>>>>>>>>
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>Hi, Guys,
>>>>>>>>>>
>>>>>>>>>>It seems
>>>>>>>>>>to me that the text which describes PW Status negotiation 
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>is flawed.
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>This is what it says:
>>>>>>>>>>
>>>>>>>>>>---
>>>>>>>>>>
>>>>>>>>>>"A PE that supports the PW Status TLV MUST include it in 
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>the initial
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>label mapping signaling as part of the PW FEC and 
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>following the
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>>>>>interface parameters field. The PW Status TLV will be 
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>used for the
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>lifetime of the Pseudowire for PEs that support this TLV.
>>>>>>>>>>
>>>>>>>>>>If the PW Status TLV is not present in the initial 
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>PW FEC Message
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>>>>>received by a PE, then the PW Status TLV will not be 
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>used and both
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>PEs of the pseudowire will revert to the label withdraw 
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>procedure for
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>signaling status changes.
>>>>>>>>>>
>>>>>>>>>>If PW status TLV is sent as part of the initial PW FEC 
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>Message, but
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>the remote PE corresponding FEC advertisement does not 
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>include a PW
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>status TLV, or the remote PE does not support the PW 
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>Status TLV then
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>the PW will revert to the label withdraw method to signal 
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>PW status.
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>Note that if the PW Status TLV is not supported it will 
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>automatically
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>be ignored since the LDP ignore bit is set."
>>>>>>>>>>
>>>>>>>>>>----
>>>>>>>>>>
>>>>>>>>>>The text says that the "PW Status TLV" should be part of 
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>the FEC TLV
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>and following the interface parameters. Note that according 
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>to LDP spec
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>a FEC TLV does not have sub-tlvs and I don't see a 
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>provision for
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>>>>>having sub-tlvs within it. All it has is a contiguous array 
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>of different
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>FEC types. So I am assuming that the PW Status TLV is 
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>*NOT* part of
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>>>>>the FEC TLV but an additional TLV following the FEC TLV. 
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>Also note that
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>the text says that old implementations which do not suppor 
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>this would
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>ignore it - this is possible only if its a separate 
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>TLV and is not
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>>>>>piggybacked on the FEC TLV. The text has to be corrected to 
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>relfect this. 
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>Yes , I can see there is a problem in the description. 
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>And yes the 
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>>>>status TLV is a separate TLV and MUST immediately follow 
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>the FEC TLV.
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>The next question I have is, if the PW Status TLV follows 
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>the FEC TLV, to
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>which FEC does it apply (note that a FEC TLV could have 
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>'n' number of
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>FECs). Does the PW status apply to all FECs ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>not for the PW case. In IP you can have multiple FEC elements 
>>>>>>>>>in the FEC 
>>>>>>>>>( sharing of LSP for multiple IP addresses ), but for the PW 
>>>>>>>>>it's only 
>>>>>>>>>one FEC element per FEC so the status TLV will be only 
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>for the FEC 
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>>>>element present.
>>>>>>>>>
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>Correct me if I am wrong in any of these points.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>you are right on most of them :-)
>>>>>>>>>
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>Also is there an IANA assigned number for the PW 
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>Status TLV type ?
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>No. Not yet.
>>>>>>>>>
>>>>>>>>>I'll send out a correction for the text above . it really 
>>>>>>>>>meant to say 
>>>>>>>>>"the PW Status TLV should immediately follow the FEC 
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>TLV" as in the 
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>>>>picture...
>>>>>>>>>
>>>>>>>>>Luca
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>Thanks for your clarification.
>>>>>>>>>>
>>>>>>>>>>- Rex
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>_______________________________________________
>>>>>>>>>pwe3 mailing list
>>>>>>>>>pwe3@ietf.org
>>>>>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
>>>>>>>>>
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>_______________________________________________
>>>>>>>>pwe3 mailing list
>>>>>>>>pwe3@ietf.org
>>>>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>           
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>_______________________________________________
>>>>pwe3 mailing list
>>>>pwe3@ietf.org
>>>>https://www1.ietf.org/mailman/listinfo/pwe3
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>
>  
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: Re: PW Status negotiation procedure
Date: Mon, 29 Dec 2003 11:50:23 -0500
Lines: 664
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Cc: "'Rex Emmanuel Fernando'" <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li
	 <renwei@procket.com>,
        Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Dec 29 18:01:31 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Shah, Himanshu'" <hshah@ciena.com>,
        "Busschbach, Peter B (Peter)"
	 <busschbach@lucent.com>,
        "'Luca Martini'" <lmartini@cisco.com>
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



> -----Original Message-----
> From: Shah, Himanshu [mailto:hshah@ciena.com]
> Sent: Monday, December 29, 2003 11:22 AM
> To: 'Busschbach, Peter B (Peter)'; 'Luca Martini'
> Cc: 'Rex Emmanuel Fernando'; tob@laurelnetworks.com; Srihari 
> Ramachandra
> Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> Subject: RE: [PWE3] Re: PW Status negotiation procedure
> 
> 
> Original intent was to relay only "ability/inability to forward 
> traffic between AC and PW" as the PW status indication. 
> It seems that people wanted additional breakdown (when possible) for
> diagnostic purposes.  As we dig deeper, if there is a need to 
> further qualify an action per status per PW type, it will complicate
> whole PW status handling.

Himanshu,

I am not entirely sure what you are arguing for. Are you saying that we should keep the PW status indication as simple as possible and not use the additional breakdown or are you saying that we shouldn't define consequent actions?

My personal view is:

- We should limit the use of PW status indication to very specific cases. There are other tools to provide additional diagnostics when necessary and it doesn't make sense to duplicate that functionality in PW status indications.

- We need to define consequent actions. When one PE sends a PW status indication to another PE, the receiving PE should perform some action, otherwise you might as well not send the message. It has to be clear what that action is. In many cases, that action will be the generation of a forward and/or backward Failure Indication in the emulated protocol. 

Peter

> 
> I also think we need clearer rules on PW status handling to
> avoid PW status deadlock.
> 
> /himanshu
> 
> > -----Original Message-----
> > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com]
> > Sent: Monday, December 29, 2003 10:23 AM
> > To: 'Luca Martini'
> > Cc: Shah, Himanshu; 'Rex Emmanuel Fernando'; tob@laurelnetworks.com;
> > Srihari Ramachandra Sangli; Renwei Li; Avneesh Sachdev; 
> Rajesh Parikh;
> > pwe3@ietf.org
> > Subject: RE: [PWE3] Re: PW Status negotiation procedure
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Luca Martini [mailto:lmartini@cisco.com]
> > > Sent: Wednesday, December 24, 2003 6:29 PM
> > 
> > > Busschbach, Peter B (Peter) wrote:
> > > 
> > > >draft-ietf-pwe3-iana-allocation-02 defines the following PW 
> > > status codes.
> > > >
> > > >0x00000000 - Pseudo Wire forwarding ( clear all failures)
> > > >0x00000001 - Pseudo Wire Not Forwarding
> > > >0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault
> > > >0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault
> > > >0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault
> > > >0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault
> > > >
> > > >Could anyone explain what exactly is meant by each of 
> these codes?
> > > >
> > > >Here are the reasons I am uncertain about the semantics:
> > > >
> > > >- Should "customer-facing PW" be read as "attachment 
> > > circuit"? If not, I don't know what it is meant. From the 
> > > perspective of a PE, I would think that the PW is always 
> PSN-facing.
> > > >  
> > > >
> > > Yes,  It would probably make it easier to read if we corected the 
> > > definition.  I take that attachment circuit does not mean 
> > attachment 
> > > interface right ?
> > 
> > Luca,
> > 
> > That is a good point. I don't know what was originally 
> > intended, but it would make sense to clearly define what 
> > fault conditions are covered by these error codes.
> > 
> > Take, for example, a receive failure on an Attachment 
> > Circuit. In most cases such a failure indication should be 
> > propagated via failure notifications in the emulated protocol 
> > and not via the PW control plane. E.g. if the emulated 
> > service is ATM, the PE should translate a receive failure on 
> > the Attachment Ciruit to an AIS signal that is forwarded over 
> > the Pseudo Wire. There would be no need for a failure 
> > indication over the PW control plane.
> > 
> > I can see two exceptions:
> > 
> > 1) When port-mode encapsulation is used. I.e. if there is no 
> > Native ATM Processing in the PE, the PE is not able to 
> > generate AIS signals (after all, it doesn't know which VCs 
> > are active). In that case, it would make sense to use the PW 
> > control plane to indicate a failure on the Attachment Circuit. 
> > 
> > 2) When the failure occurs on the interface within the PE 
> > between the NSP module and the PW module. In that case, the 
> > NSP module is cut off from the PW module and can not be 
> > relied on for AIS generation. Hence, the need for a failure 
> > indication in the PW control plane so that the egress PE can 
> > generate AIS.
> > 
> > 
> > I think the OAM Message Mapping draft is the right place to 
> > identify under which conditions a PE should generate each of 
> > the PW status codes and how its peer should react. However, 
> > until a new version of that draft comes out, I would 
> > appreciate it if people could give more examples to 
> > illustrate when the PW status codes should be used.
> > 
> > Peter
> > 
> > 
> > 
> > > 
> > > >- I assume that "PSN-facing transmit fault" is an indication 
> > > from one PE (PE1) to its peer (PE2) that there is a failure 
> > > on the PW in the direction from PE1 to PE2. However, if that 
> > > failure does indeed exist, how is the status indication  
> > > supposed to reach PE2?
> > > >  
> > > >
> > > through the control channel. After all, the MPLS LSP can be 
> > > broken , but 
> > > IP connectivity can still exist.
> > > I cant remember now, but there was some reason why we did 
> > not simply 
> > > call this "Local PSN tunnel" .
> > > we can change this if nobody else objects...
> > > 
> > > > 
> > > >- What is meant by "Pseudo Wire Not Forwarding"? When is 
> > > this error code used instead of "PSN-facing PW receive fault" 
> > > and/or "PSN-facing PW transmit fault"?
> > > >  
> > > >
> > > Somebody purposefully configures it to be administratively down.
> > > 
> > > Please keep in mind that these are general status singals, 
> > > and not meant 
> > > to carry the operational status information that a NOC would need.
> > > Luca
> > > 
> > > >Peter
> > > >
> > > >  
> > > >
> > > >>-----Original Message-----
> > > >>From: Shah, Himanshu [mailto:hshah@ciena.com]
> > > >>Sent: Wednesday, December 24, 2003 7:49 AM
> > > >>To: 'Rex Emmanuel Fernando'
> > > >>Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
> > > >>Ramachandra Sangli;
> > > >>Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > > >>Subject: RE: [PWE3] Re: PW Status negotiation procedure
> > > >>
> > > >>
> > > >>The changes to PWE3-control draft has to be determined
> > > >>by Luca and his co-authors. We can only make 
> recommendations.....
> > > >>
> > > >>/himanshu
> > > >>
> > > >>    
> > > >>
> > > >>>-----Original Message-----
> > > >>>From: Rex Emmanuel Fernando [mailto:rex@procket.com]
> > > >>>Sent: Wednesday, December 24, 2003 12:25 AM
> > > >>>To: Shah, Himanshu
> > > >>>Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
> > > >>>Ramachandra Sangli;
> > > >>>Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > > >>>Subject: RE: [PWE3] Re: PW Status negotiation procedure
> > > >>>
> > > >>>
> > > >>>
> > > >>>Himanshu,
> > > >>>
> > > >>>      
> > > >>>
> > > >>>>The Status TLV is sent in label mapping message 
> > > >>>>in "optional parameter" field as a  "capability learning" 
> > > >>>>        
> > > >>>>
> > > >>mechanism.
> > > >>    
> > > >>
> > > >>>>The changes in PW status (or others) is subsequently sent as 
> > > >>>>LDP notification messages as per rev1 draft (we did listen 
> > > >>>>        
> > > >>>>
> > > >>>to you :-).
> > > >>>      
> > > >>>
> > > >>>>I still believe that dispatching initial status tlv 
> in optional
> > > >>>>parameter field is a better choice than appending to 
> the PW FEC.
> > > >>>>Its a suggestion that you may want to consider....
> > > >>>>        
> > > >>>>
> > > >>>As Luca seems to concur below the PW Status TLV has to be a 
> > > >>>separate TLV 
> > > >>>following the FEC TLV in the label mapping message. Having 
> > > >>>said that I 
> > > >>>agree with you that the correct way to carry this information 
> > > >>>would be in 
> > > >>>the optional parameters field in the label mapping message. 
> > > >>>Any subsequent 
> > > >>>change to the status is conveyed using LDP notification 
> > so there is
> > > >>>no FEC churn. 
> > > >>>
> > > >>>If we all agree on this could the authors make necessary 
> > changes to
> > > >>>the draft so that we (implementors) could make forward 
> progress ?
> > > >>>
> > > >>>Thanks,
> > > >>>
> > > >>>- Rex
> > > >>>
> > > >>>      
> > > >>>
> > > >>>>Yes, we are going to update the draft to remove status related
> > > >>>>stuff (as you have covered it in your draft) and keep IP TLV
> > > >>>>and other stuff. So your impression is correct.
> > > >>>>
> > > >>>>/himanshu
> > > >>>>
> > > >>>>        
> > > >>>>
> > > >>>>>-----Original Message-----
> > > >>>>>From: Luca Martini [mailto:lmartini@cisco.com]
> > > >>>>>Sent: Tuesday, December 23, 2003 4:34 PM
> > > >>>>>To: Shah, Himanshu
> > > >>>>>Cc: Rex Emmanuel Fernando; tob@laurelnetworks.com; 
> > > >>>>>          
> > > >>>>>
> > > >>>Srihari Ramachandra
> > > >>>      
> > > >>>
> > > >>>>>Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh; 
> > pwe3@ietf.org
> > > >>>>>Subject: Re: [PWE3] Re: PW Status negotiation procedure
> > > >>>>>
> > > >>>>>
> > > >>>>>Himanshu,
> > > >>>>>
> > > >>>>>When we dicussed this months ago , I had pointed out that 
> > > >>>>>putting this 
> > > >>>>>in the optional parameter field , means that the FEC changes 
> > > >>>>>every time 
> > > >>>>>there is a status change. This would mean a withdraw a, and 
> > > >>>>>re-advertisement of the PW FEC.
> > > >>>>>It is too late to change anything now, But I was under 
> > > >>>>>          
> > > >>>>>
> > > >>>the impression 
> > > >>>      
> > > >>>
> > > >>>>>that the draft below would be amended to include only the IP 
> > > >>>>>TLV , and 
> > > >>>>>other VPLS related informantion.
> > > >>>>>
> > > >>>>>Luca
> > > >>>>>
> > > >>>>>
> > > >>>>>Shah, Himanshu wrote:
> > > >>>>>
> > > >>>>>          
> > > >>>>>
> > > >>>>>>In draft-shah-pwe3-control-protocol-extension-01.txt, 
> > > >>>>>>we have recommended that this status TLV (or for that
> > > >>>>>>matter any additional TLV) should be part of the
> > > >>>>>>"optional parameter" field of the Label Mapping message.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>/himanshu
> > > >>>>>>
> > > >>>>>>
> > > 
> >>>>>>http://www.ietf.org/internet-drafts/draft-shah-pwe3-control-p
> > > >>>>>>            
> > > >>>>>>
> > > >>>>rotocol-extension-01.txt
> > > >>>>        
> > > >>>>
> > > >>>>>> 
> > > >>>>>>
> > > >>>>>>            
> > > >>>>>>
> > > >>>>>>>-----Original Message-----
> > > >>>>>>>From: Luca Martini [mailto:lmartini@cisco.com]
> > > >>>>>>>Sent: Tuesday, December 23, 2003 2:28 PM
> > > >>>>>>>To: Rex Emmanuel Fernando
> > > >>>>>>>Cc: tob@laurelnetworks.com; Srihari Ramachandra Sangli; 
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>Renwei Li;
> > > >>>      
> > > >>>
> > > >>>>>>>Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > > >>>>>>>Subject: [PWE3] Re: PW Status negotiation procedure
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>Rex Emmanuel Fernando wrote:
> > > >>>>>>>
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>>Hi, Guys,
> > > >>>>>>>>
> > > >>>>>>>>It seems
> > > >>>>>>>>to me that the text which describes PW Status negotiation 
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>is flawed.
> > > >>>>>          
> > > >>>>>
> > > >>>>>>>>This is what it says:
> > > >>>>>>>>
> > > >>>>>>>>---
> > > >>>>>>>>
> > > >>>>>>>> "A PE that supports the PW Status TLV MUST include it in 
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>the initial
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>> label mapping signaling as part of the PW FEC and 
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>following the
> > > >>>      
> > > >>>
> > > >>>>>>>> interface parameters field. The PW Status TLV will be 
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>used for the
> > > >>>>>          
> > > >>>>>
> > > >>>>>>>> lifetime of the Pseudowire for PEs that support this TLV.
> > > >>>>>>>>
> > > >>>>>>>> If the PW Status TLV is not present in the initial 
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>PW FEC Message
> > > >>>      
> > > >>>
> > > >>>>>>>> received by a PE, then the PW Status TLV will not be 
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>used and both
> > > >>>>>          
> > > >>>>>
> > > >>>>>>>> PEs of the pseudowire will revert to the label withdraw 
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>procedure for
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>> signaling status changes.
> > > >>>>>>>>
> > > >>>>>>>> If PW status TLV is sent as part of the initial PW FEC 
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>Message, but
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>> the remote PE corresponding FEC advertisement does not 
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>include a PW
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>> status TLV, or the remote PE does not support the PW 
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>Status TLV then
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>> the PW will revert to the label withdraw method 
> to signal 
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>PW status.
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>> Note that if the PW Status TLV is not supported it will 
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>automatically
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>> be ignored since the LDP ignore bit is set."
> > > >>>>>>>>
> > > >>>>>>>>----
> > > >>>>>>>>
> > > >>>>>>>>The text says that the "PW Status TLV" should be part of 
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>the FEC TLV
> > > >>>>>          
> > > >>>>>
> > > >>>>>>>>and following the interface parameters. Note that 
> according 
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>to LDP spec
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>>a FEC TLV does not have sub-tlvs and I don't see a 
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>provision for
> > > >>>      
> > > >>>
> > > >>>>>>>>having sub-tlvs within it. All it has is a 
> contiguous array 
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>of different
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>>FEC types. So I am assuming that the PW Status TLV is 
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>*NOT* part of
> > > >>>      
> > > >>>
> > > >>>>>>>>the FEC TLV but an additional TLV following the FEC TLV. 
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>Also note that
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>>the text says that old implementations which do 
> not suppor 
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>this would
> > > >>>>>          
> > > >>>>>
> > > >>>>>>>>ignore it - this is possible only if its a separate 
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>TLV and is not
> > > >>>      
> > > >>>
> > > >>>>>>>>piggybacked on the FEC TLV. The text has to be 
> corrected to 
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>relfect this. 
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>Yes , I can see there is a problem in the description. 
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>And yes the 
> > > >>>      
> > > >>>
> > > >>>>>>>status TLV is a separate TLV and MUST immediately follow 
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>the FEC TLV.
> > > >>>>>          
> > > >>>>>
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>>The next question I have is, if the PW Status TLV follows 
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>the FEC TLV, to
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>>which FEC does it apply (note that a FEC TLV could have 
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>'n' number of
> > > >>>>>          
> > > >>>>>
> > > >>>>>>>>FECs). Does the PW status apply to all FECs ?
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>not for the PW case. In IP you can have multiple FEC 
> > elements 
> > > >>>>>>>in the FEC 
> > > >>>>>>>( sharing of LSP for multiple IP addresses ), but 
> for the PW 
> > > >>>>>>>it's only 
> > > >>>>>>>one FEC element per FEC so the status TLV will be only 
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>for the FEC 
> > > >>>      
> > > >>>
> > > >>>>>>>element present.
> > > >>>>>>>
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>>Correct me if I am wrong in any of these points.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>you are right on most of them :-)
> > > >>>>>>>
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>>Also is there an IANA assigned number for the PW 
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>Status TLV type ?
> > > >>>      
> > > >>>
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>No. Not yet.
> > > >>>>>>>
> > > >>>>>>>I'll send out a correction for the text above . it really 
> > > >>>>>>>meant to say 
> > > >>>>>>>"the PW Status TLV should immediately follow the FEC 
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>TLV" as in the 
> > > >>>      
> > > >>>
> > > >>>>>>>picture...
> > > >>>>>>>
> > > >>>>>>>Luca
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>>>Thanks for your clarification.
> > > >>>>>>>>
> > > >>>>>>>>- Rex
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>     
> > > >>>>>>>>
> > > >>>>>>>>                
> > > >>>>>>>>
> > > >>>>>>>_______________________________________________
> > > >>>>>>>pwe3 mailing list
> > > >>>>>>>pwe3@ietf.org
> > > >>>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
> > > >>>>>>>
> > > >>>>>>>   
> > > >>>>>>>
> > > >>>>>>>              
> > > >>>>>>>
> > > >>>>>>_______________________________________________
> > > >>>>>>pwe3 mailing list
> > > >>>>>>pwe3@ietf.org
> > > >>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
> > > >>>>>>
> > > >>>>>> 
> > > >>>>>>
> > > >>>>>>            
> > > >>>>>>
> > > >>>>>          
> > > >>>>>
> > > >>>      
> > > >>>
> > > >>_______________________________________________
> > > >>pwe3 mailing list
> > > >>pwe3@ietf.org
> > > >>https://www1.ietf.org/mailman/listinfo/pwe3
> > > >>
> > > >>    
> > > >>
> > > >
> > > >  
> > > >
> > > 
> > 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: Re: PW Status negotiation procedure
Date: Mon, 29 Dec 2003 12:03:08 -0500
Lines: 21
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Cc: "'Shah, Himanshu'" <hshah@ciena.com>,
        "'Rex Emmanuel Fernando'"
	 <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli
	 <srihari@procket.com>,
        Renwei Li <renwei@procket.com>,
        Avneesh Sachdev
	 <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Dec 29 18:07:06 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Luca Martini'" <lmartini@cisco.com>
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O


Luca> You are correct , however, unlike ATM,  other protocols like ethernet 
Luca> etc. lack the ability to propagate the status information.

But if the emulated protocol lacks the ability to propagate status information, what is the egress PE supposed to do?

To make sure that we are talking about the same thing:
Let's assume we have Attachment Circuit 1 connected to PE1, which is connected via a PW to PE2, which supports AC2.

My point was: if AC1 goes down, the NSP functionality in PE1 should generate Forward and Backward Defect indications. There is no need for a PW status indication. Your point is, if I am not mistaken, that there is a need for a status indication since the emulated prorocol may not have FDI and BDI defined.

So the question is: what good does it do to inform PE2 that AC1 is down, if PE2 is not able to propagate the failure indication over AC2 for lack of FDI?

Luca> Also SP like built in SLA down time measurements, which 
Luca> require a status 
Luca> code from the remote PE to signal that something went wrong. In this 
Luca> case it can be difficult to snoop the data in the PW to glean 
Luca> the status 
Luca> of the PW itself.

I don't understand this. If PE1 detects that there is a failure, why can't it send an alarm to the SP's fault management system? Are you assuming that the SP monitors PE2, but not PE1?


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Shah, Himanshu" <hshah@ciena.com>
Subject: RE: Re: PW Status negotiation procedure
Date: Mon, 29 Dec 2003 12:20:36 -0500
Lines: 723
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Cc: "'Rex Emmanuel Fernando'" <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li
	 <renwei@procket.com>,
        Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Dec 29 18:25:14 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Busschbach, Peter B (Peter)'" <busschbach@lucent.com>,
        "'Luca Martini'" <lmartini@cisco.com>
X-Mailer: Internet Mail Service (5.5.2657.72)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

comments below.

> -----Original Message-----
> From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com]
> Sent: Monday, December 29, 2003 11:50 AM
> To: Shah, Himanshu; Busschbach, Peter B (Peter); 'Luca Martini'
> Cc: 'Rex Emmanuel Fernando'; tob@laurelnetworks.com; Srihari 
> Ramachandra
> Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> Subject: RE: [PWE3] Re: PW Status negotiation procedure
> 
> 
> 
> 
> > -----Original Message-----
> > From: Shah, Himanshu [mailto:hshah@ciena.com]
> > Sent: Monday, December 29, 2003 11:22 AM
> > To: 'Busschbach, Peter B (Peter)'; 'Luca Martini'
> > Cc: 'Rex Emmanuel Fernando'; tob@laurelnetworks.com; Srihari 
> > Ramachandra
> > Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > Subject: RE: [PWE3] Re: PW Status negotiation procedure
> > 
> > 
> > Original intent was to relay only "ability/inability to forward 
> > traffic between AC and PW" as the PW status indication. 
> > It seems that people wanted additional breakdown (when possible) for
> > diagnostic purposes.  As we dig deeper, if there is a need to 
> > further qualify an action per status per PW type, it will complicate
> > whole PW status handling.
> 
> Himanshu,
> 
> I am not entirely sure what you are arguing for. Are you 
> saying that we should keep the PW status indication as simple 
> as possible and not use the additional breakdown or are you 
> saying that we shouldn't define consequent actions?


Keep status indications simple.  So if the rule is that when forwding
capability is compromised, PW status is generated irrespective
of whether it is ATM, FRL, ETH, RX down/TX down, RX up but TX is down,
or whatever. Similarly when PW status is received, PE performs
appropriate actions to AC based on AC type. 

Whatever is done for OAM interworking (between AC&PW at 
data plane level) is independent of PW status. But there needs
clearer action plans so that PW status ping pong does not
happen leading to PW status deadlock when each PE thinks
other is responsible for clearing the PW status.

/himanshu
 

> 
> My personal view is:
> 
> - We should limit the use of PW status indication to very 
> specific cases. There are other tools to provide additional 
> diagnostics when necessary and it doesn't make sense to 
> duplicate that functionality in PW status indications.
> 
> - We need to define consequent actions. When one PE sends a 
> PW status indication to another PE, the receiving PE should 
> perform some action, otherwise you might as well not send the 
> message. It has to be clear what that action is. In many 
> cases, that action will be the generation of a forward and/or 
> backward Failure Indication in the emulated protocol. 
> 
> Peter
> 
> > 
> > I also think we need clearer rules on PW status handling to
> > avoid PW status deadlock.
> > 
> > /himanshu
> > 
> > > -----Original Message-----
> > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com]
> > > Sent: Monday, December 29, 2003 10:23 AM
> > > To: 'Luca Martini'
> > > Cc: Shah, Himanshu; 'Rex Emmanuel Fernando'; 
> tob@laurelnetworks.com;
> > > Srihari Ramachandra Sangli; Renwei Li; Avneesh Sachdev; 
> > Rajesh Parikh;
> > > pwe3@ietf.org
> > > Subject: RE: [PWE3] Re: PW Status negotiation procedure
> > > 
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Luca Martini [mailto:lmartini@cisco.com]
> > > > Sent: Wednesday, December 24, 2003 6:29 PM
> > > 
> > > > Busschbach, Peter B (Peter) wrote:
> > > > 
> > > > >draft-ietf-pwe3-iana-allocation-02 defines the following PW 
> > > > status codes.
> > > > >
> > > > >0x00000000 - Pseudo Wire forwarding ( clear all failures)
> > > > >0x00000001 - Pseudo Wire Not Forwarding
> > > > >0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault
> > > > >0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault
> > > > >0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault
> > > > >0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault
> > > > >
> > > > >Could anyone explain what exactly is meant by each of 
> > these codes?
> > > > >
> > > > >Here are the reasons I am uncertain about the semantics:
> > > > >
> > > > >- Should "customer-facing PW" be read as "attachment 
> > > > circuit"? If not, I don't know what it is meant. From the 
> > > > perspective of a PE, I would think that the PW is always 
> > PSN-facing.
> > > > >  
> > > > >
> > > > Yes,  It would probably make it easier to read if we 
> corected the 
> > > > definition.  I take that attachment circuit does not mean 
> > > attachment 
> > > > interface right ?
> > > 
> > > Luca,
> > > 
> > > That is a good point. I don't know what was originally 
> > > intended, but it would make sense to clearly define what 
> > > fault conditions are covered by these error codes.
> > > 
> > > Take, for example, a receive failure on an Attachment 
> > > Circuit. In most cases such a failure indication should be 
> > > propagated via failure notifications in the emulated protocol 
> > > and not via the PW control plane. E.g. if the emulated 
> > > service is ATM, the PE should translate a receive failure on 
> > > the Attachment Ciruit to an AIS signal that is forwarded over 
> > > the Pseudo Wire. There would be no need for a failure 
> > > indication over the PW control plane.
> > > 
> > > I can see two exceptions:
> > > 
> > > 1) When port-mode encapsulation is used. I.e. if there is no 
> > > Native ATM Processing in the PE, the PE is not able to 
> > > generate AIS signals (after all, it doesn't know which VCs 
> > > are active). In that case, it would make sense to use the PW 
> > > control plane to indicate a failure on the Attachment Circuit. 
> > > 
> > > 2) When the failure occurs on the interface within the PE 
> > > between the NSP module and the PW module. In that case, the 
> > > NSP module is cut off from the PW module and can not be 
> > > relied on for AIS generation. Hence, the need for a failure 
> > > indication in the PW control plane so that the egress PE can 
> > > generate AIS.
> > > 
> > > 
> > > I think the OAM Message Mapping draft is the right place to 
> > > identify under which conditions a PE should generate each of 
> > > the PW status codes and how its peer should react. However, 
> > > until a new version of that draft comes out, I would 
> > > appreciate it if people could give more examples to 
> > > illustrate when the PW status codes should be used.
> > > 
> > > Peter
> > > 
> > > 
> > > 
> > > > 
> > > > >- I assume that "PSN-facing transmit fault" is an indication 
> > > > from one PE (PE1) to its peer (PE2) that there is a failure 
> > > > on the PW in the direction from PE1 to PE2. However, if that 
> > > > failure does indeed exist, how is the status indication  
> > > > supposed to reach PE2?
> > > > >  
> > > > >
> > > > through the control channel. After all, the MPLS LSP can be 
> > > > broken , but 
> > > > IP connectivity can still exist.
> > > > I cant remember now, but there was some reason why we did 
> > > not simply 
> > > > call this "Local PSN tunnel" .
> > > > we can change this if nobody else objects...
> > > > 
> > > > > 
> > > > >- What is meant by "Pseudo Wire Not Forwarding"? When is 
> > > > this error code used instead of "PSN-facing PW receive fault" 
> > > > and/or "PSN-facing PW transmit fault"?
> > > > >  
> > > > >
> > > > Somebody purposefully configures it to be administratively down.
> > > > 
> > > > Please keep in mind that these are general status singals, 
> > > > and not meant 
> > > > to carry the operational status information that a NOC 
> would need.
> > > > Luca
> > > > 
> > > > >Peter
> > > > >
> > > > >  
> > > > >
> > > > >>-----Original Message-----
> > > > >>From: Shah, Himanshu [mailto:hshah@ciena.com]
> > > > >>Sent: Wednesday, December 24, 2003 7:49 AM
> > > > >>To: 'Rex Emmanuel Fernando'
> > > > >>Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
> > > > >>Ramachandra Sangli;
> > > > >>Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > > > >>Subject: RE: [PWE3] Re: PW Status negotiation procedure
> > > > >>
> > > > >>
> > > > >>The changes to PWE3-control draft has to be determined
> > > > >>by Luca and his co-authors. We can only make 
> > recommendations.....
> > > > >>
> > > > >>/himanshu
> > > > >>
> > > > >>    
> > > > >>
> > > > >>>-----Original Message-----
> > > > >>>From: Rex Emmanuel Fernando [mailto:rex@procket.com]
> > > > >>>Sent: Wednesday, December 24, 2003 12:25 AM
> > > > >>>To: Shah, Himanshu
> > > > >>>Cc: 'Luca Martini'; tob@laurelnetworks.com; Srihari 
> > > > >>>Ramachandra Sangli;
> > > > >>>Renwei Li; Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > > > >>>Subject: RE: [PWE3] Re: PW Status negotiation procedure
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>Himanshu,
> > > > >>>
> > > > >>>      
> > > > >>>
> > > > >>>>The Status TLV is sent in label mapping message 
> > > > >>>>in "optional parameter" field as a  "capability learning" 
> > > > >>>>        
> > > > >>>>
> > > > >>mechanism.
> > > > >>    
> > > > >>
> > > > >>>>The changes in PW status (or others) is 
> subsequently sent as 
> > > > >>>>LDP notification messages as per rev1 draft (we did listen 
> > > > >>>>        
> > > > >>>>
> > > > >>>to you :-).
> > > > >>>      
> > > > >>>
> > > > >>>>I still believe that dispatching initial status tlv 
> > in optional
> > > > >>>>parameter field is a better choice than appending to 
> > the PW FEC.
> > > > >>>>Its a suggestion that you may want to consider....
> > > > >>>>        
> > > > >>>>
> > > > >>>As Luca seems to concur below the PW Status TLV has to be a 
> > > > >>>separate TLV 
> > > > >>>following the FEC TLV in the label mapping message. Having 
> > > > >>>said that I 
> > > > >>>agree with you that the correct way to carry this 
> information 
> > > > >>>would be in 
> > > > >>>the optional parameters field in the label mapping message. 
> > > > >>>Any subsequent 
> > > > >>>change to the status is conveyed using LDP notification 
> > > so there is
> > > > >>>no FEC churn. 
> > > > >>>
> > > > >>>If we all agree on this could the authors make necessary 
> > > changes to
> > > > >>>the draft so that we (implementors) could make forward 
> > progress ?
> > > > >>>
> > > > >>>Thanks,
> > > > >>>
> > > > >>>- Rex
> > > > >>>
> > > > >>>      
> > > > >>>
> > > > >>>>Yes, we are going to update the draft to remove 
> status related
> > > > >>>>stuff (as you have covered it in your draft) and keep IP TLV
> > > > >>>>and other stuff. So your impression is correct.
> > > > >>>>
> > > > >>>>/himanshu
> > > > >>>>
> > > > >>>>        
> > > > >>>>
> > > > >>>>>-----Original Message-----
> > > > >>>>>From: Luca Martini [mailto:lmartini@cisco.com]
> > > > >>>>>Sent: Tuesday, December 23, 2003 4:34 PM
> > > > >>>>>To: Shah, Himanshu
> > > > >>>>>Cc: Rex Emmanuel Fernando; tob@laurelnetworks.com; 
> > > > >>>>>          
> > > > >>>>>
> > > > >>>Srihari Ramachandra
> > > > >>>      
> > > > >>>
> > > > >>>>>Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh; 
> > > pwe3@ietf.org
> > > > >>>>>Subject: Re: [PWE3] Re: PW Status negotiation procedure
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>Himanshu,
> > > > >>>>>
> > > > >>>>>When we dicussed this months ago , I had pointed out that 
> > > > >>>>>putting this 
> > > > >>>>>in the optional parameter field , means that the 
> FEC changes 
> > > > >>>>>every time 
> > > > >>>>>there is a status change. This would mean a 
> withdraw a, and 
> > > > >>>>>re-advertisement of the PW FEC.
> > > > >>>>>It is too late to change anything now, But I was under 
> > > > >>>>>          
> > > > >>>>>
> > > > >>>the impression 
> > > > >>>      
> > > > >>>
> > > > >>>>>that the draft below would be amended to include 
> only the IP 
> > > > >>>>>TLV , and 
> > > > >>>>>other VPLS related informantion.
> > > > >>>>>
> > > > >>>>>Luca
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>Shah, Himanshu wrote:
> > > > >>>>>
> > > > >>>>>          
> > > > >>>>>
> > > > >>>>>>In draft-shah-pwe3-control-protocol-extension-01.txt, 
> > > > >>>>>>we have recommended that this status TLV (or for that
> > > > >>>>>>matter any additional TLV) should be part of the
> > > > >>>>>>"optional parameter" field of the Label Mapping message.
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>/himanshu
> > > > >>>>>>
> > > > >>>>>>
> > > > 
> > >>>>>>http://www.ietf.org/internet-drafts/draft-shah-pwe3-control-p
> > > > >>>>>>            
> > > > >>>>>>
> > > > >>>>rotocol-extension-01.txt
> > > > >>>>        
> > > > >>>>
> > > > >>>>>> 
> > > > >>>>>>
> > > > >>>>>>            
> > > > >>>>>>
> > > > >>>>>>>-----Original Message-----
> > > > >>>>>>>From: Luca Martini [mailto:lmartini@cisco.com]
> > > > >>>>>>>Sent: Tuesday, December 23, 2003 2:28 PM
> > > > >>>>>>>To: Rex Emmanuel Fernando
> > > > >>>>>>>Cc: tob@laurelnetworks.com; Srihari Ramachandra Sangli; 
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>Renwei Li;
> > > > >>>      
> > > > >>>
> > > > >>>>>>>Avneesh Sachdev; Rajesh Parikh; pwe3@ietf.org
> > > > >>>>>>>Subject: [PWE3] Re: PW Status negotiation procedure
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>Rex Emmanuel Fernando wrote:
> > > > >>>>>>>
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>>Hi, Guys,
> > > > >>>>>>>>
> > > > >>>>>>>>It seems
> > > > >>>>>>>>to me that the text which describes PW Status 
> negotiation 
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>is flawed.
> > > > >>>>>          
> > > > >>>>>
> > > > >>>>>>>>This is what it says:
> > > > >>>>>>>>
> > > > >>>>>>>>---
> > > > >>>>>>>>
> > > > >>>>>>>> "A PE that supports the PW Status TLV MUST 
> include it in 
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>the initial
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>> label mapping signaling as part of the PW FEC and 
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>following the
> > > > >>>      
> > > > >>>
> > > > >>>>>>>> interface parameters field. The PW Status TLV will be 
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>used for the
> > > > >>>>>          
> > > > >>>>>
> > > > >>>>>>>> lifetime of the Pseudowire for PEs that 
> support this TLV.
> > > > >>>>>>>>
> > > > >>>>>>>> If the PW Status TLV is not present in the initial 
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>PW FEC Message
> > > > >>>      
> > > > >>>
> > > > >>>>>>>> received by a PE, then the PW Status TLV will not be 
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>used and both
> > > > >>>>>          
> > > > >>>>>
> > > > >>>>>>>> PEs of the pseudowire will revert to the label 
> withdraw 
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>procedure for
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>> signaling status changes.
> > > > >>>>>>>>
> > > > >>>>>>>> If PW status TLV is sent as part of the initial PW FEC 
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>Message, but
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>> the remote PE corresponding FEC advertisement does not 
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>include a PW
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>> status TLV, or the remote PE does not support the PW 
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>Status TLV then
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>> the PW will revert to the label withdraw method 
> > to signal 
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>PW status.
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>> Note that if the PW Status TLV is not 
> supported it will 
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>automatically
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>> be ignored since the LDP ignore bit is set."
> > > > >>>>>>>>
> > > > >>>>>>>>----
> > > > >>>>>>>>
> > > > >>>>>>>>The text says that the "PW Status TLV" should 
> be part of 
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>the FEC TLV
> > > > >>>>>          
> > > > >>>>>
> > > > >>>>>>>>and following the interface parameters. Note that 
> > according 
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>to LDP spec
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>>a FEC TLV does not have sub-tlvs and I don't see a 
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>provision for
> > > > >>>      
> > > > >>>
> > > > >>>>>>>>having sub-tlvs within it. All it has is a 
> > contiguous array 
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>of different
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>>FEC types. So I am assuming that the PW Status TLV is 
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>*NOT* part of
> > > > >>>      
> > > > >>>
> > > > >>>>>>>>the FEC TLV but an additional TLV following the 
> FEC TLV. 
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>Also note that
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>>the text says that old implementations which do 
> > not suppor 
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>this would
> > > > >>>>>          
> > > > >>>>>
> > > > >>>>>>>>ignore it - this is possible only if its a separate 
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>TLV and is not
> > > > >>>      
> > > > >>>
> > > > >>>>>>>>piggybacked on the FEC TLV. The text has to be 
> > corrected to 
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>relfect this. 
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>Yes , I can see there is a problem in the description. 
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>And yes the 
> > > > >>>      
> > > > >>>
> > > > >>>>>>>status TLV is a separate TLV and MUST immediately follow 
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>the FEC TLV.
> > > > >>>>>          
> > > > >>>>>
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>>The next question I have is, if the PW Status 
> TLV follows 
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>the FEC TLV, to
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>>which FEC does it apply (note that a FEC TLV could have 
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>'n' number of
> > > > >>>>>          
> > > > >>>>>
> > > > >>>>>>>>FECs). Does the PW status apply to all FECs ?
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>not for the PW case. In IP you can have multiple FEC 
> > > elements 
> > > > >>>>>>>in the FEC 
> > > > >>>>>>>( sharing of LSP for multiple IP addresses ), but 
> > for the PW 
> > > > >>>>>>>it's only 
> > > > >>>>>>>one FEC element per FEC so the status TLV will be only 
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>for the FEC 
> > > > >>>      
> > > > >>>
> > > > >>>>>>>element present.
> > > > >>>>>>>
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>>Correct me if I am wrong in any of these points.
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>you are right on most of them :-)
> > > > >>>>>>>
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>>Also is there an IANA assigned number for the PW 
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>Status TLV type ?
> > > > >>>      
> > > > >>>
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>No. Not yet.
> > > > >>>>>>>
> > > > >>>>>>>I'll send out a correction for the text above . 
> it really 
> > > > >>>>>>>meant to say 
> > > > >>>>>>>"the PW Status TLV should immediately follow the FEC 
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>TLV" as in the 
> > > > >>>      
> > > > >>>
> > > > >>>>>>>picture...
> > > > >>>>>>>
> > > > >>>>>>>Luca
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>>>Thanks for your clarification.
> > > > >>>>>>>>
> > > > >>>>>>>>- Rex
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>     
> > > > >>>>>>>>
> > > > >>>>>>>>                
> > > > >>>>>>>>
> > > > >>>>>>>_______________________________________________
> > > > >>>>>>>pwe3 mailing list
> > > > >>>>>>>pwe3@ietf.org
> > > > >>>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
> > > > >>>>>>>
> > > > >>>>>>>   
> > > > >>>>>>>
> > > > >>>>>>>              
> > > > >>>>>>>
> > > > >>>>>>_______________________________________________
> > > > >>>>>>pwe3 mailing list
> > > > >>>>>>pwe3@ietf.org
> > > > >>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
> > > > >>>>>>
> > > > >>>>>> 
> > > > >>>>>>
> > > > >>>>>>            
> > > > >>>>>>
> > > > >>>>>          
> > > > >>>>>
> > > > >>>      
> > > > >>>
> > > > >>_______________________________________________
> > > > >>pwe3 mailing list
> > > > >>pwe3@ietf.org
> > > > >>https://www1.ietf.org/mailman/listinfo/pwe3
> > > > >>
> > > > >>    
> > > > >>
> > > > >
> > > > >  
> > > > >
> > > > 
> > > 
> > 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Luca Martini <lmartini@cisco.com>
Subject: Re: Re: PW Status negotiation procedure
Date: Mon, 29 Dec 2003 15:02:37 -0700
Organization: Cisco Systems
Lines: 44
Sender: pwe3-admin@ietf.org
References: <B99995113B318D44BBE87DC50092EDA90C0D5651@nj7460exch006u.ho.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "'Shah, Himanshu'" <hshah@ciena.com>,
        "'Rex Emmanuel Fernando'" <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li <renwei@procket.com>, Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Dec 29 23:09:13 2003
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020
X-Accept-Language: en-us, en
To: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
In-Reply-To: <B99995113B318D44BBE87DC50092EDA90C0D5651@nj7460exch006u.ho.lucent.com>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

in section 4.1 of the control document:
4.1. Frame Relay

   When emulating a frame relay service, the Frame Relay PDUs are
   encapsulated according to the procedures defined in [7]. The PE MUST
   provide Frame Relay PVC status signaling to the Frame Relay network.
   If the PE detects a service-affecting condition for a particular
   DLCI, as defined in [2] Q.933 Annex A.5 sited in IA FRF1.1, PE MUST
   communicate to the remote PE the status of the PW corresponds to the
   frame relay DLCI. The Egress PE SHOULD generate the corresponding
   errors and alarms as defined in [2] on the egress Frame relay PVC.

In this case frame-relay does have an LMI protocol, and we indicate the 
failure to the CE using the LMI protocol.
I also think that when ethernet LMI is finalized , and actually widely 
implemented it can also be used in this instance.

Some SPs will also probably run VCCV , and would then want to notify the 
CE based on a detected failure. The customer might or might not be 
running ATM OAM F4/F5 loopback cell to monitor the circuit.


>Luca> Also SP like built in SLA down time measurements, which 
>Luca> require a status 
>Luca> code from the remote PE to signal that something went wrong. In this 
>Luca> case it can be difficult to snoop the data in the PW to glean 
>Luca> the status 
>Luca> of the PW itself.
>
>I don't understand this. If PE1 detects that there is a failure, why can't it send an alarm to the SP's fault management system? Are you assuming that the SP monitors PE2, but not PE1?
>
>  
>
this is for debugging , at the command line. From the router world point 
of view, there is no centralized management, just an alarm monitoring 
system. Then  the debugging work is done by logging into the device 
itself , and looking at output of a "show" command. In this case it is 
very useful to have an SLA down timer to measure when this happened. All 
of this can, of course, be implemented in the centralized management 
system, but realistically , information there might not be easy to gather.
This is just a nice thing to have , the main purpose remains as stated 
above.

Luca


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: Re: PW Status negotiation procedure
Date: Mon, 29 Dec 2003 17:34:47 -0500
Lines: 40
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Cc: "'Shah, Himanshu'" <hshah@ciena.com>,
        "'Rex Emmanuel Fernando'"
	 <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli
	 <srihari@procket.com>,
        Renwei Li <renwei@procket.com>,
        Avneesh Sachdev
	 <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Dec 29 23:57:03 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Luca Martini'" <lmartini@cisco.com>
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

[snipped]
> 
> >Luca> Also SP like built in SLA down time measurements, which 
> >Luca> require a status 
> >Luca> code from the remote PE to signal that something went 
> wrong. In this 
> >Luca> case it can be difficult to snoop the data in the PW to glean 
> >Luca> the status 
> >Luca> of the PW itself.
> >
> >I don't understand this. If PE1 detects that there is a 
> failure, why can't it send an alarm to the SP's fault 
> management system? Are you assuming that the SP monitors PE2, 
> but not PE1?
> >
> >  
> >
> this is for debugging , at the command line. From the router 
> world point 
> of view, there is no centralized management, just an alarm monitoring 
> system. Then  the debugging work is done by logging into the device 
> itself , and looking at output of a "show" command. In this 
> case it is 
> very useful to have an SLA down timer to measure when this 
> happened. All 
> of this can, of course, be implemented in the centralized management 
> system, but realistically , information there might not be 
> easy to gather.
> This is just a nice thing to have , the main purpose remains 
> as stated 
> above.
> 
> Luca
> 

I still don't understand it.

I thought we were discussing under which conditions PE1 needs to inform PE2 of the fact that AC1 (an Attachment Circuit on PE1) is down.

You seem to say that such an indication is necessary because it allows the operator to access an SLA down timer on PE2. My question is: why not just keep this information on PE1? After all, the interface that is down is attached to PE1. 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: Re: PW Status negotiation procedure
Date: Mon, 29 Dec 2003 21:49:27 -0500
Lines: 60
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Cc: "'Shah, Himanshu'" <hshah@ciena.com>,
        "'Rex Emmanuel Fernando'"
	 <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli
	 <srihari@procket.com>,
        Renwei Li <renwei@procket.com>,
        Avneesh Sachdev
	 <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 30 03:59:07 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Luca Martini'" <lmartini@cisco.com>
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O

Thanks, Luca.

It was good that you included a quote from the control draft.  It is interesting that there is a fundamental difference between the way FR PVC status is propagated over a PW (i.e. using PW Status) and the way ATM PVC status is propagated. The Control Draft is not very clear about the ATM case, but the ATM Encapsulation draft specifies clearly that OAM cells should be used across the PW.

A few additional comments in line.

Peter

> -----Original Message-----
> From: Luca Martini [mailto:lmartini@cisco.com]
> Sent: Monday, December 29, 2003 5:03 PM
> To: Busschbach, Peter B (Peter)
> Cc: 'Shah, Himanshu'; 'Rex Emmanuel Fernando'; tob@laurelnetworks.com;
> Srihari Ramachandra Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh;
> pwe3@ietf.org
> Subject: Re: [PWE3] Re: PW Status negotiation procedure
> 
> 
> in section 4.1 of the control document:
> 4.1. Frame Relay
> 
>    When emulating a frame relay service, the Frame Relay PDUs are
>    encapsulated according to the procedures defined in [7]. 
> The PE MUST
>    provide Frame Relay PVC status signaling to the Frame 
> Relay network.
>    If the PE detects a service-affecting condition for a particular
>    DLCI, as defined in [2] Q.933 Annex A.5 sited in IA FRF1.1, PE MUST
>    communicate to the remote PE the status of the PW 
> corresponds to the
>    frame relay DLCI. The Egress PE SHOULD generate the corresponding
>    errors and alarms as defined in [2] on the egress Frame relay PVC.
> 
> In this case frame-relay does have an LMI protocol, and we 
> indicate the 
> failure to the CE using the LMI protocol.

It doesn't have to be the CE. It could be an adjacent Frame Relay switch.


> I also think that when ethernet LMI is finalized , and 
> actually widely 
> implemented it can also be used in this instance.

The question is whether Ethernet OAM will look more like Frame Relay or ATM. In the former case, PW Status should be used. In the latter case, Ethernet OAM messages should be propagated over the PW.


> 
> Some SPs will also probably run VCCV , and would then want to 
> notify the 
> CE based on a detected failure. The customer might or might not be 
> running ATM OAM F4/F5 loopback cell to monitor the circuit.
> 

Actually, connectivity would be checked with CC cells. Otherwise you are right: If the customer doesn't use CC cells to check ATM PVC status, he might use VCCV over the PW, or even some kind of connectivity verification over the underlying Transport LSP. However, that is tangential to my original comment. My point was that in case of a failure on the Attachment Circuit, the related PE should generate AIS or RDI signals over the encapsulated PVC instead of using PW Status messages to indicate PVC status to the remote PE. Since that is in line with the ATM Encpasulation draft, I assume you agree.



> 
[snipped to the end] 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in
	 PWE3]
Date: Mon, 29 Dec 2003 23:00:49 -0500
Lines: 77
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain
Cc: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        Maarten.Vissers@alcatel.de, stbryant@cisco.com, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Dec 30 05:07:08 2003
Return-path: <pwe3-admin@ietf.org>
To: "'Peter Willis'" <pjw@ip-engineering.bt.com>
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O



> -----Original Message-----
> From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
> Sent: Friday, December 19, 2003 10:01 AM
> To: Busschbach, Peter B (Peter)
> Cc: 'neil.2.harrison@bt.com'; Maarten.Vissers@alcatel.de;
> stbryant@cisco.com; pwe3@ietf.org
> Subject: Re: [PWE3] PW functional model and its OAM [was: FCS 
> retention
> in PWE3] 
> 
> 
> Colleagues,
> 
> First a comment on carrier strategy & requirements then 
> comments on VCCV & 
> RSVP-TE detail.
> 
> In terms of Fault & Performance Management versus efficient 
> packet forwarding 
> the message from BT is very clear. Customer experience is the 
> most important 
> thing to us. The customer must never see a fault.  Five 9's 
> reliability & sub 50
> msec fast reroute is insignificant if it takes us N hours to 
> locate a fault.
> We also aim to reduce Operational costs & we can buy a lot of 
> extra-gates in
> ASICs for the recurring costs of experts to locate faults. 
> Carriers won't do
> PWE3 or core network convergence to only save capex (that's 
> not where the major
> costs lie) but they do it to reduce opex as well. The 
> inability to fault manage 
> efficiently increase opex costs and negates the reason to do 
> PWE3 or network
> convergence. Seems to me the carrier version of PWE3 starts 
> with "how do
> we reduce operational expediture?".
> 
> Does VCCV detect swapped or merged LSPs e.g. at the egress 2 
> LSPs have each 
> others' labels or 2 LSPs have merged into 1 label by a fault 
> condition? What's 
> the risk of an LSP being sent to the wrong egress and the 
> discriminators still 
> being valid?

Peter,

Sorry for the late response.

Yes, I believe VCCV protects against swapped or mismerged LSPs. There are two cases:

Wrong PW Label:
When LSP Ping is used over the PW, the original PW-id FEC is included in the message. The receiving PE will check whether the FEC in the Ping message matches the original PW-id FEC. It will reply accordingly. 

Wrong PSN Label:
To detect failures in the underlying transport LSPs, one could run LSP Ping over the PSN LSPs. However, as far as the PWs are concerned, VCCV would also protect against swapped or mismerged PSN LSPs.  It is possible that despite a wrong PSN Label, the PW is still terminated on the correct egress PW. In that case there is no problem. However, if due to an incorrect PSN Label the PW is terminated on a different PE, LSP Ping run over the PW will result in detection of the failure.

Note: LSP Ping over PW will detect swapped or mismerged PSN LSPs. However, it does not enable fault localization. For that, one needs to run an OAM protocol in the PSN layer itself.

Peter


> 
> If we are running graceful restart RSVP to protect our 
> forwarding against 
> control plane outages then don't we need to run a data plane 
> liveness test 
> (like BFD) to check the forwarding plane is still available 
> whilst the 
> control-plane is restarting? 
> 
> PeterW.
>