Subject: [PWE3] PWE over Alternative networks

From: "David Allan" <[email-masked]>
Date: Tue, 20 Mar 2007 14:03:53 -0400

Hi: <<Microsoft PowerPoint - PWE3 and Alternative PSNs.ppt.pdf>> 

Did not get to this on the agenda today and we agreed to go to the
list....

I had put together some charts to advocate for a charter update on the
subject, which I've attached.

For the time impaired, the assertion is that there is no difference
between a PWE MPLS label and a PSN MPLS label, therefore a PWE label can
run "naked" anywhere an MPLS label can run similarly inheriting the
transfer properties of the underlying network, and the charter should
simply acknowledge the case where the MPLS PSN is NULL....

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

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 21 Mar 2007 17:09:49 +0200

Just 2 comments.
 
One, Ping Pan brought this all up at IETF-60 (see
http://pwe3.tcb.net/meetings/ietf60/agenda.txt).
What he was told at the time is that the IETF doesn't explicitly talk
about Ethernet as a PSN
(not being the design authority for Ethernet), but nothing rules it out
either.
In particular, you can view it as a PHP'ed MPLS PSN.
 
Two, although this discussion was motivated by
draft-mohan-pwe3-vccv-eth-00.txt,
this draft is not limited to Ethernet PSNs.  I would not want this draft
to be held up
until Ethernet PSNs are admitted.
 
Y(J)S 

________________________________

From: David Allan [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2007 20:04
To: [email-masked]
Subject: [PWE3] PWE over Alternative networks

Comments? 
Dave

---

From: "David Allan" <[email-masked]>
Date: Wed, 21 Mar 2007 11:22:10 -0400

Hi Yaakov:

<snipped>
 
> although this discussion was motivated by
> this draft is not limited to Ethernet PSNs.  I would not want this
draft to be held up
> until Ethernet PSNs are admitted.

Agreed, both to applicability and desired outcome...

Dave

---

From: Luca Martini <[email-masked]>
Date: Thu, 22 Mar 2007 01:37:08 -0600

Dave,

The fact that we might use PHP when the MPLS PEs are adjacent does NOT 
mean that there is no PSN  or that the PSN is Null.
Nowhere in the architecture do we specify a Null PSN.

How ever I am unclear of what you are requesting. Here is a quote form 
rfc4447:

" To transmit the packet   from one pseudowire endpoint to another, the 
packet may need to
   travel through a "Packet Switched Network (PSN) tunnel"; this will
   require that an additional header be prepended to the packet."

Also note that the do not always need a tunnel label as stated in rfc4447:

"However, if the pseudowire endpoints are immediately adjacent and 
penultimate hop popping
behavior is in use, the MPLS tunnel may not be necessary.  Any sort of 
PSN tunnel can be used, as long as it is possible to transmit MPLS
packets through it.  "

So it is perfectly fine to have 2 adjacent nodes and use no MPLS tunnel 
label. In which case the label stack will consist of only one label.
By coincidence this is what the MEF has already used for MEF8 
(CEoEthernet) .

So the fact that we might not have a tunnel label under certain 
circumstances does not mean that there is no PSN.

Luca

David Allan wrote:
> ------------------------------------------------------------------------
>

---

From: "David Allan" <[email-masked]>
Date: Thu, 22 Mar 2007 04:50:07 -0400

Hi Luca:
 
A subtle distinction is that it may not be packet switched (e.g.
PWoPOS), and an MPLS PSN LDP adjacency between a mesh of directly
connected PEs simply for the purpose of handing out explicit NULLs adds
no value. So IMO there is a small ambiguity in how thing are currently
described that would be useful to eradicate.
 
So instead of simply acknowledging the dataplane aspects (1) there MAY
not be a PSN label (optional PHP),     I'd like to explcitly call out
scenarios whereby (1) there IS not a PSN label, (2) the PW MAY be
carried directly by other than a PSN, it is the first instance of
packetization and (3) the MPLS PSN is genuinely a NULL function (no
control plane adjaceny either)....
 
I thought the proposed charter change would express that...
 
hope that makes it clearer...
Dave

From: Luca Martini [mailto:[email-masked]] 
Sent: Thursday, March 22, 2007 3:37 AM
To: Allan, David (CAR:NS00)
Cc: [email-masked]
Subject: Re: [PWE3] PWE over Alternative networks

Dave,

Also note that the do not always need a tunnel label as stated in
rfc4447:

Luca

David Allan wrote: 

	Did not get to this on the agenda today and we agreed to go to
the
	list....
	
	I had put together some charts to advocate for a charter update
on the
	subject, which I've attached.
	
	For the time impaired, the assertion is that there is no
difference
	between a PWE MPLS label and a PSN MPLS label, therefore a PWE
label can
	run "naked" anywhere an MPLS label can run similarly inheriting
the
	transfer properties of the underlying network, and the charter
should
	simply acknowledge the case where the MPLS PSN is NULL....
	
	Comments?
	Dave

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 22 Mar 2007 09:13:10 +0000

From a *PWE3* point of view, what changes when you
replace a PSN with only two nodes with length of
wire. i.e. what are the consequences for the PWE3
design of explicitly rather thna implicitly recognising
the existance of the NULL-PSN?

- Stewart

---

From: "David Allan" <[email-masked]>
Date: Thu, 22 Mar 2007 05:23:47 -0400

In the context of my last post consider this snipped of RFC 4447 Luca
highlighted

Not really implicit is it?, there are a lot of pre-requisites
implied/required which I'd like to simply have the option of dispesing
with...

Cheers
Dave 

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, March 22, 2007 5:13 AM
To: Allan, David (CAR:NS00)
Cc: Luca Martini; [email-masked]
Subject: Re: [PWE3] PWE over Alternative networks

 From a *PWE3* point of view, what changes when you replace a PSN with
only two nodes with length of wire. i.e. what are the consequences for
the PWE3 design of explicitly rather thna implicitly recognising the
existance of the NULL-PSN?

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 22 Mar 2007 09:33:20 +0000

Dave

My core question question is - what changes
with regard to PWE3 itself in this context?

Is there a change to the PWE3 component of the encap
(as distinct from the PSN component), the PWE3 control
plane, the PWE3 OAM.....

i.e. what do you want to do, that you cannot do with the
existing PWE3 design, and what additional changes will you
then need to do to PWE3 to support that application?

- Stewart

---

From: Luca Martini <[email-masked]>
Date: Thu, 22 Mar 2007 05:09:21 -0600

> implied/required which I'd like to simply have the option of dispesing
What do you specifically want to "dispense with" ?
MPLS ???
:-)
Luca

---

From: "David Allan" <[email-masked]>
Date: Thu, 22 Mar 2007 08:40:21 -0400

"dispense" may be too strong a word ;-)

