Subject: [PWE3] SG13 liaison on pseudowires

From: Stewart Bryant <[email-masked]>
Date: Tue, 22 May 2007 15:16:40 +0100

Please can I draw the attention of the PWE3 WG to the following liaison 
from ITU SG13

https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=329

The two key items are:

In this draft new Recommendation we have adopted terminology that better 
matches yours (for
example, “common interworking indicators” has been replaced by “control 
word”). However, we
use the term generic adaptation layer (GAL) for both single and 
multi-segment pseudowires. Our
present understanding of this relationship is captured in Appendix III 
of the aforementioned
document. Our preference is to use the term “pseudowire layer” instead 
of GAL. We would
appreciate your comments and in particular on our desire to use the term 
“pseudowire layer” instead
of GAL.

In addition, in the course of editing Y.gal we have come across a 
discrepancy between our
definition of a stitching interworking function (S-IWF) and our 
understanding of your use of S-PEs
for the case of traversal of multiple administrative domains. When two 
administrative domains need
to be joined, the administrative boundary should always be located in 
the middle of a link, and not
in the middle of a processing function. Positioning a boundary inside a 
processing function (as we
understand to be the case for an S-PE) would mean shared ownership of a 
physical piece of
equipment, and its location on the premises of one of the 
administrations involved. The former is
usually unacceptable for business reasons and the latter enables a 
service provider to gain access to
another service provider’s topology.

- Stewart

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

---

From: [email-masked]
Date: Wed, 23 May 2007 13:26:26 +0100

Stewart,

Stewart Bryant <[email-masked]> wrote on 22/05/2007 15:16:40:

> example, "common interworking indicators" has been replaced by "control
> word"). However, we
> document. Our preference is to use the term "pseudowire layer" instead
> of GAL. We would
> "pseudowire layer" instead
> of GAL.
>
> another service provider's topology.

I am not sure that we do imply the use of a single S-PE. Figure 5 of
Section 4.4.4 of draft-ietf-pwe3-ms-pw-arch-02.txt describes the
architecture for the multi-provider case. This shows two S-PEs, one
belonging to each of the providers.

Regards,

Matthew

-----------------------------------------
Matthew Bocci
IP Division,
Alcatel-Lucent Telecom Limited, Registered Office: Christchurch Way,
Greenwich, London SE10 0AG.
Registered in England & Wales number 02650571
-----------------------------------------

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Wed, 23 May 2007 11:35:16 -0500

Agree, also can draw attention to the requirements document which
includes Fig 3 and requirements on interprovider support.

Neither the requirements document or architecture document states (or
infers) the need for "shared ownership" and "enables a service provider
to gain access to another service provider's topology" to support
interprovider. If they continue to have concerns on the interpretation
of S-PE, it would be helpful if they provide specifics.

Regards,
Deborah

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, May 23, 2007 8:26 AM
To: [email-masked]
Cc: pwe3
Subject: Re: [PWE3] SG13 liaison on pseudowires

Stewart,

Regards,

Matthew

---

From: <[email-masked]>
Date: Wed, 23 May 2007 18:03:22 +0100

Colleagues,

While draft-ietf-pwe3-ms-pw-arch-02 does show a case where the
administrative boundary between two providers is located in the middle
of a link (Figure 5) it also shows a case where the admin boundary is
located within the middle of a processing function - i.e. the following
text in the first paragraph of section 4.2.2 "For example, in Figure 4,
PSN 1 and PSN 2 would be different provider's networks. However, this
would require that S-PE1 be a member of both provider networks".

Therefore my interpretation is that use of a single S-PE is permissible
by the PWE3 documents (and is technically achievable).  However from a
business boundary & commercial perspective it is not generally
permissable.

Maybe a response pointing to Figure 5 and commenting that the PWE3
architecture accommodates the admin boundary being positioned in the
middle of a link and recognising that this is likely to be the commonest
implementation would be appropriate?

Ben

