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

From: Pablo Frank <[email-masked]>
Date: Wed, 15 Feb 2012 17:24:10 -0500

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 <[email-masked]> 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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Pablo Frank
> *Sent:* Wednesday, February 15, 2012 7:30 AM
> *To:* [email-masked]
> *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****
>
> ** **
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Feb 2012 08:22:36 +0200

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: [email-masked] [[email-masked]] On Behalf Of Pablo Frank [[email-masked]]
Sent: Thursday, February 16, 2012 12:24 AM
To: John E Drake
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Question about Entropy labels + GAL

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 <[email-masked]<mailto:[email-masked]>> 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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Pablo Frank
Sent: Wednesday, February 15, 2012 7:30 AM
To: [email-masked]<mailto:[email-masked]>
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:

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.

---

From: Pablo Frank <[email-masked]>
Date: Thu, 16 Feb 2012 11:22:05 -0500

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 <
[email-masked]> 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:* [email-masked] [[email-masked]] On Behalf Of Pablo
> Frank [[email-masked]]
> *Sent:* Thursday, February 16, 2012 12:24 AM
> *To:* John E Drake
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [mpls] Question about Entropy labels + GAL
>
>> ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload |
>> ...****
>>
>> ****
>>
>> 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.****
>>
>> ****
>>
>   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.
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Feb 2012 20:19:49 +0200

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 [[email-masked]]
Sent: Thursday, February 16, 2012 6:22 PM
To: Alexander Vainshtein
Cc: John E Drake; [email-masked]; [email-masked]
Subject: Re: [mpls] Question about Entropy labels + GAL

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 <[email-masked]<mailto:[email-masked]>> wrote:
Pablo, John and all,
A couple of comments:

Regards,

     Sasha

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Pablo Frank [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, February 16, 2012 12:24 AM
To: John E Drake
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Question about Entropy labels + GAL

Pablo

Thanks,

John

regards,
Pablo

---

From: Pablo Frank <[email-masked]>
Date: Fri, 17 Feb 2012 11:39:40 -0500

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 <
[email-masked]> wrote:

> 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.
>
>    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.
>
>
>
>  *From:* Pablo Frank [[email-masked]]
> *Sent:* Thursday, February 16, 2012 6:22 PM
> *To:* Alexander Vainshtein
> *Cc:* John E Drake; [email-masked]; [email-masked]
>
>  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
>  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 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
>>    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)
>>  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
>>
>>> unnecessary.  Following the procedures detailed in 4.3, the datapathwould 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.  ****
>>>
>>> ****
>>>
>>> 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?****
>>>
>>> ****
>>>

---

From: John E Drake <[email-masked]>
Date: Fri, 17 Feb 2012 09:14:40 -0800

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:[email-masked]]
Sent: Friday, February 17, 2012 8:40 AM
To: Alexander Vainshtein
Cc: John E Drake; [email-masked]; [email-masked]
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.

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 <[email-masked]<mailto:[email-masked]>> wrote:
Pablo,
Lots of thanks for a prompt response.

Did I miss something?

My 2c,

Sasha

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

regards,
Pablo

Regards,

     Sasha

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

regards,
Pablo

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 18 Feb 2012 08:22:37 +0200

Pablo hi,

Regarding "added complexity in trying to do a hardware implementation": I think whatever complexity is there has been added by GAL following the AL, not by the flow label (with or without ELI). This has been my main point for objecting to what has become RFC 6423.  Prior to that, you could handle an  AL exactly as you would handle  any other label according to RFC 3031 - look it up in the ILM and perform the corresponding action which would be "pop and forward an unlabeled (because your AL has been always BoS) packet to a non-MPLS forwarder defined by the AL". And yes, I know that some implementations did it differently - but the naive processing I've defined before had worked OK for PWs, VPLS and IP VPN.  And RFC 6391 did not really change that:
you could still forward a (possibly labeled) packet to a suitable non-MPLS forwarder, and  the only change you needed would be for this forwarder to ignore the remainder of the label stack whatever it happened to be if it received a labeled packet.

GAL following the AL has changed this simple logic. You really had to distinguish between ALs and "regular" labels in your MPLS forwarder. This means that your ILM lookup must now return a "this is an AL" indication to the forwarding HW. I do not see how this can be avoided if you want to support RFC 6423 - please consider the difference between the T-PE and S-PE operation in MS-PWs as an example.

At the same time once you implement that, support of flow labels on top of supporting GAL becomes trivial because, since RFC 6391, reserved labels (including GAL) MUST NOT be used as flow labels. I.e., a dumb parser would know that if it has found an AL that is not BoS, it should only check for the next label for being a reserved one. Having an ELI at this point would only make life more complicated, because you would then to distinguish specifically between GAL, ELI and, possibly, other reserved labels...

My 2c,
     Sasha

Sent: Friday, February 17, 2012 6:39 PM

Hi Sasha,

Pablo

Did I miss something?

My 2c,

Sasha

regards,
Pablo

Regards,

     Sasha

Pablo

Thanks,

John

regards,
Pablo