I had a chat with Stewart where he asked the fundamental question is
"would this have any affect on PWE protocols". As in "is this the tip of
the iceberg..". My basic response was the issue was primarily
applicablity, not changes....but if I agreed that "any sort of tunnel
could be used" is the actual status quo, there are actually two
statements in 4447 I'd like to see modified to permit a better
architectural fit with other tunnel types....

Section 5: "The PEs will establish an LDP session using the Extended
Discovery mechanism described in [LDP,
   sections 2.4.2 and 2.5]."

Extended discovery requires knowledge of peers, and assumes an
intervening IP network, it would be useful to also permit the basic
discovery mechanism to be used to eliminate that step when the peers are
directly connected and CAN discover each other...

Section 3: "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."

For some tunnel types it would be useful to be able to use a
per-interface label space for the PW, something that makes no sense when
the PW label is not the top label. This actually came up on the list
when pw-o-pbt was first posted. If PW signalling was used in a channel
associated fashion using per platform label space, we ended up with
multiple adjacencies for a single label space if there was multiple
tunnels present...

I believe those two changes would align PWE without an intervening MPLS
PSN with those MPLS features that exist with MPLS as the top label, and
is all that would actually be required to make PW protocols completely
neutral to the underlying network...

Cheers
Dave

-----Original Message-----
From: Luca Martini [mailto:[email-masked]] 
Sent: Thursday, March 22, 2007 7:09 AM
To: Allan, David (CAR:NS00)
Cc: Stewart Bryant; [email-masked]
Subject: Re: [PWE3] PWE over Alternative networks

David Allan wrote:
> penultimate hop popping behavior is in use, the MPLS tunnel may not be

> necessary.  Any sort of PSN tunnel can be used, as long as it is 
> possible to transmit MPLS packets through it.  "
>

---

From: Luca Martini <[email-masked]>
Date: Thu, 22 Mar 2007 08:30:23 -0600

David Allan wrote:
> intervening IP network, 
IP is  mostly what we use in the IETF ....
> it would be useful to also permit the basic
The peers still have to run IP , or is something else required ?

> multiple adjacencies for a single label space if there was multiple
and exactly one LDP session between two peers....
What space the label are allocated from is independent from the number 
of adjacencies.

Quoting from rfc3031:

3.14. Scope and Uniqueness of Labels
.....
"The question arises as to whether it is possible for an LSR to use
   multiple per-platform label spaces, or to use multiple per-interface
   label spaces for the same interface.  This is not prohibited by the
   architecture.  However, in such cases the LSR must have some means,
   not specified by the architecture, of determining, for a particular
   incoming label, which label space that label belongs to. "

So there is nothing stopping you from building an LSR that uses one 
per-platform label space for each of "some tunnel types"
( it would be nice if you can give me a bit more detail about what 
tunnel types you are referring to, and why ...)

Luca
> I believe those two changes would align PWE without an intervening MPLS
I still fail to see why we need any changes to meet your requirements.

Luca

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 22 Mar 2007 11:58:21 -0400

In general, I don't think that "IP-not-required" is
implied in Dave's draft as I understand it.
 
