Re: [PWE3] [mpls] Question about Entropy labels + GAL

[John E Drake <[e-mail]>]

Pablo,

These are some of the same conclusions to which the EL authors came.  The deployment environment for FAT labels, pt-2-pt, is more constrained than the deployment environment for ELs, any- 2-any, so presumably some of these cases could be handled in signaling, such that both endpoints know what to expect before packets start to flow.  However, it might be nice to use a reserved ELI for FAT labels in order to have a consistent data plane for both.

Thanks,

John

From: Pablo Frank [mailto:[e-mail]]
Sent: Friday, February 17, 2012 8:40 AM
To: Alexander Vainshtein
Cc: John E Drake; [e-mail]; [e-mail]
Subject: Re: [mpls] Question about Entropy labels + GAL

Hi Sasha,

Even the relatively simple set of rules that you've defined below glosses over a some added complexity in trying to do a hardware implementation.  I think we can at least agree that this is not nearly as simple as using reserved ELI (which a dumb parser can dispose of without needing to even look anything up).  I guess I'm just nervous about the lookup context of a label affecting the disposition of a label that is not necessarily next in the stack.  To me this feels like a slippery slope.  What if, in the future, we come up with more "stuff" that goes between the AL and the EL?  The permutations quickly multiply and this will ultimately impact the cost of hardware.

Just something to keep in mind as we go forward.

In any case, I think there's enough uncertainty that the authors of type-4 VCCV should probably explicitly address how they expect it to interact with flow labels.

Pablo
On Thu, Feb 16, 2012 at 1:19 PM, Alexander Vainshtein <[e-mail]<mailto:[e-mail]>> wrote:
Pablo,
Lots of thanks for a prompt response.

I think that the situation with GAL between the PW (application label) and flow label is much simpler than what you have described. This logic is based on the fact "application labels" can be easily recognized as such by the LSR that examines them during label stack parsing.

When an application label is encountered, there are just three cases:

 1.  It is BoS - nothing new, pass to the corresponding application (PW forwarder, VRF etc.) for handling. The data for this application directly follows the label stack (may include CW in the case of PW or VPLS)
 2.  Not BoS and the next label is GAL - stop parsing and pass to the "VCCV-4" handler, The data for the "VCCV-4 handler" application directly follows the label stack and starts with the ACH header.
 3.  Not BoS and the next label is not GAL - treat the next label as the "flow label", i.e. pass to the corresponding application (may include CW in the case of PW or VPLS).

In the case of MS-PWs, only T-PEs would treat the PW labels as "application labels", S-PEs would treat them as non-application labels. This is fully consistent with RFC 6073 which explains that if you want an S-PE to handle a VCCV packet, you must use VCCV Type 3 (TTL expiration) possibly combined with VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4.



In other words, there is no need for ELI with the flow label.



Did I miss something?



My 2c,

Sasha



________________________________
From: Pablo Frank [[e-mail]<mailto:[e-mail]>]
Sent: Thursday, February 16, 2012 6:22 PM
To: Alexander Vainshtein
Cc: John E Drake; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

Subject: Re: [mpls] Question about Entropy labels + GAL

Thanks Sasha.  I completely concur with your points 1 and 2.

As for point #3, that seems like the logical conclusion.  However, I think there's still a bit of awkwardness around implementing this.  Both the original entropy-label draft and RFC 6391 have assumed a simple pop-pop logic when you encounter an entropy-enabled AL or a flow-enabled PW.  The moment GAL, or any other reserved label gets thrown into the mix, the label disposition logic gets suddenly more complex.  Instead of pop-pop, the hardware will have to do more complicated logic like "IF this is a flow-enabled label AND the next label is ! GAL THEN pop-pop ELSE IF ..., etc.".  While I have very programmable hardware at my disposal, I prefer elegant and simple and this feels wrong.

It sounds like the authors of the entropy label draft have recognized this problem and are now moving towards mandating the use of a reserved ELI which unambiguously implies that the next label is entropy (so the hardware can go back to having simple pop-pop logic when it sees a reserved ELI).