BRUNGARD, DEBORAH A, ATTLABS <mailto:[email-masked]> wrote:
> Agree, also can draw attention to the requirements document
> which includes Fig 3 and requirements on interprovider support.
> 
> infers) the need for "shared ownership" and "enables a
> service provider to gain access to another service provider's
> topology" to support interprovider. If they continue to have
> concerns on the interpretation of S-PE, it would be helpful
> if they provide specifics.
> 
> Regards,
> Deborah
> 
> 
>> Please can I draw the attention of the PWE3 WG to the following
>> liaison from ITU SG13 
>> 
>> In this draft new Recommendation we have adopted terminology that
>> better matches yours (for example, "common interworking indicators"
>> has been replaced by "control word"). However, we use the term
>> generic adaptation layer (GAL) for both single and multi-segment
>> pseudowires. Our present understanding of this relationship is
>> captured in Appendix III of the aforementioned document. Our
>> preference is to use the term "pseudowire layer" instead of GAL. We
>> would appreciate your comments and in particular on our desire to
>> use the 
> term
>> discrepancy between our definition of a stitching interworking
>> function (S-IWF) and our understanding of your use of S-PEs for the
>> case of traversal of multiple administrative domains. When two
>> administrative domains need to be joined, the administrative boundary
>> should always be located in the middle of a link, and not in the
>> middle of a processing function. Positioning a boundary inside a
>> processing function (as we understand to be the case for an S-PE)
>> would mean shared 
> ownership of
> a
>> physical piece of
>> administrations involved. The former is usually unacceptable for
>> business reasons and the latter enables a service provider to gain
>> access to another service provider's topology.
> 
> I am not sure that we do imply the use of a single S-PE.
> Figure 5 of Section 4.4.4 of
> draft-ietf-pwe3-ms-pw-arch-02.txt describes the architecture
> for the multi-provider case. This shows two S-PEs, one
> Alcatel-Lucent Telecom Limited, Registered Office:
> Christchurch Way, Greenwich, London SE10 0AG.

---

From: [email-masked]
Date: Thu, 24 May 2007 09:35:35 +0100

Ben,

Many thanks for clarifying where the confusion arose. Technically it could
be possible to share an S-PE, but I agree that it is not generally
desirable.

In addition to clarifying this point to the ITU-T, I propose that we remove
the sentence starting "For example, in Figure 4..." in section 4.2.2.

Regards,

Matthew

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 30 May 2007 16:23:54 +0300

Matthew, 

Sorry for being too busy to enter this discussion earlier.

I am very surprised by your response. 

If we have not one S-PE, but two S-PEs connected by a link,
what is this link ?

If it is a link of the native service, then this is not a stiching point
as we have defined it, but rather two separate PWs.

But if the two S-PEs are in different MPLS networks
they might be connected via an IP link. Then we need to
continue the PW over IP, e.g. with L2TPv3.
We haven't defined this yet.

Or perhaps you mean that the first S-PE removes 
the MPLS header and leaves the PW-PDU (i.e. the PW label, CW and
payload).
The second S-PE receives this PW-PDU and pushes an MPLS lable stack.
This is allowed by the ITU draft, but we have never defined transport
of PW over a "wire" without MPLS 
(although it can be considered MPLS with PHP).

Even after we get over this level, 
how does the setup work (unless it is all manual) ?
If there is a non-IP/MPLS link in between the S-PEs
how do all the mechanisms that have been proposed function?
Do you mean that if we have a native ATM link between two S-PEs
running ATM PWs, that you are going to run the PWE control protocol
over ATM ?  I haven't heard this suggested. 

Y(J)S

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, May 24, 2007 11:36
To: [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] SG13 liaison on pseudowires

Ben,

Many thanks for clarifying where the confusion arose. Technically it
could be possible to share an S-PE, but I agree that it is not generally
desirable.

In addition to clarifying this point to the ITU-T, I propose that we
remove the sentence starting "For example, in Figure 4..." in section
4.2.2.

Regards,

Matthew

> located within the middle of a processing function - i.e. the 
> following text in the first paragraph of section 4.2.2 "For example, 
> in Figure 4, PSN 1 and PSN 2 would be different provider's networks. 
> However, this would require that S-PE1 be a member of both provider
networks".
>
> Therefore my interpretation is that use of a single S-PE is 
> permissible by the PWE3 documents (and is technically achievable).  
> However from a business boundary & commercial perspective it is not 
> generally permissable.
>
> middle of a link and recognising that this is likely to be the 
> commonest implementation would be appropriate?
>
> Ben
>
> > infers) the need for "shared ownership" and "enables a service 
> > provider to gain access to another service provider's topology" to 
> > support interprovider. If they continue to have concerns on the 
> > interpretation of S-PE, it would be helpful if they provide 
> > specifics.
> >
> > Regards,
> > Deborah
> >
> >

