Subject: Re: [PWE3] GAL above and below the PW label

From: Luca Martini <[email-masked]>
Date: Wed, 13 Apr 2011 23:41:50 -0600

Curtis,

If we keep the GAL at the bottom of the stack to flag the fact that the
packet is GACH format , and not IP format, what is the problem ?
Surly FAT-PW would still work as most LSRs use the 2 bottom most labels
to build a hash table.

The gal = label 13 has a fixed binding to it. Do you propose that we
change that ? or just the location  of the label?

Luca

On 03/31/11 03:10, Curtis Villamizar wrote:
> In message <[email-masked]>
> David Allan I writes:
>>  
>> HI Curtis:
>>  
>> My suggestion is to avoid the GAL for PWs if it is to be a
>> homogenizing agent across TP and IP/MPLS domains in the form of
>> MS-PWs. The scenarios in which it was broken was simply a statement of
>> fact.
>>  
>> As for the problem GAL was proposed to fix (lack of CW), there are
>> solutions on the table, just not palatable...
>>  
>> D
>
> Dave,
>
> I think we are in agreement.
>
> We either use a non-GAL mechanism, or we fix GAL by removing the
> bottom of stack restriction and use GAL.
>
> I prefer the latter option, fix GAL.
>
> I support not using GAL at all in PW if GAL can't be fixed.
>
> Fixing GAL should really be an MPLS WG discussion.  The result of that
> discussion in MPLS should gate whether any PW proposal to use GAL can
> be moved forward.
>
> Curtis
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
>> Sent: Thursday, March 31, 2011 9:03 AM
>> To: Loa Andersson
>> Cc: [email-masked]
>> Subject: Re: [PWE3] GAL above and below the PW label
>>  
>>  
>> Loa, Dave, Sasha,
>>  
>> I've snipped from various posts on the thread that Sasha started.  See inline.
>>  
>> In message <[email-masked]>
>> Loa Andersson writes:
>>>  
>>> All,
>>>  
>>> missed a nuance in Sasha subject line.
>>>  
>>> We have two issues
>>>  
>>> - where the GAL is placed relative to the PW label, I  believe it is
>>>    necessary to have the GAL below the PW label.
>>>  
>>> - whether the the GAL label needs to be bottom of stack or not, it
>>>    figure that this is really a discussion if it is possible to have
>>>    a FAT label below the GAL or not. I'm not sure  about my preferences
>>>    but I think it is possible.
>>>  
>>> /Loa
>>  
>> I agree with Loa's summary.  Not putting GAL at the bottom may confuse some LSR, but putting it above the PW label is likely to be even more problematic.
>>  
>>  
>> In message <[email-masked]>
>> David Allan I writes:
>>>  
>>> It does become a new behavior, GAL with S=3D0. However the combination 
>>> of G= AL being top label at the S-PE and TTL being encoded in the PW 
>>> label means = that fate sharing is broken at every S-PE. Life only 
>>> gets a little more str= ange if there is a FAT label as well...
>>>  
>>> That being said, GAL as bottom label is broken in any ECMP 
>>> environment, whi= ch is why GAL is a TP construct.
>>>  
>>> my 2 cents
>>> D
>>  
>> Dave,
>>  
>> If GAL is broken for ECMP, which it is, then all TP OAM is broken.
>> If all it takes to fix it is simple then lets just fix it.
>>  
>> This is what we'd have to do.
>>  
>>   1) Relax the requirement that GAL be at the bottom
>>  
>>   2) Have the ingress insert GAL in the stack immediately below the
>>      label for which the measurement is made, keeping the rest of the
>>      label stack in place.
>>  
>> The only thing the midpoing LSR at a multipath (LAG, link bundle for
>> MPLS) has to do is skip over the GAL when hashing, as if the GAL wasn't there.  That will yield the same hash value and it will preserve fate-sharing across multipath.
>>  
>> I prefer that we fix things rather than complain that they are broken.
>>  
>> Curtis
>> _______________________________________________
>> pwe3 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pwe3
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: Luca Martini <[email-masked]>
Date: Thu, 14 Apr 2011 09:48:53 -0600

