Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Wed, 1 Apr 2009 13:19:34 +0530

Support.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of BOCCI Matthew
Sent: Tuesday, March 31, 2009 5:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?

This is the start of a two week poll to judge the consensus to move draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft.

Please can you respond, *to the PWE3 list only*, with your approval (or otherwise).

This poll will close on 14th April 2009.

Regards

Matthew

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 1 Apr 2009 11:08:48 -0400

I support the effort but I believe this draft needs mroe clarification
text
before it is accepted as WG draft.
 
This draft is shifting the paradigm, pw label no longer carries the
forwarding symantics,
instead PPP PID is used.  The draft needs to expand on the packet
processing aspects.
 
The PW setup needs more clarification text too.  It seems that 'server'
control plane is used
to create PW and tunnels and once PW is created, 'client' forwarding
plane (to backhaul
MPLS) and control plane (perhaps the same protocols as 'server'
protcols) is used to 
splice the 'client' MPLS networks.  I think authors need to expand on
this along with 
additional rules as break criteria so that such recurssions don't create
stack overflow. For instance, once
the PW is up and being used as virtual interface with an IP address, can
a 'client'  PE/S-PE/T-PE
be used on that server-PW-come-virtual-interface?
 
Its bit amusing that we started with PW to go over MPLS, now we need PW
to carry MPLS...:-)
 
regards,
himanshu

From: [email-masked] [mailto:[email-masked]] On Behalf Of
BOCCI Matthew
Sent: Tuesday, March 31, 2009 8:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?

This is the start of a two week poll to judge the consensus to move
draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft.

Please can you respond, *to the PWE3 list only*, with your approval (or
otherwise). 

Regards 

Matthew

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 1 Apr 2009 20:49:37 +0300

I support, but strongly do NOT support the name.

"packet PW" does not mean anything to me. Do the other encaps not transport packets ?
Does this one only transport packets (and not e.g., frames?)

How about "interface traffic PW" or "generic traffic PW" ?

