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

From: Luca Martini <[email-masked]>
Date: Tue, 10 Jul 2007 16:14:29 -0600

Hello!

More comments inline.

Ali Sajassi (sajassi) wrote:
> Hi Attila,
>
> Thanks for your comments. Please see my reply inline .... 
>
>   
>> -----Original Message-----
>> From: Attila Takacs (IJ/ETH) [mailto:[email-masked]] 
>> Sent: Tuesday, July 10, 2007 9:41 AM
>> To: Luca Martini (lmartini); Ali Sajassi (sajassi)
>> Subject: Some comments on draft-martini-pwe3-802.1ah-pw-00.txt
>>
>> Hi Luca and Ali,
>>
>> I just saw your draft on the pwe3 agenda...
>> It is a useful proposal, please find some 
>> comments/suggestions below which you might consider for a new 
>> revision.
>>
>> Best regards,
>> Attila
>> Ps.:I noticed that this is a 00 version, so sorry if you 
>> think the comments are too editorial
>>
>>
>> -Section 2, it seems to be more a terminology/definition 
>> section than acronyms The following definitions would be 
>> useful as well: 
>>
>> Service Instance Drop Eligibility Indicator (I-DEI): A field 
>> of the I-TAG which identifies the Service Instance Drop 
>> Eligibility of the frame in the 802.1ah (PBBN) domain.
>>
>> Service instance priority code point (I-PCP): A field of the 
>> I-TAG which identifies the service instance priority of the 
>> frame in the 802.1ah
>> (PBBN) domain.
>>
>> I-tagged Service Interface: A 802.1ah (PBBN) interface type 
>> over which an I-TAG immediately follows the destination and 
>> source MAC addresses in the header of the Ethernet frames.
>>
>>     
>
>   
Yes,  I also agree , we'll add these.
> Agree, since they are used in the text, it make sense to define them up
> front.
>
>   
>> A note may be appropriate saying that: These definitions will 
>> be removed in later versions by a reference to the 
>> appropriate IEEE standard.
>>
>>     
>
> I think it still would be good to keep these definitions in the draft
> for sake of completeness.
>
>
>   
Yes, It's really a compromise between how much we repeat in a document , 
and how much we want the document to be clear.

I usually err more on the clear side.

>> -Section 4 Applicability
>> In the first paragraph I'm considering if "I-SID to I-SID" 
>> should not be changed to "I-tagged interface to I-tagged 
>> interface". I recognize that this might be more limiting from 
>> an AC point of view but isn't this the intention?
>>
>>     
>
> "I-SID to I-SID" is correct since it is used to connect two I-SID aware
> forwarder rather than two Acs - e.g., AC may not be an I-tagged service
> interface but still we want to provide full-mesh of PW on a per I-SID
> basis.
>
>   
We can certainly change this definition , but in general the other encap 
drafts are written with respect to an AC.
I just wanted to keep this one consistent.

>> After this paragraph something like "In contrast to the VLAN (tagged
>> mode) where 2^12 customer service instances can be 
>> distinguished, the I-SID in the I-TAG increases scalability 
>> by allowing 2^24 service instances." might highlight one 
>> important aspect of the VLAN and I-SID scenario. 
>>
>>     
>
> Since we are using one PW per I-SID, this scalability aspect of I-tagged
> is not used in our case.
>
>   
>> In the discussion further below in Section 4 "I-SID aware" 
>> forwarders should be "I-TAG aware" forwarders. For instance 
>> for the QoS discussions not only the I-SID but also the I-PCP 
>> and I-DEI may be considered.
>>
>> Further, in the case of native CFM Ethernet OAM and PW OAM 
>> interworking I can imagine that the No Customer Addresses 
>> (NCA) field of the I-TAG may be considered by the NSP and/or 
>> forwarder.
>>
>>     
>  
> Agree.
>
>   
ok.
>> -Regarding Sections 5 and 6, I do not see the benefit of 
>> repeating general PW encapsulation procedures. In my read 
>> only 6.2 provides new information about the I-tagged mode all 
>> other discussion could be removed with no harm and instead a 
>> pointer to the already defined PW procedures could be added. 
>> (Do I mis something?)
>>
>>     
>
> I guess it is there for sake of completeness. It is up to Luca to decide
> what to do with it.
>
>   
I think that I would like to avoid too many recursive reference to other 
documents. This document needs to explain how to implement the PW 
without too many references.

