Subject: RE: [PWE3] Re: Some comments on draft-martini-pwe3-802.1ah-pw-00.txt

From: "KOMPELLA Vach" <[email-masked]>
Date: Tue, 24 Jul 2007 14:24:50 -0500

Hi Andy,
 
I absolutely agree with Luca on the principle of the PW label.  Where
did I say that the PW label was not the demux? 
 
We were talking about using the I-SID as a service delimiter.  I am
simply saying that we can continue to use that as a service delimiter.
That's precisely the way we are using VLAN tags as service delimiters in
the two ethernet flavors of PWs.
 
Use the I-SID as a delimiter (let the NSP figure out how to extract the
delimiting value), find the matching PW, leave the I-SID in place, and
drop the packet into the VLAN PW type Ethernet PW.  Pop the label stack
at egress, identify the egressing port using the PW label, and since the
I-SID has not been affected in the forwarding path, it's there to be
used at the egress NSP.
 
OK - obsolete is not the right word - less preferred?  The main use I
have seen for the VLAN PW type is for preserving 802.1p bits.
 
-Vach 

________________________________

	From: Andrew G. Malis [mailto:[email-masked]] 
	Sent: Tuesday, July 24, 2007 11:59 AM
	To: Luca Martini
	Cc: KOMPELLA Vach; PWE3 WG (E-mail); Ali Sajassi (sajassi);
Attila Takacs (IJ/ETH)
	Subject: Re: [PWE3] Re: Some comments on
draft-martini-pwe3-802.1ah-pw-00.txt

	I absolutely agree with Luca here on the principle for the PW
label.  I don't agree with Vach that the tagged PW is "obsolete".
	
	In addition, section 4 of RFC 4448 is clear on the treatment of
frames under both the raw and tagged modes, and Vach's proposal doesn't
conform to either mode as currently defined.
	
	Cheers,
	Andy
	
	At 7/24/2007 11:49 AM -0600, Luca Martini wrote:

		Vach,
		
		PWs are built on the principle that we use the mpls
label as the de-multiplexer.
		We can use a number of other header fields  for the same
purpose , but that does not make it a PW.
		For example , why not use the Frame-Relay DLCI to
determine the egress port for a frame-relay PW and have just one label
for the PE/service instance  ?
		We came to the conclusion a long time ago, that it is
more efficient to use the MPLS label as the de-multiplexer field.
		Not all devices will incorporate expensive hardware that
can perform the double lookup. This has been one of the main reasons why
PWs become so popular.

		Luca

		KOMPELLA Vach wrote: 

			I don't see why we need this.  It sounds like a
signaling
			method to
			optimize what may or may not be achievable in
hardware.
			
			It's deja vu all over again with the tagged
Ethernet PW which pretty
			much was defined, IMHO, because of harware
limitations.  By the
			time
			ethernet services became a well-defined, those
hardware limitations were
			overcome, and the tagged PW has already become
obsolete.
			
			I say just process the I-Tag in the NSP.
			
			-Vach  

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 24 Jul 2007 15:42:14 -0400

Vach,

I get what you're proposing, but that's a change of behavior from that currently defined in RFC 4448. In current raw mode, there is never a service-delimiting tag on the wire, and there is a one-to-one relationship between a physical interface at the ingress PE and a PW.  In current tagged mode, there is always a service-delimiting VLAN tag on the wire, and that VLAN tag (not I-SID) is used in the ingress PE to choose the proper PW for the frame.

Cheers,
Andy

At 7/24/2007 02:24 PM -0500, KOMPELLA Vach wrote:
>Hi Andy,
> 
>I absolutely agree with Luca on the principle of the PW label.  Where did I say that the PW label was not the demux? 
> 
>We were talking about using the I-SID as a service delimiter.  I am simply saying that we can continue to use that as a service delimiter.  That's precisely the way we are using VLAN tags as service delimiters in the two ethernet flavors of PWs.
> 
>Use the I-SID as a delimiter (let the NSP figure out how to extract the delimiting value), find the matching PW, leave the I-SID in place, and drop the packet into the VLAN PW type Ethernet PW.  Pop the label stack at egress, identify the egressing port using the PW label, and since the I-SID has not been affected in the forwarding path, it's there to be used at the egress NSP.
> 
>OK - obsolete is not the right word - less preferred?  The main use I have seen for the VLAN PW type is for preserving 802.1p bits.
> 
>-Vach 
> 
>
>
>----------
>Cc: KOMPELLA Vach; PWE3 WG (E-mail); Ali Sajassi (sajassi); Attila Takacs (IJ/ETH)
>Subject: Re: [PWE3] Re: Some comments on draft-martini-pwe3-802.1ah-pw-00.txt
>
>I absolutely agree with Luca here on the principle for the PW label.  I don't agree with Vach that the tagged PW is "obsolete".
>
>In addition, section 4 of RFC 4448 is clear on the treatment of frames under both the raw and tagged modes, and Vach's proposal doesn't conform to either mode as currently defined.
>
>Cheers,
>Andy
>
>>PWs are built on the principle that we use the mpls label as the de-multiplexer.
>>We can use a number of other header fields  for the same purpose , but that does not make it a PW.
>>For example , why not use the Frame-Relay DLCI to determine the egress port for a frame-relay PW and have just one label for the PE/service instance  ?
>>We came to the conclusion a long time ago, that it is more efficient to use the MPLS label as the de-multiplexer field.
>>Not all devices will incorporate expensive hardware that can perform the double lookup. This has been one of the main reasons why PWs become so popular.
>>
>>
>>Luca
>>
>>
>>
>>KOMPELLA Vach wrote: 
>>>
>>>
>>>I don't see why we need this.  It sounds like a signaling
>>>
>>>method to
>>>
>>>optimize what may or may not be achievable in hardware.
>>>
>>>
>>>It's deja vu all over again with the tagged Ethernet PW which pretty
>>>
>>>much was defined, IMHO, because of harware limitations.  By the
>>>
>>>time
>>>
>>>ethernet services became a well-defined, those hardware limitations were
>>>
>>>overcome, and the tagged PW has already become obsolete.
>>>
>>>