The latter name "generic PW" was the name that was used
when this same idea was described a few years ago
(see to lock onto the thread http://www.ietf.org/mail-archive/web/pwe3/current/msg08070.html )

Y(J)S

2009/3/31 BOCCI Matthew <[email-masked]<mailto:[email-masked]>>

Regards

Matthew

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

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 1 Apr 2009 11:12:47 -0700

No

> -----Original Message-----
> From: BOCCI Matthew [mailto:[email-masked]] 
> This is the start of a two week poll to judge the consensus 
> to move draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working 
> Group draft.
>

---

From: "BALUS Florin" <[email-masked]>
Date: Wed, 1 Apr 2009 13:16:00 -0500

Support.

Regards 

Matthew

---

From: <[email-masked]>
Date: Wed, 1 Apr 2009 19:41:49 +0100

Matthew,
 
 I am not clear why responses should only be sent to PWE3 as this draft
seems most germane to MPLS-TP.
 
I support the concept of adding a PID field to MPLS-TP (though I think
there are better ways to to this) but I am not sure how useful this is
to existing MPLS deployments. ....so I am a little unclear as to what we
are voting for here, ie classic MPLS or MPLS-TP?  *This point needs
clarifying.* 
 
My further observations are specifically for the case of applying this
new DP structure to MPLS-TP.....but I accept that these observation may
not be applicable if there is no intention to apply this draft to
MPLS-TP (but then this begs the question of what MPLS-TP adaptation will
look like?)

1    The opening sentence of the Introduction says:
"There is a need to provide a method of carrying a packet service over
an MPLS PSN in a way that provides isolation between the two networks. "
 
I agree with this.  And an important case is MPLS(TP)overMPLS-TP.  I
also think that in addition to client/server *functional separation* the
server should be providing a *transparent transport service* to the
client, if the server is supposed to be fulfilling a transport network
role.
 
However I have a problem with what it says later in the Introduction
about this same point:
"A further consideration is that two adjacent MPLS LSRs do not simply
exchange MPLS packets.  They exchange IP packets for adjacency
formation, control, routing, label exchange, management and  monitoring
purposes.  In addition they may exchange data-link packets as part of
routing (e.g.  IS-IS hellos and IS-IS LSPs) and for OAM purposes (e.g.
Cisco Discovery Protocol).  Thus the two clients require an attachment
mechanism that can be used to multiplex a number of protocols.  In
addition it is essential to the correct operation of the network layer
that all of these protocols fate share.

Where the client LSRs and server PEs are co-located in the same
equipment the data-link layer can be simplified to a simple protocol
identifier (PID) that is used to multiplex the various data-link types
onto a pseudowire.  This is the method that described in this document."
 
The whole point of a client/server relationship is to accomodate
distinct layer networks (and hence distinct equipment) owned by
differrent operating parties.  So to place a restriction that the new DP
format of using the PID can only be used when the client and server MPLS
layer networks are co-resident in the same equipment kind-of defeats the
whole purpose of what is said in the opening sentence of the
Introduction IMO.
 
I don't see why we can't have a p2p server layer (the 'data-link'
mentioned above) that fully terminates on the client and server MPLS
nodes....indeed this is the key case to address IMO.  Further, we should
not place an undue restriction on what the technology used here (for
this 'data-link').  It could be Ethernet or it could be SDH (using GFP
adaptation to identify the client as MPLS) and it should be able to be
different on each client/server end.

2    If we are using the PID with MPLS-TP...where I am assuming the
intention is to produce a transport network like behaviour......then we
can make these observations:
 
-    We should not have ECMP in MPLS-TP.......therefore the 1st nibble
value 0000 of the CW is redundant.
 
-    A transport network must preserve the sequence ordering of client
symbol information.....therefore the Sequence Number field of the CW is
redundant.
 
I can understand why these are required in 'classic' MPLS but we should
note that if this DP format is used with MPLS-TP these fields are
redundant and should be set to something like all 0s.   More generally
of course, we perhaps should even question whether we need the CW in
MPLS-TP, as it is not offering any useful adaptation functions at
all.....indeed we can observe that if the PID always followed the S=1
header case this ought to work fine in MPLS-TP (which is essentially
what John Drake and I were proposing should be considered).
  
regards, Neil

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 1 Apr 2009 12:10:13 -0700

+1 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, April 01, 2009 11:42 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [PWE3] [mpls-tp] 
> draft-bryant-pwe3-packet-pw-00.txt to WG draft?
> 
> Matthew,
>  
>  I am not clear why responses should only be sent to PWE3 as 
> this draft seems most germane to MPLS-TP.
>  
> I support the concept of adding a PID field to MPLS-TP 
> (though I think there are better ways to to this) but I am 
> not sure how useful this is to existing MPLS deployments. 
> ....so I am a little unclear as to what we are voting for 
> here, ie classic MPLS or MPLS-TP?  *This point needs clarifying.* 
>  
> My further observations are specifically for the case of 
> applying this new DP structure to MPLS-TP.....but I accept 
> that these observation may not be applicable if there is no 
> intention to apply this draft to MPLS-TP (but then this begs 
> the question of what MPLS-TP adaptation will look like?)
>  
>  
> "There is a need to provide a method of carrying a packet 
> service over an MPLS PSN in a way that provides isolation 
> between the two networks. "
>  
> I agree with this.  And an important case is 
> MPLS(TP)overMPLS-TP.  I also think that in addition to 
> client/server *functional separation* the server should be 
> providing a *transparent transport service* to the client, if 
> the server is supposed to be fulfilling a transport network role.
>  
> However I have a problem with what it says later in the 
> Introduction about this same point:
> "A further consideration is that two adjacent MPLS LSRs do 
> not simply exchange MPLS packets.  They exchange IP packets 
> for adjacency formation, control, routing, label exchange, 
> management and  monitoring purposes.  In addition they may 
> exchange data-link packets as part of routing (e.g.  IS-IS 
> hellos and IS-IS LSPs) and for OAM purposes (e.g.  Cisco 
> Discovery Protocol).  Thus the two clients require an 
> attachment mechanism that can be used to multiplex a number 
> of protocols.  In addition it is essential to the correct 
> operation of the network layer that all of these protocols fate share.
> 
> Where the client LSRs and server PEs are co-located in the 
> same equipment the data-link layer can be simplified to a 
> simple protocol identifier (PID) that is used to multiplex 
> the various data-link types onto a pseudowire.  This is the 
> method that described in this document."
>  
> The whole point of a client/server relationship is to 
> accomodate distinct layer networks (and hence distinct 
> equipment) owned by differrent operating parties.  So to 
> place a restriction that the new DP format of using the PID 
> can only be used when the client and server MPLS layer 
> networks are co-resident in the same equipment kind-of 
> defeats the whole purpose of what is said in the opening 
> sentence of the Introduction IMO.
>  
> I don't see why we can't have a p2p server layer (the 
> 'data-link' mentioned above) that fully terminates on the 
> client and server MPLS nodes....indeed this is the key case 
> to address IMO.  Further, we should not place an undue 
> restriction on what the technology used here (for this 
> 'data-link').  It could be Ethernet or it could be SDH (using 
> GFP adaptation to identify the client as MPLS) and it should 
> be able to be different on each client/server end.
>  
>  
> 2    If we are using the PID with MPLS-TP...where I am 
> assuming the intention is to produce a transport network like 
> behaviour......then we can make these observations:
>  
> -    We should not have ECMP in MPLS-TP.......therefore the 
> 1st nibble value 0000 of the CW is redundant.
>  
> -    A transport network must preserve the sequence ordering 
> of client symbol information.....therefore the Sequence 
> Number field of the CW is redundant.
>  
> I can understand why these are required in 'classic' MPLS but 
> we should note that if this DP format is used with MPLS-TP 
> these fields are redundant and should be set to something 
> like all 0s.   More generally of course, we perhaps should 
> even question whether we need the CW in MPLS-TP, as it is not 
> offering any useful adaptation functions at all.....indeed we 
> can observe that if the PID always followed the S=1 header 
> case this ought to work fine in MPLS-TP (which is essentially

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Thu, 2 Apr 2009 04:30:47 +0530

Support

Regards

Matthew

---

From: "Riccardo Martinotti" <[email-masked]>
Date: Thu, 2 Apr 2009 15:08:00 +0200

The network scenario considered into the draft is certainly of interest, the case where client is "classic" MPLS and server is MPLS-TP is also described into draft-martinotti-mpls-tp-interworking-01, Section 7.1.3. (IP/MPLS / MPLS-TP hybrid edge node)

I have one comment/question to the authors: In section 2 there is reference to RFC 3985, Figure 3, however it is not specified which of the two interworking functions is referred to. I suppose, due to the presence of virtual physical termination, that the one with pre-processing is referred. How is it defined the relationship between the Attachment Circuit and the PW, in term of Forwarder and Native Service Processing?

Thank you and regards,

Riccardo

From: [email-masked] [mailto:[email-masked]] On Behalf Of BOCCI Matthew
Sent: martedì 31 marzo 2009 14.01
To: [email-masked]
Cc: [email-masked]
Subject: [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG draft?

Regards 

Matthew

---

From: [email-masked]
Date: Fri, 3 Apr 2009 15:08:29 +0800

Sir,

Could rfc4618 Encapsulation Methods for Transport of PPP/High-Level Data 
Link Control (HDLC) over MPLS Networks 
be used as a solution for the scenario in this draft? (although have more 
encapsulation overhead)

Thank you!

Yaakov Stein <[email-masked]> 
发件人:  [email-masked]
2009-04-02 01:49

收件人
"[email-masked]" <[email-masked]>
抄送

主题
Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?

"packet PW" does not mean anything to me. Do the other encaps not 
transport packets ?
Does this one only transport packets (and not e.g., frames?)

The latter name "generic PW" was the name that was used
when this same idea was described a few years ago
(see to lock onto the thread 
http://www.ietf.org/mail-archive/web/pwe3/current/msg08070.html )
 
Y(J)S

2009/3/31 BOCCI Matthew <[email-masked]>

[email-masked]
[email-masked]

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 4 Apr 2009 11:39:05 -0400

Jiang,

Yes it could, but in addition to higher overhead it would also require
running the PPP state machine and using PPP options. We wanted to keep
this as simple as possible.

Thanks,
Andy

---

From: [email-masked]
Date: Wed, 8 Apr 2009 19:46:04 +0800

Andy,

Is there any need for Packet-PW to maintain any kind of state machine for 
virtual interface status like Lucy Yong mentioned?

Thanks,
Albert

Lucy Yong <[email-masked]> 
sender:  [email-masked]
2009-04-01 01:13

to
'Stewart Bryant' <[email-masked]>, [email-masked], "'Malis, Andrew G. 
(Andy)'" <[email-masked]>
cc

topic
[PWE3] comments on packet pw

Hi Stewart and Andy,
 
I support this draft to become WG draft. Congratulation!!
I also have some comments on the draft:
 
1)     Since Packet PW requires using CW, it is necessary to state how to 
use flow label and S/N for packet PW.
2)     It is good to have the PW status mapped to virtual interfaces. 
However, each protocol interface may have its own link status protocol 
running, the draft should state the procedures to determine interface 
status, or require each protocol interface to turn off its link protocol 
when using Packet PW
3)     Since Packet PW acts as a data link between two clients LSRs, the 
draft should state link operational procedures (for client networks) over 
a packet PW such as how to determine admin cost, TE metrics, etc.
4)     I assume that a Packet PW can obtain transport resiliency from 
server MPLS network, it would be nice for the draft to state them and 
considers that the consequence may change admin cost in client networks.
 