- One can run LDP to exchange PW labels
- one can manually provision the PW labels too (in which
  case LDP control signaling is not required)
 
I think both are in scope in PWE3 as well as in this draft, IMO.
 
/himanshu

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Thursday, March 22, 2007 10:30 AM
To: David Allan
Cc: [email-masked]; Stewart Bryant
Subject: Re: [PWE3] PWE over Alternative networks

David Allan wrote: 

intervening IP network, 

  

tunnels present...

and exactly one LDP session between two peers....
What space the label are allocated from is independent from the number of adjacencies.

Quoting from rfc3031:

So there is nothing stopping you from building an LSR that uses one per-platform label space for each of "some tunnel types"
( it would be nice if you can give me a bit more detail about what tunnel types you are referring to, and why ...)

Luca

Luca

Cheers

Dave

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

From: Luca Martini [ mailto:[email-masked]] 

David Allan wrote:

highlighted

  

  

with...

MPLS ???

:-)

Luca

Cheers

Dave

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

From: Stewart Bryant [ mailto:[email-masked]]

  

  

- Stewart

---

From: "David Allan" <[email-masked]>
Date: Thu, 22 Mar 2007 13:26:43 -0400

HI Luca

IP is  mostly what we use in the IETF .... 
I'd agree with mostly, we also use any network that can carry IP and
insist on applying control planes to these as well......

	 it would be useful to also permit the basic
	discovery mechanism to be used to eliminate that step when the
peers are
	directly connected and CAN discover each other...  

Would be nice if configration could be eliminated where not required...
extended discovery 
requires apriori knowledge of the peer which basic does not...
 
Why does extended discovery exist?
RFC 3036 2.4       -  An extended discovery mechanism used to locate
LSRs that are not directly connected at the link level.

For some tunnel types it would be useful to be able to use a
per-interface label space for the PW, something that makes no sense when
the PW label is not the top label. This actually came up on the list
when pw-o-pbt was first posted. If PW signalling was used in a channel
associated fashion using per platform label space, we ended up with
multiple adjacencies for a single label space if there was multiple
tunnels present...
 and exactly one LDP session between two peers.... 
RFC 3036 section 2.2.3
      When an LSR uses LDP to advertise more than one label space to
      another LSR it uses a separate LDP session for each label space

Quoting from rfc3031:

IMO that looks like a piece of 3031 rubber that did not exactly hit the
road....3036 only has one identifier for the per platform space so there
is no way to define multiple per platform spaces. 3036 (cannot find
exact stricture) implies only one adjacency per label space per set of
peers. So 4447 tells me only per platform label space and only one
adjacency. I suppose I can define different LSR IDs per per platform
space but that seems a bit strange....

Not actually leaping out at me from the above
 
If I have multiple paths between peers say for TE/QoS  purposes, and I
wish to specify which path a PW is associated with, I need either a
common channel signalling model (which if it exists today I am not aware
of, pw signalling says nothing about the underlying PSN) or channel
associated signalling.  For simplicity I considered the latter as it is
conveniently independent of the underlying network....I'm open to
suggestion, but the ones I've seen so far do not appear to solve the
problem...with the excetion of possibly using multiple LSR-IDs in label
space adverts...
 
Dave

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 29 Mar 2007 08:14:52 -0400

> list….
> I had put together some charts to advocate for a charter update on  
> the subject, which I've attached.
>
> label can run "naked" anywhere an MPLS label can run similarly  
> inheriting the transfer properties of the underlying network, and  
> the charter should simply acknowledge the case where the MPLS PSN  
> is NULL….
	Dave,

	I do not think it is a good idea to remove the ownership of the  
supported
PSNs  from PWE3, which your slides recommend doing.

	--Tom

> Comments?
> Dave
>
> <Microsoft PowerPoint - PWE3 and Alternative PSNs.ppt.pdf>

---

From: "David Allan" <[email-masked]>
Date: Thu, 29 Mar 2007 09:12:25 -0400

HI Tom:
 
I'm simply suggesting that PWs can be directly adapted onto any network
layer that can carry IP/MPLS, which is the defacto situation
today....and what feedback I've gotten in this discussion so far
suggests it is implicit in the wording of 4447...
 
cheers
Dave

From: Thomas D. Nadeau [mailto:[email-masked]] 
Sent: Thursday, March 29, 2007 8:15 AM
To: Allan, David (CAR:NS00)
Cc: [email-masked]
Subject: Re: [PWE3] PWE over Alternative networks

the list.... 

	I had put together some charts to advocate for a charter update
on the subject, which I've attached. 

	For the time impaired, the assertion is that there is no
difference between a PWE MPLS label and a PSN MPLS label, therefore a
PWE label can run "naked" anywhere an MPLS label can run similarly
inheriting the transfer properties of the underlying network, and the
charter should simply acknowledge the case where the MPLS PSN is
NULL....

Dave, 

--Tom

	Comments? 
	Dave