Subject: RE: draft-ietf-pwe3-arch-04.txt section 5.4.4

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 23 Jul 2003 14:00:34 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mustapha Aissaoui
> Sent: Wednesday, July 23, 2003 1:43 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4
> 
> 
> Eric,
> 
> Eric Rosen wrote:
> > 
> > Eric> Well, it's  another thing that  has to be  looked up at the  
> > Eric> egress PE before  you can send  the frame  out to  
> the CE,  so I  
> > Eric> think it  IS a modification to the forwarding paradigm.
> > 
> > Mustapha> It is not.  On egress, you are still moving  
> payload from a 
> > Mustapha> single PW to a  single attachment circuit. What 
> changes is  
> > Mustapha> the PID to be translated. You can view this  as 
> part of the 
> > Mustapha> payload manipulation since forwarding  is 
> essentially the same (i.e.,  all what arrives
> > Mustapha> on  that PW  goes out  on the  same AC).   
> However, the  1-to-N PW
> > Mustapha> option above is  clearly a new forwarding 
> paradigm.  That is 
> > Mustapha> why I am reluctant to go down that path.
> > 
> > We seem to  mean different things by "forwarding  paradigm".  By 
> > "forwarding paradigm", I mean "receive an MPLS  packet, look up the 
> > label, determine the rewrite string (i.e., the header 
> modifications) 
> > and the outgoing interface." So  if you  can't  determine  
> the header  
> > modifications  without looking  up something in  addition to the  
> > label, the "forwarding paradigm"  is changed. The need to look up 
> > something  other than the label may significantly impact 
> performance 
> > in certain systems, which is  why I think it important to try to 
> > avoid.
> 
> MA> Well, what you describe here is what we do in all PWE
> encapsulations. We need to interpret the header in the 
> received packet in order to create the new payload to be sent 
> out on the outgoing interface. For example, in the ATM 
> encapsulation, there is a bit which says what encapsulation 
> it is using (cell of AAL5 frame mode). 

	First, why are you creating a new payload on the outgoing
side and not just changing the payload encapsulation?  
Also, we discussed this issue during the PWE3 meeting (and I 
think Eric re-stated this above).  As I recall, it was pointed
out by several people that if the PEs remember which label has 
been bound to which VC, then you can use this information 
decapsulate and forward traffic from any VC. If you are worried 
about different ATM encap types, bind a different label to each
VC as you signal it and remember the specific encap type. When
the packets from that VC come back, you know precisely how to 
forward them out the disposition interface. I don't understand 
why this simple algorithm is insufficient to address
the case you are giving above.  Are you concerned about
running out of labels or something?

	--Tom

> As far as I am concerned, this is all part of payload 
> manipulation. Forwarding is always based on the received 
> label or attachement circuit identifier. In contrast, in the 
> 1-N option, the PE requires the knowledge of the FR DLCI plus 
> the RFC2427 PID in order to determine the outgoing PW label. 
> Is this not a change in the forwarding paradigm we currently 
> use in MPLS and PWE3?
>  
> > Note that  the distinction between 1-1  and 1-N forwarding  
> that you 
> > mention above  doesn't  impact the  "forwarding  paradigm"  as  I 
> > defined  it.
> > 
> > There are  cases in which the  forwarding paradigm (as I  
> defined it) cannot
> > work unchanged.   E.g., if the egress PE  is forwarding an 
> IP  packet out an
> > ethernet interface, it may be necessary to consult the ARP table in 
> > order to produce the rewrite string.  I think  of this as a 
> necessary 
> > evil.  What you are suggesting  is no  worse than  that, but still  
> > something that  might be worth avoiding.
> 
> MA> My main issue with the 1-N is the troubleshooting of such a
> mechanism (OAM, etc). Also, there is a concern that customer 
> traffic is split over multiple PWs and this can impact the 
> transparency of the service. 
> 
> Though, I agree that interworking between dissimilar L2 
> technologies is not trivial and there are many higher-layer 
> protocol specific issues that need to be resolved. So, I 
> think there will be many neccessary evils to deal with.
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Eric Rosen <[email-masked]>
Date: Mon, 28 Jul 2003 13:47:59 -0400

MA> Well, what you describe here is what we do in all PWE encapsulations. We
MA> need to interpret  the header in the received packet  in order to create
MA> the new payload to be sent out on the outgoing interface. 

Correct.  But I don't care what we  do before the MPLS label goes on, I only
care what  we do  after it  goes on, ;-)  since that's  the only  thing that
affects the MPLS forwarding paradigm.

So to be  consistent, I should advocate that all  reencapsulation be done by
the  ingress rather  than by  the egress.   Unfortunately, this  is  not the
position I  was taking last  week (viz., that for  FR-ethernet interworking,
the FR side should do everything). 

Okay, I see  that there is an issue to be  discussed if service interworking
gets put in the charter. 

Have  you  compared  your  proposal  with  draft-sajassi-l2vpn-interworking-
01.txt?