>   
>> It would be beneficial to add a figure focusing on the 
>> I-tagged Ethernet header and its PW encapsulation, something 
>> like this: 
>>
>> 	AC				PW
>> 	        Forwarder
>> ------------		------------
>> |   Data   |    		|   Data   | 
>> |----------|		|----------|
>> |Other TAGs|		|Other TAGs|
>> |----------|  		|----------|
>> |  I-TAG   | ----|	|  I-TAG   |
>> |----------|     |	|----------|
>> |  SA MAC  |     |	|  SA MAC  | 
>> |----------|     |	|----------|
>> |  DA MAC  |     |	|  DA MAC  |
>> ------------     |	|----------|
>> 		     +-->	|Encap (CW)|
>> 		     |	|----------|
>> 		     +-->	|   Demux  |
>> 		 		|----------|
>> 		     		|PSN tunnel|
>> 				------------
>>
>>
>>
>>     
Yes, this is a very good idea.  Is this figure what we want ? No other 
tags shown ?

Thanks.
Luca

>  
> Agree, I think such figure would be helpful.
>
> Thanks again for your comments,
> Ali
>
>   
>>
>>     
>
>   

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

---

From: "Attila Takacs (IJ/ETH)" <[email-masked]>
Date: Wed, 11 Jul 2007 18:11:08 +0200

Hi Luca, Ali,
please find my comments inline [at]
Best regards,
Attila

> From: Luca Martini [mailto:[email-masked]] 
> Sent: Wednesday, July 11, 2007 12:14 AM
> To: Ali Sajassi (sajassi)
> Cc: Attila Takacs (IJ/ETH); PWE3 WG (E-mail)
> Subject: Re: Some comments on draft-martini-pwe3-802.1ah-pw-00.txt
> 
> Hello!
> 
> More comments inline.
> 
> comments/suggestions below 
> >> which you might consider for a new revision.
> >>
> >> Best regards,
> >> Attila
> >> Ps.:I noticed that this is a 00 version, so sorry if you think the 
> >> comments are too editorial
> >>
> >>
> section than 
> >> acronyms The following definitions would be useful as well:
> >>
> >> Service Instance Drop Eligibility Indicator (I-DEI): A 
> field of the 
> >> I-TAG which identifies the Service Instance Drop 
> Eligibility of the 
> >> Service instance priority code point (I-PCP): A field of the I-TAG 
> >> which identifies the service instance priority of the frame in the 
> >> 802.1ah
> >> (PBBN) domain.
> >>
> >> I-tagged Service Interface: A 802.1ah (PBBN) interface type over 
> >> which an I-TAG immediately follows the destination and source MAC 
> >> addresses in the header of the Ethernet frames.
> >>
> >>     
> >
> >   
> > Agree, since they are used in the text, it make sense to 
> define them 
> > up front.
> >
> >   
> >> A note may be appropriate saying that: These definitions will be 
> >> removed in later versions by a reference to the appropriate IEEE 
> >> standard.
> >>
> >>     
> >
> Yes, It's really a compromise between how much we repeat in a 
> document , and how much we want the document to be clear.
> 
> interface". 
> >> I recognize that this might be more limiting from an AC 
> point of view 
> >> but isn't this the intention?
> >>
> >>     
> >
> > "I-SID to I-SID" is correct since it is used to connect two I-SID 
> > aware forwarder rather than two Acs - e.g., AC may not be 
> an I-tagged 
> > service interface but still we want to provide full-mesh of PW on a 
> > per I-SID basis.
> >
> >   
> We can certainly change this definition , but in general the 
> other encap drafts are written with respect to an AC.

[AT] I would say if the forwarder is based on the I-SID then it may be
better to limit the AC to be I-tagged. On the other hand, even if over
the AC VLAN tagged frames arrive an entity may strip the VLAN TAG
entirely (e.g., the NSP) before presenting the frame to the forwarder.
This latter case seems to be fine as well.