Cheers,
Lucy_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

"Andrew G. Malis" <[email-masked]> 
2009-04-04 23:39

[email-masked]

[email-masked], [email-masked]

Jiang,

Thanks,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 8 Apr 2009 09:41:59 -0400

Jiang,
I don't think so, but we should look more closely at the details on mapping
between the virtual interface state and PW status reporting (without being
implementation-dependent) to make sure we've got the all of the details
covered. Lucy's point 3 is a good one as well.

Thanks,
Andy

On Wed, Apr 8, 2009 at 7:46 AM, <[email-masked]> wrote:

>  *Lucy Yong <[email-masked]>*
> (Andy)'" <[email-masked]>  cc
>   topic
> However, *each protocol interface may have its own link status protocol*running, the draft should state the procedures to determine interface
> draft should state link operational procedures (for client networks) over a
> packet PW such as how to determine admin cost, TE metrics, etc.
>  *"Andrew G. Malis" <[email-masked]>*
>
> 2009-04-04 23:39
>   [email-masked]

---

From: Lucy Yong <[email-masked]>
Date: Wed, 08 Apr 2009 14:18:55 -0500

Hi Andy and XiaoWei,

Since the purpose of packet-PW is to create a virtual physical interface for
two connected client LSRs and allow multiple client protocols run over it.
Assume the client LSP is IP router, it runs OSPF or IS-IS. To support the
routing protocol properly running, IP interface is configured over a
packet-PW. Hello protocol is normally activated over IP interface. However,
if we want to use packet-PW state as IP interface state, we need to turn off
hello protocol. Is that right? That is my second point in previous e-mail.

