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

From: Stewart Bryant <[email-masked]>
Date: Mon, 14 Jul 2003 16:39:53 +0100

The only last call issue with draft-ietf-pwe3-arch-04.txt that I am aware
of is Andy's comment WRT 5.4.4

I propose the following revised text, which defines the protocol authority
identifier.

Is there consensus for this change?

Have I missed any other issues with the draft?

Stewart

5.4.4. MPLS Payload Identifier

    If technical considerations result in a PW control word that may
    alias an IP packet, the control word SHOULD be preceded by an MPLS
    payload type identifier.

    The MPLS payload type is defined as follows:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0 0 0 1| reserved = 0  |  PA   |          Protocol ID          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           As defined by PPP DLL protocol definition           |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 14: MPLS Payload Type Identifier

        PA    protocol authority for the user plane or the control plane
              protocol ID
                             0       = PPP DLL
                             1-15    = Reserved

        Protocol ID
              Protocol ID following the format defined by the protocol
              authority identified in PA.

    Bits 4 to 11 inclusive are reserved for future use and must be zero.

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 14 Jul 2003 20:10:33 +0200

Stewart,
One minor comment.
I seem to remember that ability to distinguish between PW data packets
and PW OAM packets has been mentioned as one of the possible applications 
of the "MPLS PID" in the corresponding email thread.

Taking this into account, why should bits 0-3 of the MPLS PID be set to
'0001' and not '0000' (for data)/'0001' (for OAM)? 

IMO it would not have any impact on the P routers' ability to distinguish
PW packets (data and OAM) from IPv4/IPv6 packets (which has been the
original
drive for MPLS PID).

----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Monday, July 14, 2003 5:40 PM
> To: [email-masked]
> Subject: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4
> 
> 
>         |                                                     
>           |
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 14 Jul 2003 19:22:49 +0100

> '0001' and not '0000' (for data)/'0001' (for OAM)? 

Because there is one CW (SONET) that is not ECMP safe, so some data packets
will have the PID.

Stewart

---

From: Mustapha Aissaoui <[email-masked]>
Date: Wed, 16 Jul 2003 03:33:51 -0400

Stewart,
this looks good to me. It allows future extensions such as the one
described in draft-aissaoui-extended-pid.

One minor editorial comment though. I would prefer to add the
generic format of the payload identifier as follows:

    If technical considerations result in a PW control word that may
    alias an IP packet, the control word SHOULD be preceded by an
MPLS
    payload type identifier.

    The generic format for the MPLS payload type is as follows:

     0                   1                   2                   3
   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|      rsvd.    |   PA  |            Protocol ID       
|

    Figure 14: Generic MPLS Payload Type Identifier

    PA = protocol authority for the user plane or the control plane 
         protocol ID
                       0       = PPP DLL. 
                       1-15    = Reserved

    Protocol ID = Protocol ID following the format defined by the
protocol
                  authority identified in PA.

    Bits 4 to 11 inclusive are reserved for future use and must be
zero.

    The specific format for resolving the IP aliasing uses PA = 0: 

    0                   1                   2                   3
   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1| reserved = 0  |  PA=0 |          Protocol ID         
|
   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           As defined by PPP DLL protocol definition          
|
    |                                                              
|

    Figure 15: Specific MPLS Payload Type Identifier

Regards,
Mustapha.
------------

---

From: George Swallow <[email-masked]>
Date: Wed, 16 Jul 2003 04:24:44 -0400

>     alias an IP packet, the control word SHOULD be preceded by an MPLS

What problem does this solve that just adding four bytes to your
header (in the putative case) doesn't solve?

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

---

From: [email-masked]
Date: Wed, 16 Jul 2003 18:47:22 +0100

Tom,

> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: 16 July 2003 13:23
> To: 'Mustapha Aissaoui'; 'George Swallow'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4
> 
> 
> 
> > I just send an updated slide set to Danny for my presentation 
> > this afternoon of draft-aissaoui-extended-pid. I added an 
> > example application where the translation of PID between FR, 
> > PW, and Ethernet is very useful. The main point is that in 
> > many of the installed base of L2 VPN, FR and ATM VCs carry 
> > more than one user payload (e.g., IP and IS-IS/CLNP). In 
> > those cases only, a translation of PID is useful if one one 
> > wants to have dissimilar L2 access over a PW (e.g., 
> > FR-MPLS-Ethernet). 
> 
> 	I thought that interworking was out of the scope
> in PWE3?
> 
> 	--Tom
NH=> So what if I say as an operator that interworking (both 'network' and
'service' types...and currently PWE3 is the former anyway) was pretty
important?  If bad solutions are forthcoming now in a restricted
network-interworking case, then these may not be so useful to the larger
service-interworking case.  And, just to be further clear on what is the
strategic/arch direction behind this comment, please note this:
-	there are 3 networking modes....cnls, co pkt-sw and co cct-sw;
-	all technologies map to one of these modes;
-	they are *all* needed because they all offer something different;
-	what we want is functional convergence *within* each mode (ie to
stop stovepipes, avoid nasty gateways and reduce capex/opex....so edge
service-interworking is key, hence my prior remarks), but what we don't want
is functional convergence *across* the modes, ie specifically no GMPLS
peer-model nonsense;
-	further, we want best-of-breed functions in each mode, and we will
take solutions from whichever stds body/vendors are prepared to give us
these.

regards, Neil
> 
> > 
> > I hope Danny will upload it soon so that everone will have a 
> > chance to see it before the meeting this afternoon.
> > 
> > Mustapha.
> > ----------
> > George Swallow wrote:
> > >