> distinguished, the 
> >> I-SID in the I-TAG increases scalability by allowing 2^24 service 
> >> instances." might highlight one important aspect of the VLAN and 
> >> I-SID scenario.
> >>
> >>     
> >
> > Since we are using one PW per I-SID, this scalability aspect of 
> > I-tagged is not used in our case.
> >
> >   
> >> forwarders should be "I-TAG aware" forwarders. For 
> instance for the 
> >> QoS discussions not only the I-SID but also the I-PCP and 
> I-DEI may 
> >> be considered.
> >>
> >> -Regarding Sections 5 and 6, I do not see the benefit of repeating 
> >> general PW encapsulation procedures. In my read only 6.2 
> provides new 
> >> information about the I-tagged mode all other discussion could be 
> >> removed with no harm and instead a pointer to the already 
> defined PW 
> >> procedures could be added.
> >> (Do I mis something?)
> >>
> >>     
> >
> > I guess it is there for sake of completeness. It is up to Luca to 
> > decide what to do with it.
> >
> >   
> I think that I would like to avoid too many recursive 
> reference to other documents. This document needs to explain 
> how to implement the PW without too many references.
> 
> >   
> >> It would be beneficial to add a figure focusing on the I-tagged 
> >> Ethernet header and its PW encapsulation, something like this:
> >>
> >> 	AC				PW
> >> 	        Forwarder
> Yes, this is a very good idea.  Is this figure what we want ? 
> No other tags shown ?
> 
[AT] I think there shouldn't be any other tags below the I-TAG when the
frame is presented to the forwarder.

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Wed, 11 Jul 2007 11:05:12 -0700

More comments inline ...

> Sent: Wednesday, July 11, 2007 9:11 AM
> Cc: PWE3 WG (E-mail)
> Subject: RE: Some comments on draft-martini-pwe3-802.1ah-pw-00.txt
> 
> Hi Luca, Ali,
> > Yes, It's really a compromise between how much we repeat in 
> a document 
> > , and how much we want the document to be clear.
> > 
> > We can certainly change this definition , but in general the other 
> > encap drafts are written with respect to an AC.
> [AT] I would say if the forwarder is based on the I-SID then 
> it may be better to limit the AC to be I-tagged. On the other 
> hand, even if over the AC VLAN tagged frames arrive an entity 
> may strip the VLAN TAG entirely (e.g., the NSP) before 
> presenting the frame to the forwarder.

For VPLS application, another way of looking at this is that the PE is
modeled as having I-component connected to a forwarder similar to the
model presented in bridge-interop draft. So, the AC can be a regular
802.1Q or 802.1ad port; whereas, the forwarder is based on I-SID (e.g.,
a full-mesh of PW per I-SID).

> repeating 
> > I think that I would like to avoid too many recursive reference to 
> > other documents. This document needs to explain how to 
> implement the 
> > PW without too many references.
> > 
> > >   
> [AT] I think there shouldn't be any other tags below the 
> I-TAG when the frame is presented to the forwarder.
> 

The frame format as shown is good enough. If additional tag is needed
such as B-tag, then it gets imposed by the egress PE.

Cheers,
Ali

---

From: "Attila Takacs (IJ/ETH)" <[email-masked]>
Date: Thu, 12 Jul 2007 17:14:17 +0200

Hi Ali,
Ok, I see your point with the VPLS scenario.
Thanks,
Attila 

> From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
> Sent: Wednesday, July 11, 2007 8:05 PM
> To: Attila Takacs (IJ/ETH); Luca Martini (lmartini)
> Cc: PWE3 WG (E-mail)
> For VPLS application, another way of looking at this is that 
> the PE is modeled as having I-component connected to a 
> forwarder similar to the model presented in bridge-interop 
> draft. So, the AC can be a regular 802.1Q or 802.1ad port; 
> whereas, the forwarder is based on I-SID (e.g., a full-mesh 
> of PW per I-SID).
> 
> > 
> reference to 
> I-tagged 
> > [AT] I think there shouldn't be any other tags below the I-TAG when 
> > the frame is presented to the forwarder.
> > 
> 
> The frame format as shown is good enough. If additional tag 
> is needed such as B-tag, then it gets imposed by the egress PE.
> 
> Cheers,
> Ali
> 
> > > Thanks.
> > > Luca
> > > 
> > > >