> >> administrative domains need to be joined, the administrative 
> >> boundary should always be located in the middle of a link, and not 
> >> in the middle of a processing function. Positioning a boundary 
> >> inside a processing function (as we understand to be the case for 
> >> an S-PE) would mean shared
> > ownership of
> > a
> >> physical piece of
> > draft-ietf-pwe3-ms-pw-arch-02.txt describes the architecture for the

> > multi-provider case. This shows two S-PEs, one belonging to each of 
> > the providers.
> >
> > Regards,
> >
> > Matthew
> >

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 30 May 2007 16:39:41 +0300

Everyone, 

There has been some discussion about one aspect of the ITU liaison,
but no discussion on what I consider the more important part.

ITU invented a term "GAL" (originally "GCA") in order not to use the
term "PW" without our permission. If we grant this permission,
then the ITU will happily call the transport entities in the Y.gal draft
- PWs.
I think we should encourage such use of the PW terminology
(remember that in the past the ITU used such terms as
  "interworking LSP" for PW, and 
  "common interworking idicators" for "control word").

However, there is a question about precisely what the term PW refers to.

If we have a single segment PW with VCCV, 
the ITU regards this as two functions - 
  an "adaptation" that encapsulates/decapsulates the native service
  a "termination function" that adds and monitors the VCCV OAM
Which is the PW, the adapted native service before adding the OAM
(the "link connection"), or after adding it (the "trail")?

I prefer the trail, but then the question arises as to what happens
if we do not use VCCV. Then, according to the regular definitions,
there is no "trail", and thus no PW ? 
There is the possibility of claiming that if we use a CW and thus there 
is the POSSIBILITY of using VCCV, this is still a trail,
but then what do we call the case when there is no CW ?

Next, for the multisegment PW case, the multisegment trail
is the PW (assuming VCCV travels from T-PE to T-PE). 
But what is each segment ? 
We call it a PW segment, but is it a "PW" ? 
(The ITU definitions rule this out if the trail is a PW).

Y(J)S

---

From: [email-masked]
Date: Wed, 30 May 2007 15:02:56 +0100

Yaakov,

The assumption is that you have an inter-AS MPLS tunnel between the S-PEs.

Regards,

Matthew

                                                                           
             "Yaakov Stein"                                                
             <[email-masked]                                             
             >                                                          To 
                                       <[email-masked] 
             30/05/2007 14:23          >, <[email-masked]>  
                                                                        cc 
                                       <[email-masked]>                     
                                                                   Subject 
                                       RE: [PWE3] SG13 liaison on          
                                       pseudowires                         

                                                                           

Matthew,

Y(J)S

-----Original Message-----

Ben,

Regards,

Matthew

networks".

---

From: <[email-masked]>
Date: Wed, 30 May 2007 15:24:04 +0100

Yaakov,

I agree that aligned terminology would be extremely useful.

In my view the confusion between what maps to an IETF PW (terminology
wise) arises because ITU differentiates between adaptation and
termination and IETF does not.

My view of the (PW) world is this:  We have a PW layer network.  That PW
layer network consists of PW network (or link) connections and PW trails
between PW Access Points.

An IETF PW can map to both (depending on context):

1) a PW network (or link) connection, if VCCV/CW is not present.
2) a PW trail, if VCCV/CW is present.

We therefore cannot say that an IETF PW categorically maps to either (1)
or (2).

If we look at the function provided by a PW it may help.  A PW is used
to transport (support) a client (native service) between two access
points (PEs).  Therefore the IETF term PW maps to the transport function
that is is used to support the client (native service).  If we (in ITU)
need to be more specific about precisely which component of the
transport function, then we can refer to PW network/link connections and
PW trails.