Thanks,

Lucy

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Andrew G. Malis
Sent: Wednesday, April 08, 2009 8:42 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?

Jiang,

Thanks,

Andy

Andy, 

Thanks, 
Albert 

2009-04-01 01:13 

to

cc

topic

 

Hi Stewart and Andy, 

1)     Since Packet PW requires using CW, it is necessary to state how to
use flow label and S/N for packet PW. 
2)     It is good to have the PW status mapped to virtual interfaces.
However, each protocol interface may have its own link status protocol
running, the draft should state the procedures to determine interface
status, or require each protocol interface to turn off its link protocol
when using Packet PW 
3)     Since Packet PW acts as a data link between two clients LSRs, the
draft should state link operational procedures (for client networks) over a
packet PW such as how to determine admin cost, TE metrics, etc. 
4)     I assume that a Packet PW can obtain transport resiliency from server
MPLS network, it would be nice for the draft to state them and considers
that the consequence may change admin cost in client networks. 
  
Cheers, 

pwe3 mailing list
[email-masked]

2009-04-04 23:39 

[email-masked] 

 

 

Jiang,

Thanks,
Andy

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 14 Apr 2009 08:51:17 +0100

Lucy

Turning off bits of the routing protocol is actually quite hard, risks 
breaking the protocol and requires us to track and reflect those changes 
in the surrogate protocol. We would therefore want to run the link state 
routing protocol unmodified including the hellos.