---

From: "KOMPELLA Vach" <[email-masked]>
Date: Mon, 23 Jul 2007 14:02:10 -0500

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  

> Sent: Tuesday, July 10, 2007 3:14 PM
> Subject: [PWE3] Re: Some comments on 
> draft-martini-pwe3-802.1ah-pw-00.txt
> 
> Hello!
> 
> More comments inline.
>

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Mon, 23 Jul 2007 22:58:06 -0700

Vach,

I think you are missing the point that in case of a raw-mode PW, when
you remove the VLAN tag you still end up with a valid Ethernet frame;
however, there is no equivalent for I-tagged frames - e.g., when you
remove the I-SID from an I-tagged frame, you end up with an invalid
Ethernet frame. Besides this, refer to the other reasons in the draft as
to why have the new PW type.

-Ali 

> From: KOMPELLA Vach [mailto:[email-masked]] 
> Sent: Monday, July 23, 2007 12:02 PM
> Subject: RE: [PWE3] Re: Some comments on 
> 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.
>

---

From: "KOMPELLA Vach" <[email-masked]>
Date: Tue, 24 Jul 2007 02:16:17 -0500

So don't use the raw mode.  Since we have the tagged mode, we might as
well find a good use for it.

-Vach  

> Sent: Monday, July 23, 2007 10:58 PM
> To: KOMPELLA Vach; Luca Martini (lmartini)
> I think you are missing the point that in case of a raw-mode 
> PW, when you remove the VLAN tag you still end up with a 
> valid Ethernet frame; however, there is no equivalent for 
> I-tagged frames - e.g., when you remove the I-SID from an 
> I-tagged frame, you end up with an invalid Ethernet frame. 
> Besides this, refer to the other reasons in the draft as to 
> why have the new PW type.
> 
> -Ali 
>  
> 
> > ethernet services became a well-defined, those hardware limitations 
> > were overcome, and the tagged PW has already become obsolete.
> >

---

From: Cao Wei <[email-masked]>
Date: Tue, 24 Jul 2007 17:01:10 +0800

Hi Ali,
    I agree with you that a new mode for 802.1ah should be considered.  NSP can do something but I don't think it can 
cover all necessary functionalities.
   Here are a few comments about the draft. 
   1. In "Applicability Statement " section,  why is only homogeneous Ethernet frame supported? 
   2. And is there a need to do some extension for LDP for PE request/ability exchanging?
  
    Since I am not in Chicago and the audio file is not put to web site yet, I don't know the opinions from other people. I would
like to see this draft going forward. In fact I have made a presentation and proposed a draft (draft-cao-pwe3-eth-802.1ah-00.txt) 
in IETF 67 for similar topic.  

Cao Wei
  
----- Original Message ----- 
From: "Ali Sajassi (sajassi)" <[email-masked]>
To: "KOMPELLA Vach" <[email-masked]>; "Luca Martini (lmartini)" <[email-masked]>
Cc: "Attila Takacs (IJ/ETH)" <[email-masked]>; "PWE3 WG (E-mail)" <[email-masked]>
Sent: Tuesday, July 24, 2007 1:58 PM
Subject: RE: [PWE3] Re: Some comments on draft-martini-pwe3-802.1ah-pw-00.txt

Vach,

-Ali

---

From: "BALUS Florin" <[email-masked]>
Date: Tue, 24 Jul 2007 08:51:05 -0500

Ali, Luca,

I agree with Vach: tagged mode matches the requirements for the ITAG.  

>From a VPLS perspective the ITAG is an extended 24 bits tag identified
at the NSP by a new Ethertype. Different from the Qtag modes, for the
ITAG there is just one mode of operation that needs to be performed as
Ali correctly suggested below: i.e. ITAG always stays in the PWE3 frame.
So there is no need to differentiate further through signaling the
processing as this matches tagged mode behavior. 

Also from hallway discussions I realized people think we did the
tagged/raw mode to signal the use of qtag as service delimitation at
ingress NSP. That was not the case as both raw/tagged modes may/may not
use the qtag as service delimitation. This is a choice driven by NSP
configuration. Same for the ITAG: i.e. if I want to use the ITAG as
service delimitation, I configure the NSP accordingly.