hello!

It appears to me that it might not be clear that I also believe that the
GAL should be at the bottom of the stack.
I know that that is not where we have it in the -00 version of the
VCCV-2 draft , but that was only an initial suggestion and we really
wanted a good discussion on this list.

We will update that document shortly.
Thanks.
Luca

---

From: David Allan I <[email-masked]>
Date: Thu, 14 Apr 2011 14:57:43 -0400

Hi Luca:

I don't think hashing two labels helps achieve consistency for OAM purposes...

FAT label + GAL does not hash to same value as PW label + FAT label...

Am I missing something?
D 

-----Original Message-----
From: Luca Martini [mailto:[email-masked]] 
Sent: Wednesday, April 13, 2011 10:42 PM
To: [email-masked]
Cc: David Allan I; [email-masked]
Subject: Re: [PWE3] GAL above and below the PW label

Curtis,

If we keep the GAL at the bottom of the stack to flag the fact that the packet is GACH format , and not IP format, what is the problem ?
Surly FAT-PW would still work as most LSRs use the 2 bottom most labels to build a hash table.

The gal = label 13 has a fixed binding to it. Do you propose that we change that ? or just the location  of the label?

Luca

On 03/31/11 03:10, Curtis Villamizar wrote:
> In message 
> <[email-masked]
> n.se>
> David Allan I writes:
>>  
>> HI Curtis:
>>  
>> MS-PWs. The scenarios in which it was broken was simply a statement 
>> of fact.
>>  
>> In message 
>> <[email-masked]
>> on.se>
>> David Allan I writes:
>>>  
>>> It does become a new behavior, GAL with S=3D0. However the 
>>> combination of G= AL being top label at the S-PE and TTL being 
>>> encoded in the PW label means = that fate sharing is broken at every 
>>> S-PE. Life only gets a little more str= ange if there is a FAT label as well...
>>>

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Apr 2011 16:46:25 -0400

> change that ? or just the location  of the label?

Right now as defined, GAL is below (after) the label for which OAM is
applied and it is also at the bottom.

I'm proposing we keep the restriction that GAL be below the label for
which OAM is applied and we drop the restriction that it be at the
bottom.  The G-Ach is after the BOS.  All labels after GAL and up to
BOS are skipped.

The value of GAL = 13 stays the same.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Apr 2011 17:29:10 -0400

In message <[email-masked]>
> FAT label + GAL does not hash to same value as PW label + FAT label...

Yes I think you are missing something.  Don't hash on reserved labels;
skip over them.

PW label + FAT label is on a payload packet.  PW label + GAL + FAT
label is on the OAM packet.  The LSP labels above that would be the
same.  At egress to the PW, the next label is GAL so its G-Ach.  On
TTL expired on a MS-PW, the next label is GAL so it is G-Ach.  Skip to
the BOS and then look at the G-Ach header if G-Ach is indicated.  As
soon as OAM is indicated it is OK to go to slow(er) path processing
(where slower may have hardware assist but is less than line rate).

Then OAM and payload take exactly the same path given the same fat-pw
label is used.  If traffic is sprayed using fat-pw label, then
randomizing the fat-pw label on OAM will check all of the paths
(eventually).  A single drop would need to be followed up by multiple
packets using the same fat-pw label, but this is easily handled by a
two way OAM such as LSP Ping.

Curtis

---

From: David Allan I <[email-masked]>
Date: Fri, 15 Apr 2011 17:35:29 -0400

OK I lost that element of the thread...

But I'm not aware of implementations that do not hash reserved labels. We seemed to have gone around this buoy back in label 14 days... And I'm not aware that anything has changed. 

If reserved labels are ignored then everything of course will fate share...regardless of the number of labels one hashes...

D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, April 15, 2011 2:29 PM
To: David Allan I
Cc: Luca Martini; [email-masked]; [email-masked]
Subject: Re: [PWE3] GAL above and below the PW label 

Curtis

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 15 Apr 2011 15:16:49 -0700

Curtis,

Inline for my comments with %Sam.

Sent from my iPad