Stewart

Lucy Yong wrote:
>
> Hi Andy and XiaoWei,
>
>  
>
> Since the purpose of packet-PW is to create a virtual physical 
> interface for two connected client LSRs and allow multiple client 
> protocols run over it. Assume the client LSP is IP router, it runs 
> OSPF or IS-IS. To support the routing protocol properly running, IP 
> interface is configured over a packet-PW. Hello protocol is normally 
> activated over IP interface. However, if we want to use packet-PW 
> state as IP interface state, we need to turn off hello protocol. Is 
> that right? That is my second point in previous e-mail.
>
>  
>
> Thanks,
>
> Lucy
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Andrew G. Malis
> *Sent:* Wednesday, April 08, 2009 8:42 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?
>
>  
>
> Jiang,
>
>  
>
> I don't think so, but we should look more closely at the details on 
> mapping between the virtual interface state and PW status reporting 
> (without being implementation-dependent) to make sure we've got the 
> all of the details covered. Lucy's point 3 is a good one as well.
>
>  
>
> Thanks,
>
> Andy
>
>  
>
> On Wed, Apr 8, 2009 at 7:46 AM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
> Andy,
>
> Is there any need for Packet-PW to maintain any kind of state machine 
> for virtual interface status like Lucy Yong mentioned?
>
> Thanks,
> Albert
>
>
>
> *Lucy Yong <[email-masked] <mailto:[email-masked]>>*
> sender:  [email-masked] <mailto:[email-masked]>
>
> 2009-04-01 01:13
>
> 	
>
> to
>
> 	
>
> 'Stewart Bryant' <[email-masked] <mailto:[email-masked]>>, 
> [email-masked] <mailto:[email-masked]>, "'Malis, Andrew G. (Andy)'" 
> <[email-masked] <mailto:[email-masked]>>
>
> cc
>
> 	
>
>  
>
> topic
>
> 	
>
> 1)     Since Packet PW requires using CW, it is necessary to state how 
> to use flow label and S/N for packet PW.
> However, *each protocol interface may have its own link status 
> protocol* running, the draft should state the procedures to determine 
> interface status, or require each protocol interface to turn off its 
> link protocol when using Packet PW
> 3)     Since Packet PW acts as a data link between two clients LSRs, 
> the draft should state link operational procedures (for client 
> networks) over a packet PW such as how to determine admin cost, TE 
> metrics, etc.
> [email-masked] <mailto:[email-masked]>
> *"Andrew G. Malis" <[email-masked] <mailto:[email-masked]>>*
>
> 2009-04-04 23:39
>
> 	
>
>  
>
> 	
>
> [email-masked] <mailto:[email-masked]>
>
>  
>
> 	
>
> [email-masked] <mailto:[email-masked]>, [email-masked] 
> <mailto:[email-masked]>
>
>  
>
> 	
>
> 2009/4/3  <[email-masked] <mailto:[email-masked]>>:
> >
> > Sir,
> >