Florin

> Sent: Tuesday, July 24, 2007 12:16 AM
> To: Ali Sajassi (sajassi); Luca Martini (lmartini)
> So don't use the raw mode.  Since we have the tagged mode, we 
> might as well find a good use for it.
> 
> -Vach  
> 
> > Ethernet frame.
> why have 
> > the new PW type.
> method to

---

From: "BALUS Florin" <[email-masked]>
Date: Tue, 24 Jul 2007 09:06:36 -0500

Hi Cao Wei,
See in line...

> From: Cao Wei [mailto:[email-masked]] 
> Sent: Tuesday, July 24, 2007 2:01 AM
> To: Ali Sajassi (sajassi); KOMPELLA Vach; Luca Martini (lmartini)
> Subject: Re: [PWE3] Re: Some comments on 
>     I agree with you that a new mode for 802.1ah should be 
> considered.  NSP can do something but I don't think it can 

We always had this function out of scope for all the PWs. This is purely
an NSP function.

> request/ability exchanging?

Any new requirement should be documented and understood. If we follow
the logic we used for the other PW types I do not see any need for that.
   
>     Since I am not in Chicago and the audio file is not put 
> to web site yet, I don't know the opinions from other people. 
> I would like to see this draft going forward. In fact I have 
> made a presentation and proposed a draft 
> (draft-cao-pwe3-eth-802.1ah-00.txt)

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Tue, 24 Jul 2007 08:19:18 -0700

Yes, tag-mode for I-SID is called I-tag PW :-) e.g., service delimiter
is the I-SID and not the B-VID.

-Ali

---

From: "BALUS Florin" <[email-masked]>
Date: Tue, 24 Jul 2007 10:39:38 -0500

No, tag-mode for ISID should be called I-tagged NSP. :)

Choosing the type of tag to use as a service delimiter is again an NSP
function that does not need to be signaled if we are to follow the logic
we used up to now for PW.

We had in fact to deal in the past with different tags based on the
ethertypes (8100, 9100, 88a8) and the meaning of the QoS bits - DEI/CFI.
We did not have that signaled in the PW type.  

Same with the ITAG: i.e. reading the etype tells you all the story.
Florin

> Sent: Tuesday, July 24, 2007 10:19 AM
> Yes, tag-mode for I-SID is called I-tag PW :-) e.g., service 
> delimiter is the I-SID and not the B-VID.
> 
> -Ali 
> 
> > > > > > Thanks again for your comments, Ali
> > > > > >
> > > > > >   
> > > > > >>
> > > > > >>     
> > > > > >
> > > > > >   
> > > > > 
> > > > > 
> > > > >

---