> two way OAM such as LSP Ping.
%Sam - I am presuming here that OAM packet with GAL+fat-pw will take the same path as the data packet, which is with only fat-pw but no GAL. Not sure if the hashing could ignore the reserved label GAL. For example, even the presence of explicit null label could change the hashing behavior. I haven't come across any implementation which ignores reserved label for hashing. Hope I am wrong :D

If randomizing the path selection with fat-PW is the need, is there a requirement that OAM packets should take the same path as data packet with the same fat-PW label?

Cheers
Sam

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Apr 2011 20:37:57 -0400

In message <[email-masked]>
Luca Martini writes:
>  
> hello!
>  
> It appears to me that it might not be clear that I also believe that
> the GAL should be at the bottom of the stack.  I know that that is not
> where we have it in the -00 version of the VCCV-2 draft , but that was
> only an initial suggestion and we really wanted a good discussion on
> this list.
>  

Luca,

Please specify below the PW label (below in the MPLS sense of bottom)
and not BOS.

  MPLS style stack orientation:

     LSP label
     PW label
     GAL                           <-  this is for PW OAM
     optional fat-pw label (S=1)
     G-Ach

     LSP label
     GAL                           <-  this is for LSP OAM
     PW label
     optional fat-pw label (S=1)
     G-Ach

     LSP label
     PW label
     optional fat-pw label (S=1)
     payload

Therefore there can consistently be a rule where GAL is under the
label for which the OAM is applied.

If the hashing ignores reserved labels, then all three above take the
same path in the absence of fat-pw or take the same path given the
same value of the fat-pw label.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Apr 2011 22:00:25 -0400

> I haven't come across any implementation which ignores reserved label
> for hashing. Hope I am wrong :D

Sam,

I agree that hashing on reserved labels is common today and this
requires that the hash not be done on reserved labels.

For MPLS-TP at least at the high end, the high PPS rate and new
requirements such as shutting off PHP and keeping counters for the POP
labels force new chips (or recycling packets after POP operations and
going well under line rate).  At least a few new high end chips have
this new functionality covered and the same chips also skip over
reserved labels in doing the hash.

Can't say much more on this topic.

Curtis

---

From: Jia He <[email-masked]>
Date: Mon, 18 Apr 2011 15:28:18 +0800

Hi Cutis,

>     optional fat-pw label (S=1)

If this is for LSP OAM, there is no PW label IMHO.

B.R.
Jia

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 19 Apr 2011 01:39:25 -0400

> If this is for LSP OAM, there is no PW label IMHO.

If there is a multipath and you want the OAM to take the same path as
the payload then, yes there is a PW label.

If that PW isn't working you don't want to be testing some other path.

Curtis

---

From: Lucy yong <[email-masked]>
Date: Thu, 21 Apr 2011 14:45:02 +0000

Curtis.

If GAL only applies to MPLS-TP LSP, this is not an issue because ECMP does not apply to such LSP. All PWs within such LSP will traverse through the same path. 

For MS-PW case, there are multi segment LSPs, each has its own session OAM. No problem is there too.

If GAL also applies to LDP LSP, then I agree there is a problem. For example, for an entropy-label enabled LSP, we want to trace a flow within the LSP. But I don't know if GAL applies to such LSP since not following the MPLS-TP work. In our entropy label draft, we exclude MPLS-TP case.  

Regards,
Lucy

> Sent: Tuesday, April 19, 2011 12:39 AM
> To: Jia He
> Cc: [email-masked]; Luca Martini
> <[email-masked]
> >
> > >> >> David Allan I writes:
> > >> >>>
> > >> >>> HI Curtis:
> > >> >>>
> > >> >>> I agree with Loa's summary.  Not putting GAL at the bottom may
> confuse some LSR, but putting it above the PW label is likely to be even
> more problematic.
> > >> >>>
> > >> >>>
> > >> >>> In message
> <[email-masked]
> >
> > >> >>> David Allan I writes:
> > >> >>>>
> combination
> > >> >>> MPLS) has to do is skip over the GAL when hashing, as if the GAL
> wasn't there.  That will yield the same hash value and it will preserve
> fate-sharing across multipath.
> > >> >>>