Subject: RE: MPLS PID

From: "Ron Cohen" <[email-masked]>
Date: Wed, 26 Mar 2003 14:17:04 +0200

Stewart,

I'd like to defer the discussion on whether it was right or wrong for
MPLS to have an MPLS PID or not to a different Email. I want to try and
address the applications issue.

Suppose we do not adopt the 4 bit PID suggestion, and we use the 4 bits
in the control word for other purposes. 

Lets look at the most problematic application, the IP load balancer.

A provider that has an MPLS core has two options:

1. Run Pseudo-Wires on LSPs on which IP load balance is not enabled.
2. Run Pseudo-Wires flows on top of IP.

Both options seems very reasonable for me. Why should a provider do
otherwise?

Thanks
Ron

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: Wednesday, March 26, 2003 1:08 PM
> To: Ron Cohen
> Cc: PWE3 (IETF)
> Subject: Re: [PWE3] MPLS PID
> 
> 
> Ron
> 
> Ron Cohen wrote:
> > Stewart,
> > 
> > I went over your SF arch presentation. I have doubts regarding the 
> > introduction of a requirement/suggestion for an all zero PID field 
> > within the PWE3 control word. My doubts relates both to the 
> scope of 
> > this work as well as for the applications you are 
> describing. Since I 
> > haven't been to the SF IETF, please forgive me in advance if these 
> > issues have already been discussed.
> > 
> > 
> > MPLS PID scope:
> > --------------
> > In your presentation you describe a requirement/suggestion 
> for an MPLS 
> > PID, that allows a network node to distinguish between an 
> IPv4, IPv6 
> > and PWE3 stream. The Multi-Protocol part of MPLS stands for 
> carrying 
> > any network protocol on top of MPLS, including possibly IPX, CLNS, 
> > etc. Therefore, what you are proposing is introduction of an MPLS 
> > Protocol Identifier, which I believe has a much larger 
> scope than just 
> > the PWE3 WG.
> 
> All this is correct, and the failure to include an MPLS PID 
> was an error that is apparent now that the IETF is 
> standardizing payloads other than IP over MPLS.
> 
> 
> > 
> > 1. Would you agree that this is an MPLS WG item? Has this 
> requirement 
> > (MPLS PID) been discussed in the MPLS WG before / are there 
> any drafts 
> > written?
> 
> George notes that the MPLS WG has discussed this in the past, 
> and rejected the idea. However this appears to be a mistake.
> 
> > 
> > 2. If so, would 4 bits suffice for an MPLS PID?
> 
> Four bits is a compromise, that would probably work. We are 
> stuck with a situation where we have IPv4 and IPv6 carried 
> directly in MPLS, so the minimum is to just exclude from the 
> first nibble of the MPLS payload values that would alias with 
> those payloads. To allow any MPLS payload value other than 4 
> or 6 in the first nibble is messy and does not allow us (the 
> IETF) scope for future work.
> 
> After the meeting is was suggested that the right way forward 
> would be to use the term version
> 
> as in :
> 
> " Version:  4 bits
> 
>      "The Version field indicates the format of the internet 
> header.  This
>      "document describes version 4."
> 
> (RFC 791)
> 
> and
> 
> " Version              4-bit Internet Protocol version number = 6."
> 
> (RFC 1883)
> 
> Reclaiming version 0 allows us to co-exist with IP over MPLS, 
> whilst minimizing the amount of rework. How the other 13 
> values are allocated is indeed an IANA issue, although there 
> is a case for reclaiming a further value for OAM. When we 
> have used the first 14, then we can use the last value as a 
> version extension identifier.
> 
> 
> > 
> > 
> > Applications:
> > ------------
> > You list a number of applications that require IP flow recognition, 
> > including load balancing, billing, and protection against network 
> > abuse and attacks. I would like to better understand if these 
> > applications indeed require the introduction of the PID field.
> 
> There are no drafts that I am aware that call out this 
> requirement, but there are drafts that call out the need to 
> analyze IP packets in the network (i.e. the output of the 
> ipfix and psamp WG). It seems unlikely that these functions 
> would not be required to operate correctly in an MPLS 
> network, but to do so they need to know the packet type.
> 
> The provision of flow based load balancing is a vendor 
> feature that is found in MPLS networks, that will missorder 
> PWE3 flows without appropriate payload type identification.
> 
> 
> > For example, are these applications edge applications?
> 
> Netflow is in the core routers of at least two vendors.
> 
> 
> > Do these applications run on all LSPs,
> > or are sensitive to BE LSP vs. LSP with priority? Do you run these 
> > applications on TE paths?
> 
> As far as I know they run on all LSPs.
> 
> 
> > 
> > 1. Are there any drafts that describe these applications?
> > 
> 
> The drafts that I have seen assume that the router knows that it has
> an IP packet, and this is the facility that I am keen to preserve.
> 
> > 2. If not, could you elaborate on each application, its scope, etc?
> 
> In the limit, the situation is that with all IETF payloads defined
> to date we have the ability to accurately perform deep packet 
> analysis,
> and that this feature is increasingly used. I think that we 
> discard this 
> capability at out peril.
> 
> Stewart
> 
>