From: Luca Martini <[email-masked]>
Date: Tue, 24 Jul 2007 11:49:17 -0600

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:
>> Eligibility of the 
>>>> frame in the 802.1ah (PBBN) domain.
>>>>
>>> I think it still would be good to keep these definitions in 
>>>       
>> the draft 
>>     
>>>> After this paragraph something like "In contrast to the 
>>>>         
>> VLAN (tagged
>>

---

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

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: 
>>

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 24 Jul 2007 22:33:57 +0300

Luca,
 
As I asked yesterday, can you explain the scenario where this is needed
?
 
I was assuming that you wanted to support internal internal links to a
PBBN
with MPLS, in the case where there is an ISID but no BVID.
 
But, in that case the B-DA is sufficient information for the switching,
since the ISID is only used by the BEB (backbone edge switch).
 
If switching other than on B-DA is required at the intermediate bridges,
then the BVID will used. A B-TAG looks just like an S-TAG,
and so can be handled by the existing VLAN-aware mode.
 
If you want to replace the entire PBBN edge-to-edge,
then you don't need 1ah at all, just a regular Ethernet PW.
 
So, for what scenario is the new mode needed ?
 
Y(J)S

________________________________

From: Luca Martini [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 20:49
To: KOMPELLA Vach
Cc: 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

Vach,

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.

	-Vach  

		-----Original Message-----
		From: Luca Martini [mailto:[email-masked]] 
		Sent: Tuesday, July 10, 2007 3:14 PM
		To: Ali Sajassi (sajassi)
		Cc: Attila Takacs (IJ/ETH); PWE3 WG (E-mail)
		Subject: [PWE3] Re: Some comments on 
		draft-martini-pwe3-802.1ah-pw-00.txt
		
		Hello!
		
		More comments inline.

			Hi Attila,
			
			Thanks for your comments. Please see my reply
inline .... 

				-----Original Message-----
				From: Attila Takacs (IJ/ETH)
[mailto:[email-masked]]
				Sent: Tuesday, July 10, 2007 9:41 AM
				To: Luca Martini (lmartini); Ali Sajassi
(sajassi)
				Subject: Some comments on
draft-martini-pwe3-802.1ah-pw-00.txt
				
				Hi Luca and Ali,
				
				I just saw your draft on the pwe3
agenda...
				It is a useful proposal, please find
some 

				which you might consider for a new
revision.
				
				Best regards,
				Attila
				Ps.:I noticed that this is a 00 version,
so sorry if you think the 
				comments are too editorial

				-Section 2, it seems to be more a
terminology/definition 

		section than 

				acronyms The following definitions would
be useful as well:
				
				Service Instance Drop Eligibility
Indicator (I-DEI): A 

		field of the 

				I-TAG which identifies the Service
Instance Drop 

		Eligibility of the 

				Service instance priority code point
(I-PCP): A field of the I-TAG 
				which identifies the service instance
priority of the frame in the 
				802.1ah
				(PBBN) domain.
				
				I-tagged Service Interface: A 802.1ah
(PBBN) interface type over 
				which an I-TAG immediately follows the
destination and source MAC 
				addresses in the header of the Ethernet
frames.

			      

			Agree, since they are used in the text, it make
sense to 

		define them 

			up front.

				A note may be appropriate saying that:
These definitions will be 
				removed in later versions by a reference
to the appropriate IEEE 
				standard.

			I think it still would be good to keep these
definitions in 

		the draft 

			  

		Yes, It's really a compromise between how much we repeat
in a 
		document , and how much we want the document to be
clear.

				-Section 4 Applicability
				In the first paragraph I'm considering
if "I-SID to I-SID" 
				should not be changed to "I-tagged
interface to I-tagged 

		interface". 

				I recognize that this might be more
limiting from an AC 

		point of view 

				        

			"I-SID to I-SID" is correct since it is used to
connect two I-SID 
			aware forwarder rather than two Acs - e.g., AC
may not be 

		an I-tagged 

			service interface but still we want to provide
full-mesh of PW on a 
			per I-SID basis.

		We can certainly change this definition , but in general
the 
		other encap drafts are written with respect to an AC.
		I just wanted to keep this one consistent.

				After this paragraph something like "In
contrast to the 

		VLAN (tagged

				mode) where 2^12 customer service
instances can be 

		distinguished, the 

				I-SID in the I-TAG increases scalability
by allowing 2^24 service 
				instances." might highlight one
important aspect of the VLAN and 
				I-SID scenario.

			Since we are using one PW per I-SID, this
scalability aspect of 
			I-tagged is not used in our case.

				In the discussion further below in
Section 4 "I-SID aware" 
				forwarders should be "I-TAG aware"
forwarders. For 

		instance for the 

				QoS discussions not only the I-SID but
also the I-PCP and 

		I-DEI may 

				be considered.
				
				Further, in the case of native CFM
Ethernet OAM and PW OAM 
				interworking I can imagine that the No
Customer Addresses
				(NCA) field of the I-TAG may be
considered by the NSP and/or 
				forwarder.

			Agree.

		ok.

				-Regarding Sections 5 and 6, I do not
see the benefit of repeating 
				general PW encapsulation procedures. In
my read only 6.2 

		provides new 

				information about the I-tagged mode all
other discussion could be 
				removed with no harm and instead a
pointer to the already 

		defined PW 

				        

			I guess it is there for sake of completeness. It
is up to Luca to 
			decide what to do with it.

		I think that I would like to avoid too many recursive 
		reference to other documents. This document needs to
explain 
		how to implement the PW without too many references.

				It would be beneficial to add a figure
focusing on the I-tagged 
				Ethernet header and its PW
encapsulation, something like this:
				
					AC
PW
					        Forwarder
				|   Data   |    		|   Data
| 
						     +-->	|Encap
(CW)|
						     |	|----------|
						     +-->	|
Demux  |
	
|----------|
						     		|PSN
tunnel|
	
------------

		Yes, this is a very good idea.  Is this figure what we
want ? 
		No other tags shown ?
		
		Thanks.
		Luca

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Tue, 24 Jul 2007 12:59:13 -0700

Yaakov,
 
There are a number of scenarios in which we would need this PW - please
refer to my draft that I presented in last IETF. However, the simplest
scenario to consider is when trying to setup PWs between two I-comp
devices connected via an MPLS network. In such case, you need to map an
I-SID to a PW since there is neither a B-VID nor any B-MAC is used for
forwarding. 
 
-Ali

	From: Yaakov Stein [mailto:[email-masked]] 
	Sent: Tuesday, July 24, 2007 12:34 PM
	To: Luca Martini (lmartini)
	Cc: PWE3 WG (E-mail); Ali Sajassi (sajassi)
	Subject: RE: [PWE3] Re: Some comments on
draft-martini-pwe3-802.1ah-pw-00.txt

	Luca,
	 
	As I asked yesterday, can you explain the scenario where this is
needed ?
	 
	I was assuming that you wanted to support internal internal
links to a PBBN
	with MPLS, in the case where there is an ISID but no BVID.
	 
	But, in that case the B-DA is sufficient information for the
switching,
	since the ISID is only used by the BEB (backbone edge switch).
	 
	If switching other than on B-DA is required at the intermediate
bridges,
	then the BVID will used. A B-TAG looks just like an S-TAG,
	and so can be handled by the existing VLAN-aware mode.

	 
	Y(J)S

	Cc: PWE3 WG (E-mail); Ali Sajassi (sajassi); Attila Takacs
(IJ/ETH)

	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.

		-Vach  

			-----Original Message-----
			From: Luca Martini [mailto:[email-masked]] 
			Sent: Tuesday, July 10, 2007 3:14 PM
			To: Ali Sajassi (sajassi)
			Cc: Attila Takacs (IJ/ETH); PWE3 WG (E-mail)
			Subject: [PWE3] Re: Some comments on 
			draft-martini-pwe3-802.1ah-pw-00.txt
			
			Hello!
			
			More comments inline.

				Hi Attila,
				
				Thanks for your comments. Please see my
reply inline .... 

				-----Original Message-----
				
				Hi Luca and Ali,

				
				Best regards,
				Attila

			section than 

			field of the 

			Eligibility of the 

				

				      

				Agree, since they are used in the text,
it make sense to 

			define them 

				up front.

				        

				I think it still would be good to keep
these definitions in 

			the draft 

				  

			Yes, It's really a compromise between how much
we repeat in a 
			document , and how much we want the document to
be clear.

				-Section 4 Applicability

			interface". 

			point of view 

				        

				"I-SID to I-SID" is correct since it is
used to connect two I-SID 
				aware forwarder rather than two Acs -
e.g., AC may not be 

			an I-tagged 

				service interface but still we want to
provide full-mesh of PW on a 
				per I-SID basis.

			We can certainly change this definition , but in
general the 
			other encap drafts are written with respect to
an AC.
			I just wanted to keep this one consistent.

			VLAN (tagged

			distinguished, the 

				        

				Since we are using one PW per I-SID,
this scalability aspect of 
				I-tagged is not used in our case.

			instance for the 

			I-DEI may 

				be considered.

				        

				Agree.

			ok.

			provides new 

			defined PW 

				        

				I guess it is there for sake of
completeness. It is up to Luca to 
				decide what to do with it.

			I think that I would like to avoid too many
recursive 
			reference to other documents. This document
needs to explain 
			how to implement the PW without too many
references.

				
					AC
PW
					        Forwarder
	
|----------|
						     		|PSN
tunnel|
	
------------

			Yes, this is a very good idea.  Is this figure
what we want ? 
			No other tags shown ?
			
			Thanks.
			Luca

				Agree, I think such figure would be
helpful.