---

From: Eric Rosen <[email-masked]>
Date: Thu, 17 Jul 2003 15:55:40 -0400

Wei> First  of all,  what is  the  need to  demultiplex different  protocols
Wei> carried in one  DLCI to different PWs?  Is it because  you want to send
Wei> them to  different destinations?  Not  sure if the current  FR switches
Wei> (PEs) for legacy L2VPNs can demultiplex packets from a single DLCI into
Wei> different PVCs. 

If  I  understand  correctly,  what   they  are  worried  about  is  service
interworking, e.g., frame  relay on one side and ethernet  on the other.  To
do this  kind of interworking,  you need  to be able  to tell that  a packet
received on  the frame relay link  is, e.g., an  IP packet, so that  you can
put on the proper IP-in-ethernet encapsulation at the other end. 

One can't say this is "useless", the use is clear enough.  But: 

- As Tom points out, service interworking is out of scope. 

- There are  other methods of  doing service interworking (such  as carrying
  the  Frame  Relay  encaps  across   the  pw,  and  then  doing  "ordinary"
  FR-to-ethernet  translation  at  the   other  endpoint),  and  there's  no
  consensus within the WG of the best way.  

- There are other possible methods of demultiplexing, using MPLS labels. 

However, without a charter change, discussion of this topic is academic.

---

From: Mustapha Aissaoui <[email-masked]>
Date: Fri, 18 Jul 2003 16:51:08 -0400

Eric,

Eric Rosen wrote:
> 
> > There was good support to start service interworking in the L2VPN WG
> > meeting yesterday. If this happens, clearly the encpasulation and
> > signaling parts are part of the PWE3.
> 
> Sure, if  service interworking is  added to the  charter then we'll  need to
> consider it.
> 
> > In my presentation, I mentioned three options:
> > a. extend FR or Ethernet to the remote PE. This is a valid solution
> > and should be supported. The problem is there are more and more
> > Ethernet/MPLS PE products out there which do not implement anything
> > about FRoMPLS, let alone FR-Ethernet interworking.
> 
> What about doing the translation to  ethernet formats at the FR end? I don't
> think we're ready to rule this out.

I do not rule this out. I think it is also a valid option. Though, I
prefer to keep the MAC address discovery as close as possible to the
Ethernet PE.
 
> > b. split the FR VC into multiple parallel PWs (1-to-N). I guess the
> > implementation complexity and troublshooting complications of this
> > solutions are obvious.
> 
> No,  I   don't  think  that  this   is  obviously  more   complex  than  the
> alternatives.
> 
> I can see  an issue in having  to maintain state for an  increased number of
> pws, but a  slight alternative might be  to allow more than one  label to be
> used per pw, with the  different labels invoking different encapsulations at
> the  receiving endpoint.   (This  would be  something  like having  multiple
> streams on a pw, with an MPLS label for each stream.)

This starts to look more like multilink FR or Inverse Multiplexing
over ATM (IMA). I am not sure I want to go down that path. In
general, it is expected not to mess with customer traffic in a L2
service.
 
> > c. The PID translation between FR, PW, and Ethernet. In my view this
> > is the most straighforward solution. It does not change the
> > forwarding paradigm because it is still based on the label.
> 
> Well, it's another  thing that has to  be looked up at the  egress PE before
> you can send the frame out to the CE, so I think it IS a modification to the
> forwarding paradigm.

It is not. On egress, you are still moving payload from a single PW
to a single attachment circuit. What changes is the PID to be
translated. YOu can view this as part of the payload manipulation
since forwarding is essentially the same (i.e., all what arrives on
that PW goes out on the same AC).
However, the 1-to-N PW option above is clearly a new forwarding
paradigm. That is why I am reluctant to go down that path.

> My real worry about this alternative is that it might just be the tip of the
> iceberg; I don't  think we want a large "how to  interwork FR with ethernet"
> project in the IETF.

I share your concern. I personally believe that this kind of
interworking cannot be generalized. I am looking for a practical
solution for a situation that some of my customers are facing.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 23 Jul 2003 12:06:14 -0400

Eric> Well, it's  another thing that  has to be  looked up at the  egress PE
Eric> before  you can send  the frame  out to  the CE,  so I  think it  IS a
Eric> modification to the forwarding paradigm.

Mustapha> It is not.  On egress, you are still moving  payload from a single
Mustapha> PW to a  single attachment circuit. What changes is  the PID to be
Mustapha> translated. You can view this  as part of the payload manipulation
Mustapha> 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 why I
Mustapha> 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.  

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.

---

From: Mustapha Aissaoui <[email-masked]>
Date: Wed, 23 Jul 2003 13:42:38 -0400

Eric,

> performance in certain systems, which is  why I think it important to try to

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). 

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?
 
> are suggesting  is no  worse than  that, but still  something that  might be

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.

---

From: Mustapha Aissaoui <[email-masked]>
Date: Wed, 23 Jul 2003 14:30:30 -0400

"Thomas D. Nadeau" wrote:
> > 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> 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.
> >
> > 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
> 
Tom,
I am not sure we are exactly talking about the same thing here. I am
referring to a FR or ATM VC which carries more than one higher-layer
protocol and which is terminated locally at a PE. It is terminated
locally because the remote PE-CE interface is different, i.e.,
Ethernet. In this scenario, you need to identify the user payload in
a PW, packet by packet, as it changes. You cannot signal it ahead of
time because you do not have a priori knowledge of it.