Therefore in answer to your (well the liaison's) question "precisely
what the term PW refers to" I believe the answer is the transport
function that is used to support the native service.

IMO both IETF and ITU are describing the same behaviour and
functionality so there should be no reason why they can't both use the
term PW.

Ben

Yaakov Stein <mailto:[email-masked]> wrote:
> Everyone,
> 
> There has been some discussion about one aspect of the ITU
> liaison, but no discussion on what I consider the more important part.
> 
> ITU invented a term "GAL" (originally "GCA") in order not to
> use the term "PW" without our permission. If we grant this
> permission, then the ITU will happily call the transport
> entities in the Y.gal draft
> - PWs.
> If we have a single segment PW with VCCV, the ITU regards
> this as two functions -
>   a "termination function" that adds and monitors the VCCV
> OAM Which is the PW, the adapted native service before adding
> the OAM (the "link connection"), or after adding it (the "trail")?
> I prefer the trail, but then the question arises as to what
> happens if we do not use VCCV. Then, according to the regular
> definitions, there is no "trail", and thus no PW ?
> There is the possibility of claiming that if we use a CW and
> thus there is the POSSIBILITY of using VCCV, this is still a
> trail, but then what do we call the case when there is no CW ?
> 
> Next, for the multisegment PW case, the multisegment trail is
> the PW (assuming VCCV travels from T-PE to T-PE).

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 30 May 2007 19:09:35 +0300

Matthew, 

> The assumption is that you have an inter-AS MPLS tunnel between the
S-PEs.

Then this assumption should be made explicit,
and the dual S-PE case predicated on this being the case.

However, I am not sure that this case is the most prevalent one,
and even when it does exist, I am not sure what signaling (if any)
can be assumed to run over this inter-AS tunnel.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 30 May 2007 19:17:10 +0300

Ben, 

I fully agree that we should align terminology,
at least to help potential readers better understand documents
from both forums.

I would like to understand what you are suggesting
that PWE should liaise back to Q7/13.

At least four possibilities seem not to contradict your wording:

1) A PW is either a PW or a LC. Pick which ever is best for your
purposes.

2) A PW can be either a PW or a LC. Please do not pin it down,
   as we want it sometimes to be one, and sometime the other.

3) We haven't thought about it very much. 
    Please advise as to which you believe is more useful
    and we will consider adopting.

4) A new construct (transport function) is being defined
    which is neither/both. 

Y(J)S

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, May 30, 2007 17:24
To: Yaakov Stein; [email-masked]
Subject: RE: [PWE3] SG13 liaison on pseudowires

Yaakov,

Ben

Yaakov Stein <mailto:[email-masked]> wrote:
> term "PW" without our permission. If we grant this permission, then 
> the ITU will happily call the transport entities in the Y.gal draft
> - PWs.
> I think we should encourage such use of the PW terminology (remember 
> that in the past the ITU used such terms as
> If we have a single segment PW with VCCV, the ITU regards this as two 
> functions -
>   a "termination function" that adds and monitors the VCCV OAM Which 
> is the PW, the adapted native service before adding the OAM (the "link

> connection"), or after adding it (the "trail")?
> I prefer the trail, but then the question arises as to what happens if

> we do not use VCCV. Then, according to the regular definitions, there 
> is no "trail", and thus no PW ?
> There is the possibility of claiming that if we use a CW and thus 
> there is the POSSIBILITY of using VCCV, this is still a trail, but 
> then what do we call the case when there is no CW ?
> 
> Next, for the multisegment PW case, the multisegment trail is the PW 
> (assuming VCCV travels from T-PE to T-PE).

---

From: <[email-masked]>
Date: Wed, 30 May 2007 18:04:41 +0100

Yaakov,

My understanding of how PWE3 currently use the term PW would be (a
slightly modified) (2) - "A PW can be either a Trail or a NC/LC. Please
do not pin it down, as we want it sometimes to be one, and sometimes the
other."

I hope that clarifies.

Ben

Yaakov Stein <mailto:[email-masked]> wrote:
> Ben,
> 
> I fully agree that we should align terminology, at least to
> help potential readers better understand documents from both forums.
> 
> I would like to understand what you are suggesting that PWE
> should liaise back to Q7/13.
> 
> 1) A PW is either a PW or a LC. Pick which ever is best for
> your purposes.
> 
> 4) A new construct (transport function) is being defined     which is
> neither/both. 
> 
> Y(J)S