---

From: "Riccardo Martinotti" <[email-masked]>
Date: Tue, 14 Apr 2009 18:51:15 +0200

Support,

however, following also my previous email on this subject, I would like IETF during working group drafting could better specify the interworking function on the virtual physical termination.

I think that it's also important to address Lucy's third point.

Regards,

Riccardo 

Regards 

Matthew

---

From: Lucy Yong <[email-masked]>
Date: Tue, 14 Apr 2009 17:22:40 -0500

Hi Stewart,

If link hello protocol can't be turned off, then the following statement in
the section 4 does not apply. LSR has to use link state routing protocol to
decide if the interface is up or down. I suggest revising the section 4 and
adding your description (below) in. 

4.  Status Indication

   A pseudowire status indicating a fault can be considered equivalent
   to interface down and SHOULD be passed across the virtual interface
   to the local LSR.  This improves scaling in PE with large numbers of
   c-resident LSRs and with LSRs that have large numbers of interfaces
   mapped to pseudowires.

We should also mention in the draft that since client LSR runs its own link
state protocols to its peers, there is no need to use PW status message to
carry LSR local link state fault to Packet-PW remote.

Regards,
Lucy

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Tuesday, April 14, 2009 2:51 AM
> To: Lucy Yong
> Cc: 'Andrew G. Malis'; [email-masked]; [email-masked]

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 14 Apr 2009 21:57:43 -0400

Not sure where this discussion is going but...

if a physical point-to-point connection is being
mimicked by a 'virtual wire' (i.e. pw) with its
corresponding mechanisms of up/down (i.e. pw status), etc,
why should layer above (or for that matter layer below)
start making exceptions??

what am I missing here???

/himanshu

-----Original Message-----
From: [email-masked] on behalf of Lucy Yong
Sent: Tue 4/14/2009 6:22 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?
 
Hi Stewart,

4.  Status Indication

Regards,
Lucy

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 15 Apr 2009 11:53:47 +0100

Lucy

The statement in (4) is still correct, because you can turn the hello 
rate down and
use the network indication fault indication to indicate the absence of 
end to end
connectivity.

You can't turn hello's off because they carry all sorts of adjacency 
information, but
you can still configure the system so that connectivity loss is 
primarily reported
through loss of light or its functional equivalent (PW down) and this is 
what we
propose in the text.

It might be useful of I added some text to the draft stating that the 
scaling
improvement occurs because the operator can reduce the hello packet and
BFD rate.

Stewart

Lucy Yong wrote:
>>>> Could rfc4618 Encapsulation Methods for Transport of PPP/High-Level
>>>>         
> Data
>   
>>>> be used as a solution for the scenario in this draft? (although have
>>>>         
> more
>   
>>>> encapsulation overhead)
>>>>
>>>> Thank you!
>>>>         
>>>
>>>       
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 15 Apr 2009 12:20:51 +0100

Himanshu

You are not missing anything.

The protocol carried over the PW must remain unchanged.

A failure of the PW looks like "loss of light" which is always reflected
up to routing.

The proposal is therefore to run the routing layer exactly as we normally do
and to create a signal that is equivalent to LoL that is passed up to
the virtual interface.

Stewart

---

From: Lucy Yong <[email-masked]>
Date: Wed, 15 Apr 2009 09:43:40 -0500

Hi Stewart,

Thank you for the explanation. It is good to state this in the draft. In
addition, clarify that org PW is responsible to pass local ACH fault to PW
remote, but packet-PW is not necessary to carry client link fault to
packet-PW remote because client has its own link state protocol.

Regards,
Lucy

> Sent: Wednesday, April 15, 2009 5:54 AM
> To: Lucy Yong
> Cc: pwe3