Which brings me back to VCCV.  If I'm doing type-1,2,3 VCCV, the situation is unambiguous.  If I encounter any of these types of PWEs with flow-enabled, I can do a pop-pop.  If for type-4 VCCV, we assume that the GAL is between the PW label and flow label (which I think was the intent), we're back to having ugly logic to try and dispose of the GAL and flow label correctly.  A reserved ELI could help disambiguate the situation in this case but this makes running type-4 VCCV with flow labels unattractive compared to type-1 VCCV.

regards,
Pablo

On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtein <[e-mail]<mailto:[e-mail]>> wrote:
Pablo, John and all,
A couple of comments:


 1.  Following a long discussion on the PWE3 WG mailing list RFC 6423 has relaxed the original requirement for GAL being at the bottom of stack that have been defined in RFC 5586.
 2.  My reading of RFC 6391 is that it mandates the flow label to be at the bottom of the label stack for PW packets carrying user data. And it does not provide for ELI usage anywhere, be it a reserved label or a signaled one.
 3.  To the best of my understanding, the situation when GAL is used for fat PWs is not explicitly defined. Inserting GAL between the PW label and flow label (with the ACH header immediately following the label stack) seems to be fully compatible with both RFC 6423 and RFC 6391. Maybe this format should be explicitly defined as the correct one?

Regards,

     Sasha









________________________________
From: [e-mail]<mailto:[e-mail]> [[e-mail]<mailto:[e-mail]>] On Behalf Of Pablo Frank [[e-mail]<mailto:[e-mail]>]
Sent: Thursday, February 16, 2012 12:24 AM
To: John E Drake
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] Question about Entropy labels + GAL
Ah, good.  That certainly makes things more deterministic.

I guess the question now becomes how will this affect type-4 VCCV on fat pseudowires (RFC 6391)?  Will type-4 VCCV have to mandate the use of ELIs when flow labels are present?  That seems too bad since the main advantage of type-4 VCCV seems to be to save a few bytes on the wire.  This puts the overhead right back in so it may be more attractive to run fat PWEs with type-1 VCCV...

Pablo
On Wed, Feb 15, 2012 at 4:26 PM, John E Drake <[e-mail]<mailto:[e-mail]>> wrote:
Pablo,

Based upon Kireeti's update in Taipei, we seem to going towards using a reserved label for ELI and making it always required.

Thanks,

John

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Pablo Frank
Sent: Wednesday, February 15, 2012 7:30 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [mpls] Question about Entropy labels + GAL

I'm working on implementation for entropy labels and I have a question about draft-ietf-mpls-entropy-label-01.  Consider a scenario where I have received the following:

... | LSP label x | Entropy label | IPv4 payload | ...

Assume that I've signaled that the LSP label wants entropy and an ELI is unnecessary.  Following the procedures detailed in 4.3, the datapath would lookup label x and see that it is expecting a possible entropy label and since x is not BOS, it pops the next label and then begins processing the IPv4 payload.  So far, so good.

However, I believe the following is legal as well:

... | LSP label x | GAL label | Entropy label | BFD payload | ...

Alternatively, an equally vexing scenario is:

... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | ...

There are probably other reserved labels that are applicable as well.

In either case, the draft doesn't clearly state what's supposed to happen.  If I follow the procedures in 4.3, the datapath would end up popping the GAL or the explicit NULL label (thinking they are entropy labels) and would then attempt to lookup the entropy label (which would result in erroneous behaviour).   The only additional guidance that the draft gives is in section 6 where it suggests that GAL could be treated as an application label.  But that doesn't seem helpful since the LSP label must also be an application label (to handle the non-GAL case) and will always be encountered first during label disposition.  Also, presumably I don't want all GALs to expect entropy so there's an implied scoping of GAL.

It seems to me that when a datapath encounters an entropy-enabled application label or an ELI, that it essentially must do a "deferred pop of BOS label".  In other words, if the datapath encounters an entropy-enabled AL or an ELI, it must make a note of it and continue processing labels until it hits the BOS label, which it must pop.  While certainly possible, this is a lot more convoluted and difficult to implement than what is specified in the draft.  Is this really the desired behaviour?

The same question applies to type-4 VCCV with flow labels.

regards,
Pablo



This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.


This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.