---

From: <[email-masked]>
Date: Wed, 30 May 2007 19:14:56 +0100

Guys....this is getting messy.  Functional architecture descriptions of
layer networks are quite specific as to what is adaptation and what is
trail termination.  Both of these functions in layer network X occur at
the end-points...adaptation is what is required to map a given client to
a given server, and trail termination is specific to the server (and
only the server...this is where layer network X's OAM must live).  And
of course this model is fully recursive, ie a LC in layer N is formed by
a NC (trail) in layer N-1, etc to the duct.

Both the adaptation and trail termination functions required are a
function of the nature of network mode considered:
-	as a client AND server pair for adaptation, or 
-	server (only) for trail termination.

These functions are NOT the same for all the network modes.

The only reason I see folks having some difficulty here is that the PW
construct started off life as a pure adaptation of a non-IP_or_MPLS
client to MPLS (and some folks thought it would also be cool to have the
same adaptation to an IP server....hmmm).  So PWs were most definitely
NOT a layer network when they were created (and they are were ONLY
necessary because of the way MPLS was defined to treat IP and MPLS
clients differently).

However, go multi-hop with PWs and they become a full blown layer
network.....and this requires they now be defined as such (big change).
So, IF PWs are now a layer network (seems so) then it makes no sense to
talk about adaptation OR trail termination as options because BOTH
functions are present, ie whether they are 1 hop or N hops.  How good
they are as functions is a different issue.

BTW this is also why VCCV only belongs as OAM to the PW layer
network....this is added/removed at PW trail termination points...and it
has nothing to do with MPLS.

If none of the above makes sense, have look at G.805... or better still,
read Chapter 3 of Reid/Sexton 'Broadband Networking'.

regards, Neil

> Sent: 30 May 2007 18:05
> To: [email-masked]; [email-masked]
> My understanding of how PWE3 currently use the term PW would 
> be (a slightly modified) (2) - "A PW can be either a Trail or 
> a NC/LC. Please do not pin it down, as we want it sometimes 
> to be one, and sometimes the other."
> 
> I hope that clarifies.
> 
> Ben
> 
> > I fully agree that we should align terminology, at least to help 
> > potential readers better understand documents from both forums.
> > 
> > I would like to understand what you are suggesting that PWE should 
> > liaise back to Q7/13.
> > 
>  which is

---

From: [email-masked]
Date: Thu, 31 May 2007 15:31:38 +0800

Yaakov, Matthew

I agree, it's a bit hard to find a good method to provide a inter-as 
tunnel from existing techniques. And in RFC 3985, the PSN tunnel must 
exist between any two PEs. But I still think PSN tunnel can not be used 
between two directly connected ASBRs, just like the PHP situation. The 
above can be an option for PSN tunnel requirement for PWE3 in RFC3985. 
After all, this kind of senario is most popular for the deployment. If PSN 
tunnel is not existed between two ASBRs, then signaling for setting up PSN 
tunnel need not be enabled between two ASBRs.

For details, please refer this draft:  
http://tools.ietf.org/wg/pwe3/draft-jin-pwe3-pw-inter-as-ext-00.txt

Best Regards
Jin Lizhong

..............................................
ZTE Corporation
Add:   No.68 Zijinghua Rd,Yuhuatai District, 
       Nanjing. P.R.China.
Zip:   210012
Mail:  [email-masked]
.............................................. 

"Yaakov Stein" <[email-masked]>
2007-05-31 00:09
 
        To:     <[email-masked]>
        cc:     [email-masked], [email-masked]
        Subject:        RE: [PWE3] SG13 liaison on pseudowires

Matthew, 

Y(J)S

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: [email-masked]
Date: Thu, 31 May 2007 11:20:23 +0100

Jin,

Thanks for the pointer to your draft.

There is a difference between choosing not to use a PSN tunnel because
S-PEs are directly attached, as per the option in RFC 4447, and saying that
a PSN tunnel cannot be used between directly connected ASBRs.  I agree that
there are limitations, but there are various ways to enable it to be
established. For example, you can use a static route on the ASBR, or you
can statically configure the tunnel. The MS-PW architecture supports mixing
and matching of tunnel segments.

Using an inter-AS tunnel on a particular segment is probably less of a
challenge than expecting two providers to share ownership and management of
a single S-PE.

Regards,

Matthew

[email-masked] wrote on 31/05/2007 08:31:38:

> tunnel from existing techniques. And in RFC 3985, the PSN tunnel
> must exist between any two PEs. But I still think PSN tunnel can not
> be used between two directly connected ASBRs, just like the PHP
> situation. The above can be an option for PSN tunnel requirement for
> PWE3 in RFC3985. After all, this kind of senario is most popular for
> the deployment. If PSN tunnel is not existed between two ASBRs, then
> signaling for setting up PSN tunnel need not be enabled between two
ASBRs.
>
> For details, please refer this draft:  http://tools.ietf.
> org/wg/pwe3/draft-jin-pwe3-pw-inter-as-ext-00.txt
>
>
>
> Best Regards
> Jin Lizhong
>

> ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated
> to maintain secrecy and are not permitted to disclose the contents
> of this communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this
> message are those of the individual sender.
system.

> ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated
> to maintain secrecy and are not permitted to disclose the contents
> of this communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this
> message are those of the individual sender.
system.

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Thu, 31 May 2007 17:12:36 +0300

Matthew and all,
I wonder if the situation where two providers "share ownership and
management of a single S-PE" is realistic.

Can anybody on this list definitely confirm the existence of such a
situation (or even of a situation where two providers
share ownership and management of an LSR)?

My 2c,
         Sasha   

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, May 31, 2007 1:20 PM
To: [email-masked]
Cc: [email-masked]; Yaakov Stein; [email-masked]
Subject: RE: [PWE3] SG13 liaison on pseudowires

Jin,

There is a difference between choosing not to use a PSN tunnel because
S-PEs are directly attached, as per the option in RFC 4447, and saying
that a PSN tunnel cannot be used between directly connected ASBRs.  I
agree that there are limitations, but there are various ways to enable
it to be established. For example, you can use a static route on the
ASBR, or you can statically configure the tunnel. The MS-PW architecture
supports mixing and matching of tunnel segments.

Using an inter-AS tunnel on a particular segment is probably less of a
challenge than expecting two providers to share ownership and management
of a single S-PE.

Regards,

Matthew

[email-masked] wrote on 31/05/2007 08:31:38:

> and even when it does exist, I am not sure what signaling (if any) can

> be assumed to run over this inter-AS tunnel.
>
>
> exist between any two PEs. But I still think PSN tunnel can not be 
> used between two directly connected ASBRs, just like the PHP 
ASBRs.

> Then this assumption should be made explicit, and the dual S-PE case 
> predicated on this being the case.
>
> However, I am not sure that this case is the most prevalent one, and 
> even when it does exist, I am not sure what signaling (if any) can be 
> assumed to run over this inter-AS tunnel.
>
> Y(J)S
>
> communication is confidential. Recipients named above are obligated to

> maintain secrecy and are not permitted to disclose the contents of 
> this communication to others.
> are addressed. If you have received this email in error please notify 
> the originator of the message. Any views expressed in this message are

> those of the individual sender.
system.

> communication is confidential. Recipients named above are obligated to

> maintain secrecy and are not permitted to disclose the contents of 
> this communication to others.
> are addressed. If you have received this email in error please notify 
> the originator of the message. Any views expressed in this message are

> those of the individual sender.
system.

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 31 May 2007 17:46:43 +0300

Neil, 

Thanks for the clarification, but none of what you said was in doubt.

We are talking about a CO mode (no one is talking about CL here), 
and agree that the PW is a layer network.
We have been through all of this countless times before.

We also all agree that VCCV is PW layer OAM (not MPLS). No one claimed
otherwise. 

All we are asking is to what the term PW as it is used in the IETF
corresponds.
This question resulted precisely from the functional analysis performed
(by myself, Ben, Malcolm, etc) at the ITU, in the context of Y.gal.

Y.gal defines the PW layer. It makes the concept of multisegment PWs
obvious.
It also makes various other generalizations of the original PW concept
obvious.

But I prefer to call the layer network so defined a "PW" instead of a
"GAL".

Also, I really got into wording problems when talking about the clients
of a "GAL" ;-)

Y(J)S