Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

From: Robert Rennison <[email-masked]>
Date: Sun, 31 Jul 2011 22:40:02 -0400

I do Not support the draft,

After hearing the results of the earlier user deployment  poll I thought, " ok  the way out of this mess is to migrate towards using the CW". Then I see this proposal and wondered what am I missing.  I've still not seen the light of why adding a fourth type will simplify matters, hence in the absence of me understanding how this will simplify matter versus complicate things, I'm against it.

Rob

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Sunday, July 31, 2011 12:45 AM
To: Yaakov Stein; Bocci, Matthew (Matthew); [email-masked]
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Hi all,
I do NOT support this draft for the same reasons that Yaakov has indicated.

Regards,
     Sasha

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Yaakov Stein [[email-masked]]
Sent: Friday, July 29, 2011 3:58 AM
To: Bocci, Matthew (Matthew); [email-masked]
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
I do not support !    and I can not understand how anyone can support it !

We do NOT need a fourth VCCV type, there are too many already.

I completely agree with the part that says if there is a CW then the ACh should be marked by it.

I do NOT agree that if the CW is not used then we should use a non-PW method developed for MPLS-TP.
I do NOT agree that there is any way to deprecate the use of TTL expiry to mark the ACh.
I do NOT agree that we should change mechanisms that have been widely deployed for many years now,
without an extremely pressing reason.

Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the ADDITIONAL option
for ACh marking, I might be convinced not to object as strongly.
However, since I don't think that PWs can be limited in this matter (the MPLS WG adopted the "seamless" draft)
it would be difficult to convince me that such a limitation is possible.

I would have enthusiastically support this proposal had it been brought 8 years ago.
It's too late for this now.

Y(J)S

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Thursday, July 28, 2011 21:02
To: [email-masked]
Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

This email begins a two week poll to help assess if there is consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft.

Please indicate whether or not you support adoption of this draft, and also send any comments to the PWE3 list.

This poll will end on Friday 12th August.

Regards,

Matthew & Andy

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.

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 1 Aug 2011 15:28:42 -0700

Hi,

I also don't support this draft since I don't think to solve the problem we need yet a 4th type of VCCV. The best solution is to mandate CW.

Shahram

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Rennison
Sent: Sunday, July 31, 2011 7:40 PM
To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); [email-masked]
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Rob

Hi all,

Regards,
     Sasha

Y(J)S

Regards,

Matthew & Andy

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 2 Aug 2011 07:59:07 -0400

On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote:

> Hi,
> 
> I also don’t support this draft since I don’t think to solve the problem we need yet a 4th type of VCCV. The best solution is to mandate CW.

	While I am with you, that argument went out the window during the debates we had over the past 3 IETF meetings. Operators
were very clear that they do not want to mandate the use of a CW.   Hence, Luca and I came up with this solution that narrows the 
scope to 2 modes, one that handles the CW case and one that doesn't while still both modes providing predictable OAM capabilities
for the PW.

	--Tom

> After hearing the results of the earlier user deployment  poll I thought, “ ok  the way out of this mess is to migrate towards using the CW”. Then I see this proposal and wondered what am I missing.  I’ve still not seen the light of why adding a fourth type will simplify matters, hence in the absence of me understanding how this will simplify matter versus complicate things, I’m against it.
>  
> Rob
>  
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: [email-masked]
Date: Tue, 2 Aug 2011 20:04:54 +0800

yes/support

"Bocci, Matthew (Matthew)" <[email-masked]> 
发件人:  [email-masked]
2011-07-29 02:02

收件人
"[email-masked]" <[email-masked]>
抄送

主题
[PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

This email begins a two week poll to help assess if there is consensus to 
adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft.

Please indicate whether or not you support adoption of this draft, and 
also send any comments to the PWE3 list.

Regards,

Matthew & Andy_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Mallette, Edwin" <[email-masked]>
Date: Tue, 2 Aug 2011 09:12:24 -0400

No – do not support.

I also am under the belief that mandating CW is the proper course.  The last thing I need is yet another VCCV type.

Ed

From: Shahram Davari <[email-masked]<mailto:[email-masked]>>
Date: Mon, 1 Aug 2011 18:28:42 -0400
To: Robert Rennison <[email-masked]<mailto:[email-masked]>>, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>, Yaakov Stein <[email-masked]<mailto:[email-masked]>>, "Bocci, Matthew (Matthew)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Hi,

Shahram

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Rennison
Sent: Sunday, July 31, 2011 7:40 PM
To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); [email-masked]<mailto:[email-masked]>
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Rob

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Sunday, July 31, 2011 12:45 AM
To: Yaakov Stein; Bocci, Matthew (Matthew); [email-masked]<mailto:[email-masked]>
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Hi all,

Regards,
     Sasha

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Yaakov Stein [[email-masked]<mailto:[email-masked]>]
Sent: Friday, July 29, 2011 3:58 AM
To: Bocci, Matthew (Matthew); [email-masked]<mailto:[email-masked]>
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
I do not support !    and I can not understand how anyone can support it !

Y(J)S

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Thursday, July 28, 2011 21:02
To: [email-masked]<mailto:[email-masked]>
Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Regards,

Matthew & Andy

________________________________
CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.

---

From: Luca Martini <[email-masked]>
Date: Tue, 02 Aug 2011 10:33:02 -0600

> We do NOT need a fourth VCCV type, there are too many already.
I agree that there are too many already.
Why not move to a single one ?

Luca

---

From: Giles Heron <[email-masked]>
Date: Wed, 03 Aug 2011 19:10:03 +0100

Agreed - some operators won't want to use a CW, and on that basis I support
this draft. 

Sure, it'll take a while to move away from the router alert label and TTL
approaches, but the GAL approach is definitely better than either of
those...

Giles

On 02/08/2011 12:59, "Thomas Nadeau" <[email-masked]> wrote:

>> I also don¹t support this draft since I don¹t think to solve the problem we
>> need yet a 4th type of VCCV. The best solution is to mandate CW.
> 
> While I am with you, that argument went out the window during the debates we
> had over the past 3 IETF meetings. Operators
> were very clear that they do not want to mandate the use of a CW.   Hence,
> Luca and I came up with this solution that narrows the
> scope to 2 modes, one that handles the CW case and one that doesn't while
> still both modes providing predictable OAM capabilities
> for the PW.
> 
> --Tom
> 
> 
>>  
>> Shahram
>>  
>> After hearing the results of the earlier user deployment  poll I thought,
>> ³ ok  the way out of this mess is to migrate towards using the CW². Then I
>> see this proposal and wondered what am I missing.  I¹ve still not seen the
>> light of why adding a fourth type will simplify matters, hence in the absence
>> of me understanding how this will simplify matter versus complicate things,
>> I¹m against it.
>>  
>> Rob
>>  
>> 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.

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 3 Aug 2011 12:45:29 -0700

Giles,

Adding GAL to PW requires HW change, so why not just add CW and use VVCV Type 1? 
Also what is wrong with TTL approach for non-CW?

Thx
Shahram

-----Original Message-----
From: Giles Heron [mailto:[email-masked]] 
Sent: Wednesday, August 03, 2011 11:10 AM
To: Thomas Nadeau; Shahram Davari
Cc: [email-masked]; Yaakov Stein; Robert Rennison
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Giles

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Aug 2011 19:05:11 -0400

In message <[email-masked]>
"Shahram Davari" writes:
>  
> Giles,
>  
> Adding GAL to PW requires HW change, so why not just add CW and use
> VVCV Type 1?  Also what is wrong with TTL approach for non-CW?
>  
> Thx
> Shahram

Shahram,

Adding GAL to an MPLS label stack requires hardware support.  The
hardware need not know if the label above the GAL is an MPLS label or
a PW label, just that the next label is GAL and the label over it is
not a SWAP.  Unless we are talking about incredibly inflexible parser
hardware, like none I've encounted recently, there should be no
problem noticing a GAL below the POP or PW label and then directing
the packet to OAM processing.  Any remaining labels must be removed
and hopefully no implementation neglects to look for BOS before
deciding where the payload is supposed to be.

TTL is best reserved for traceroute only (in the MS-PW case).  In this
case TTL-expire would occur where a label swap was called for and a
GAL would be below the label containing the expired TTL.  Since LDP
can have transient loops, this avoids having lots of packets sent to
the OAM engine should such a loop occur in a LDP signaled MPLS PSN.

This yield one way to do OAM with or without CW.  A GAL label is below
the label for which action is taken (POP or PW termination) or below a
label for which TTL has expired.  This method applied to LSP and PW.

I think mandating CW would be just as good a solution, but one that
was rejected so this is the best we have.

Curtis

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 3 Aug 2011 16:37:08 -0700

Hi Curtis,

You are absolutely correct if there is no Entropy label. But with Entropy label most implementation assume a Entropy label to be BoS and below the PW label. 

This draft doesn't even talk about whether the GAL should be BoS or the Entropy Label? In either case adding GAL would make the packet un-parsable by most HW.

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 03, 2011 4:05 PM
To: Shahram Davari
Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; [email-masked]; Robert Rennison
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Shahram,

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Aug 2011 19:52:58 -0400

In message <[email-masked]>
"Shahram Davari" writes:
>  
> Hi Curtis,
>  
> You are absolutely correct if there is no Entropy label. But with
> Entropy label most implementation assume a Entropy label to be BoS and
> below the PW label.
>  
> This draft doesn't even talk about whether the GAL should be BoS or
> the Entropy Label? In either case adding GAL would make the packet
> un-parsable by most HW.
>  
> Thx
> Shahram

That should be covered in this work.  At least it was covered in WG
email.  PW, then GAL, then fat-pw (aka Flow label, which is different
from Entropy label in MPLS).

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            PW Label                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              GAL                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ... additional labels (ie: fat-pw) may be present         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version|   Reserved    |  Associated Channel Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        VCCV Message Body                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The above would be a better choice.  The VCCV is always after the
label entry with BOS (S-bit = 1).

The flow label (or entropy label) must not be a reserved label.
Therefore there is no ambiguity.  In draft-ietf-pwe3-fat-pw-07 section
1.2 (page 5) you will find.

   Note that the flow label MUST NOT be an MPLS reserved label (values
   in the range 0..15) [RFC3032], but is otherwise unconstrained by the
   protocol.

The flow label below GAL is needed so that all data paths which the PW
can take are exercised by OAM (ie: LSP Ping used within VCCV).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Aug 2011 20:01:49 -0400

In message <[email-masked]>
"Bocci, Matthew (Matthew)" writes:
>  
> This email begins a two week poll to help assess if there is consensus
> to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group
> draft.
>  

+1  yes/support

(in case it wasn't already obvious)

Curtis

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 3 Aug 2011 17:06:31 -0700

Hi Curtis,

Even if we assume this format (which is not yet incorporated in the fat-pw draft), then most hardware assume  ACH is right after GAL. In this case how is the HW supposed to examine the ACH channel Type to decide how to process the packet? (unless you assume there is one engine that can process all OAM packet types such as BFD, AIS, PSC, LSP-ping, LDI, LKR, LM, DM, etc)

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 03, 2011 4:53 PM
To: Shahram Davari
Cc: [email-masked]; Giles Heron; Thomas Nadeau; Yaakov Stein; [email-masked]; Robert Rennison
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

0                   1                   2                   3

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Aug 2011 09:38:53 -0400

In message <[email-masked]>
"Shahram Davari" writes:
>  
> Hi Curtis,
>  
> Even if we assume this format (which is not yet incorporated in the
> fat-pw draft), then most hardware assume ACH is right after GAL. In
> this case how is the HW supposed to examine the ACH channel Type to
> decide how to process the packet? (unless you assume there is one
> engine that can process all OAM packet types such as BFD, AIS, PSC,
> LSP-ping, LDI, LKR, LM, DM, etc)
>  
> Thx
> Shahram

Shahram,

This doesn't need to go in the fat-pw draft.  It needs to go into the
draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic
when some other feature, fat-pw or other, puts a label under the PW
label.  The GAL goes after the PW and before the other labels.  A
proper multipath distribution will skip any reserved label and use the
rest of the label stack to load balance.  This allows spraying across
the entropy space or testing a spacific payload label stack that has
yielded trouble.

Hardware that assumes ACH is right after GAL when the S-bit is not set
on the GAL is broken.

The payload (ACH) is after the BOS (aka S-bit = 1).

The IETF has never been sympathetic of broken hardware and should not
be since we would halt progress.

If the hardware is broken, then the fat-pw label can be omitted but
only one path through any multipath would be tested.  It would still
work for TP, but not work in general.  PW does not require TP.  The
fat-pw work is explicitly done for multipath because multipath is used
a lot in deployed networks and isn't going away.

Curtis

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 4 Aug 2011 09:42:56 -0400

Curtis,

	That is a good point, and we will modify the draft to handle the FAT PW case.

	--Tom

>>>>> I also don’t support this draft since I don’t think to solve the problem we
>>>>> “ ok  the way out of this mess is to migrate towards using the CW”. Then I
>>>>> see this proposal and wondered what am I missing.  I’ve still not seen the
>>>>> I’m against it.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Aug 2011 09:52:53 -0400

In message <[email-masked]>
> 	That is a good point, and we will modify the draft to handle

Gracias mi amigo.

[which is about all I remember from HS spanish]

Curtis

---

From: Shane Amante <[email-masked]>
Date: Thu, 4 Aug 2011 08:33:53 -0600

I support this draft becoming a WG doc.

> Agreed - some operators won't want to use a CW, and on that basis I support

+1

> approaches, but the GAL approach is definitely better than either of

+1

We need a single, /unified/ PW VCCV method across all of our platforms, and the GAL approach is superior to CW.  

-shane

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 4 Aug 2011 07:42:21 -0700

I don't agree with you. This is not about broken HW. Before this draft how was one supposed to process a packet with GAL  in the middle of the label stack? 

What if this draft had decided to put GAL after entropy? Then the HW processing would have been completely different from what you are proposing on the fly now.  

You are making imaginary assumptions that HW should be able to process what was in your mind. 

I strongly object to this unnecessary draft. If you look at RFCs there are always cases that we wished we had done it differently, but we are not going to change them since in most cases like this one it is too late. Sorry but that is the fact.

Thx
Shahram

----- Original Message -----
From: Curtis Villamizar [mailto:[email-masked]]
Sent: Thursday, August 04, 2011 06:38 AM
To: Shahram Davari
Cc: [email-masked] <[email-masked]>; Giles Heron <[email-masked]>; Thomas Nadeau <[email-masked]>; Yaakov Stein <[email-masked]>; [email-masked] <[email-masked]>; Robert Rennison <[email-masked]>
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Shahram,

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Aug 2011 13:12:22 -0400

In message <[email-masked]>
"Shahram Davari" writes:
>  
> I don't agree with you. This is not about broken HW. Before this draft
> how was one supposed to process a packet with GAL in the middle of the
> label stack?

Before this draft one had to read the MPLS and PWE3 mailing list and
remember what was said.  Getting it written in a draft is the next
step.

Some of the most purist of the MPLS-TP folks have done a good job of
shouting down any suggestion that multipath had a valid place in any
network for quite some time.

> What if this draft had decided to put GAL after entropy? Then the HW
> processing would have been completely different from what you are
> proposing on the fly now.

Putting labels under GAL for the purpose of entropy was proposed on
MPLS mailing list for well over a year now, probably close to two
years, more recently on PWE3.  It is reflected in other
internet-drafts, For example, draft-villamizar-mpls-tp-multipath-00
was submitted before Maastricht but fell off the end of the agenda.

It is also in a document that we have been giving to chip vendors
under NDA stating detailed requirements starting just under a year ago.
Before that is was more verbal discussion of requirements and email.
Your friends in another part of your company were eliminated from
consideration for other reasons a while back but have heard this
requirement verbally at least.

> You are making imaginary assumptions that HW should be able to process

That is presumptious on your part.  Actually we have given this
requirement to chip vendors in our product space for about a year and
a half and I have brought this up for even longer in the MPLS WG and
more recently on PWE3.  Two chip vendors have taken these requirements
to heart and will be allowing labels under GAL plus the forwarding
functionality described in draft-villamizar-mpls-tp-multipath-01.

Of all the packet processors that we have considered, all on the very
high end of things, I know of none that have a parser that is so
inflexible that it could not deal with a label under GAL and still
find the OAM payload with nothing more than a change to the low level
programming of the parser.

I can envision that chips do exist for which the parser is too hard
coded to accommodate such a change.  Lucky for us (not luck really)
that we are not working with such a chip.  Are you?

> I strongly object to this unnecessary draft. If you look at RFCs there
> are always cases that we wished we had done it differently, but we are
> not going to change them since in most cases like this one it is too
> late. Sorry but that is the fact.

We are implementing labels under GAL for non-TP OAM in our products
regardless of your objections.  If a provider wants to use it, it will
be there.  If it can also be used for PW, all the better.  Its really
easy to do, so it doesn't hurt to do it.

If a provider prefers to use CW all the time, I'm fine with that but
we still need labels under GAL for non-TP MPLS OAM.

Curtis

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 4 Aug 2011 10:21:47 -0700

Curtis,

I am sorry but your RFI and emails are not equal to IETF RFCs and there is no reason for vendors to follow the words of an IETF participant.

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 04, 2011 10:12 AM
To: Shahram Davari
Cc: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Curtis

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 4 Aug 2011 10:29:57 -0700

Also I forgot to mention that we have super-flexible fully programmable parsers, but IETF works should not assume that everyone has such capability. Specially for an unnecessary draft such as this one.

Thx
Shharam

-----Original Message-----
From: Shahram Davari
Sent: Thursday, August 04, 2011 10:22 AM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Curtis,

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 04, 2011 10:12 AM
To: Shahram Davari
Cc: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Curtis

---

From: John E Drake <[email-masked]>
Date: Thu, 4 Aug 2011 10:56:03 -0700

>From Section 6 of the Entropy Label I-D (http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-label/?include_text=1):

"As part of the MPLS-TP work, an in-band OAM channel is defined in [RFC5586].  Packets sent in this channel are identified with a reserved label, the Generic Associated Channel Label (GAL) placed at the bottom of the MPLS label stack.  In order to use the inband OAM channel with entropy labels, this memo relaxes the restriction that the GAL must be at the bottom of the MPLS label stack.  Rather, the GAL is placed in the MPLS label stack above the entropy label so that it effectively functions as an application label."

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Curtis Villamizar
> Cc: [email-masked]'; [email-masked]'; [email-masked]'
> In message
> <[email-masked]
> m.com>
> "Shahram Davari" writes:
> >
> years, more recently on PWE3.  It is reflected in other internet-
> drafts, For example, draft-villamizar-mpls-tp-multipath-00
> It is also in a document that we have been giving to chip vendors under
> NDA stating detailed requirements starting just under a year ago.
> > You are making imaginary assumptions that HW should be able to
> process
> > what was in your mind.
>
> requirement to chip vendors in our product space for about a year and a
> half and I have brought this up for even longer in the MPLS WG and more
> recently on PWE3.  Two chip vendors have taken these requirements to
> heart and will be allowing labels under GAL plus the forwarding
> inflexible that it could not deal with a label under GAL and still find
> the OAM payload with nothing more than a change to the low level
> If a provider prefers to use CW all the time, I'm fine with that but we
> still need labels under GAL for non-TP MPLS OAM.
>
> > Thx
> > Shahram
>
> Curtis
>
>
> > Cc: [email-masked] <[email-masked]>; Giles Heron
> > <[email-masked]>; Thomas Nadeau <[email-masked]>;
> > Yaakov Stein <[email-masked]>; [email-masked] <[email-masked]>;
> Robert
> > Rennison <[email-masked]>
> > In message
> <[email-masked]
> > om.com>
> > "Shahram Davari" writes:
> > >
> > > Hi Curtis,
> > >
> > > In message
> <[email-masked]
> > > dcom.com>
> > > "Shahram Davari" writes:
> > > >
> > > > Hi Curtis,
> > > >
> > > > Entropy label most implementation assume a Entropy label to be
> BoS
> > > > and below the PW label.
> > > >
> > > > This draft doesn't even talk about whether the GAL should be BoS
> > > > or the Entropy Label? In either case adding GAL would make the
> > > > packet un-parsable by most HW.
> > > >
> > > > Thx
> > > > Shahram
> > >
> > >
> > > email.  PW, then GAL, then fat-pw (aka Flow label, which is
> > > different from Entropy label in MPLS).
> > >
> > > 0                   1                   2                   3
> > > The flow label below GAL is needed so that all data paths which the
> > > PW can take are exercised by OAM (ie: LSP Ping used within VCCV).
> > >
> > > Curtis
> > >
> > >
> > > > In message
> <[email-masked]
> > > > oadcom.com>
> > > > "Shahram Davari" writes:
> > > > >
> > > > > Giles,
> > > > >
> > > > > Adding GAL to PW requires HW change, so why not just add CW and
> > > > > use VVCV Type 1?  Also what is wrong with TTL approach for non-
> CW?
> > > > >
> > > > > Thx
> > > > > Shahram
> > > >
> > > >
> > > > Shahram,
> > > >
> > > > hardware need not know if the label above the GAL is an MPLS
> label
> > > > or a PW label, just that the next label is GAL and the label over
> > > > it is not a SWAP.  Unless we are talking about incredibly
> > > > inflexible parser hardware, like none I've encounted recently,
> > > > there should be no problem noticing a GAL below the POP or PW
> > > > label and then directing the packet to OAM processing.  Any
> > > > remaining labels must be removed and hopefully no implementation
> > > > neglects to look for BOS before deciding where the payload is
> supposed to be.
> > > >
> > > > TTL is best reserved for traceroute only (in the MS-PW case).  In
> > > > this case TTL-expire would occur where a label swap was called
> for
> > > > and a GAL would be below the label containing the expired TTL.
> > > > Since LDP can have transient loops, this avoids having lots of
> > > > packets sent to the OAM engine should such a loop occur in a LDP
> signaled MPLS PSN.
> > > >
> > > > This yield one way to do OAM with or without CW.  A GAL label is
> > > > below the label for which action is taken (POP or PW termination)
> > > > or below a label for which TTL has expired.  This method applied
> to LSP and PW.
> > > >
> > > > I think mandating CW would be just as good a solution, but one
> > > > that was rejected so this is the best we have.
> > > >
> > > > Curtis
> > > >
> > > >
> > > > > Agreed - some operators won't want to use a CW, and on that
> > > > > basis I support this draft.
> > > > >
> > > > > Sure, it'll take a while to move away from the router alert
> > > > > label and TTL approaches, but the GAL approach is definitely
> > > > > better than either of those...
> > > > >
> > > > > Giles
> > > > >
> > > > > >> I also don¹t support this draft since I don¹t think to solve
> > > > > >> the problem we need yet a 4th type of VCCV. The best
> solution is to mandate CW.
> > > > > >
> > > > > > While I am with you, that argument went out the window during
> > > > > > the debates we had over the past 3 IETF meetings. Operators
> > > > > > Luca and I came up with this solution that narrows the scope
> > > > > > to 2 modes, one that handles the CW case and one that doesn't
> > > > > > while still both modes providing predictable OAM capabilities
> > > > > > for the PW.
> > > > > >
> > > > > > --Tom
> > > > > >
> > > > > >
> > > > > >>
> > > > > >> Shahram
> > > > > >>
> > > > > >> From: [email-masked] [mailto:[email-masked]]
> On
> > > > > >> Behalf Of Robert Rennison
> > > > > >> After hearing the results of the earlier user deployment
> > > > > >> poll I thought, ³ ok  the way out of this mess is to migrate
> > > > > >> towards using the CW². Then I see this proposal and wondered
> > > > > >> what am I missing.  I¹ve still not seen the light of why
> > > > > >> adding a fourth type will simplify matters, hence in the
> > > > > >> absence of me understanding how this will simplify matter
> versus complicate things, I¹m against it.
> > > > > >>
> > > > > >> Rob
> > > > > >>
> > > > > >> From: [email-masked] [mailto:[email-masked]]
> On
> > > > > >> Behalf Of Alexander Vainshtein
> > > > > >> From: [email-masked] [[email-masked]] On
> Behalf
> > > > > >> Of Yaakov Stein [[email-masked]]
> > > > > >> I do NOT agree that we should change mechanisms that have
> > > > > >> been widely deployed for many years now, without an
> extremely
> > > > > >> pressing reason.
> > > > > >>
> > > > > >> Were the proposal to be that for PWs that traverse ONLY
> > > > > >> MPLS-TP to have the ADDITIONAL option for ACh marking, I
> > > > > >> might be convinced not to object as strongly.
> > > > > >> However, since I don't think that PWs can be limited in this
> > > > > >> matter (the MPLS WG adopted the "seamless" draft) it would
> be
> > > > > >> difficult to convince me that such a limitation is possible.
> > > > > >>
> > > > > >> From: [email-masked] [mailto:[email-masked]]
> On
> > > > > >> Behalf Of Bocci, Matthew (Matthew)
> > > > > >> This email begins a two week poll to help assess if there is
> > > > > >> consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3
> working group draft.
> > > > > >>
> > > > > >> Please indicate whether or not you support adoption of this
> > > > > >> draft, and also send any comments to the PWE3 list.
> > > > > >>
> > > > > >> 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.

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 4 Aug 2011 11:09:56 -0700

John,

If your point is that this is mentioned in an IETF draft then please look at the date of the draft as well (May 5 2011). Also this draft applies only to MPLS tunnels and not PW. I hope you don't expect people to implement an IETF draft-00 which was published just 3 months ago.

-Shahram

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Thursday, August 04, 2011 10:56 AM
To: [email-masked]; Shahram Davari
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Thu, 4 Aug 2011 11:37:58 -0700

Shahram,

That is the date at which it became a *working group draft*.  The point that Curtis made, and with which I was agreeing, was that moving the GAL from the bottom of the stack in support of ECMP has been the direction taken by both MPLS and PWE3 for at least a year.

John

Sent from my iPhone

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Thursday, August 04, 2011 11:10 AM
> To: John E Drake; [email-masked]
> If your point is that this is mentioned in an IETF draft then please
> look at the date of the draft as well (May 5 2011). Also this draft
> applies only to MPLS tunnels and not PW. I hope you don't expect people
> to implement an IETF draft-00 which was published just 3 months ago.
>
> -Shahram
>
> From Section 6 of the Entropy Label I-D
> (http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-
> label/?include_text=1):
>
> "As part of the MPLS-TP work, an in-band OAM channel is defined in
> [RFC5586].  Packets sent in this channel are identified with a reserved
> label, the Generic Associated Channel Label (GAL) placed at the bottom
> of the MPLS label stack.  In order to use the inband OAM channel with
> entropy labels, this memo relaxes the restriction that the GAL must be
> at the bottom of the MPLS label stack.  Rather, the GAL is placed in
> the MPLS label stack above the entropy label so that it effectively
> functions as an application label."
>
> Sent from my iPhone
>
>
> under
> a
> find
> we
> > > >    in the range 0..15) [RFC3032], but is otherwise unconstrained
> by
> > the
> > > >    protocol.
> > > >
> > > >
> > > > > > On 02/08/2011 12:59, "Thomas Nadeau"
> <[email-masked]>
> > wrote:
> > > > > >
> > > > > > >
> > > > > > > were very clear that they do not want to mandate the use of
> a
> > CW.   Hence,
> scope
> > > > > > >> I do NOT support this draft for the same reasons that
> Yaakov
> > has indicated.
> > > > > > >>
> > > > > > >> Regards,
> > > > > > >>      Sasha
> > > > > > >>
> > > > > > >> I completely agree with the part that says if there is a
> CW
> > > > > > >> then the ACh should be marked by it.
> > > > > > >>
> > > > > > >> I do NOT agree that if the CW is not used then we should
> use
> > > > > > >> a non-PW method developed for MPLS-TP.
> > > > > > >> I do NOT agree that there is any way to deprecate the use
> of
> > > > > > >> TTL expiry to mark the ACh.

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 4 Aug 2011 11:43:47 -0700

Hi,

I don't remember such direction and directions should be documented in stable IETF draft and RFCs. And in fact I think that direction is not correct. I think GAL should be at the bottom of the stack so I like to challenge this draft as well.

Thx
Shahram

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Thursday, August 04, 2011 11:38 AM
To: Shahram Davari; [email-masked]
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Shahram,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Thu, 4 Aug 2011 12:26:44 -0700

Shahram,

Thanks for your comments!  They are *really* incisive and helpful.

John

Sent from my iPhone

> Sent: Thursday, August 04, 2011 11:44 AM
> I don't remember such direction and directions should be documented in
> stable IETF draft and RFCs. And in fact I think that direction is not
> correct. I think GAL should be at the bottom of the stack so I like to
> challenge this draft as well.
>
>
> Thx
> Shahram
>
> That is the date at which it became a *working group draft*.  The point
> that Curtis made, and with which I was agreeing, was that moving the
> GAL from the bottom of the stack in support of ECMP has been the
> direction taken by both MPLS and PWE3 for at least a year.
>
> John
>
> Sent from my iPhone
>
>
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > > Curtis Villamizar
> > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-
> 2-
> > > 02.txt
> > >
> > >
> > > In message
> > >
> >
> > > > how was one supposed to process a packet with GAL in the middle
> of
> > > the
> > > > label stack?
> > >
> > > > are always cases that we wished we had done it differently, but
> we
> > > are
> > > > > fat-pw draft), then most hardware assume ACH is right after
> GAL.
> > In
> > > > > this case how is the HW supposed to examine the ACH channel
> Type
> > to
> > > > proper multipath distribution will skip any reserved label and
> use
> > > the
> > > > Hardware that assumes ACH is right after GAL when the S-bit is
> not
> > > set
> > > > on the GAL is broken.
> > > >
> > > > > That should be covered in this work.  At least it was covered
> in
> > WG
> > > > > |                            PW Label
> |
> > > > > |                              GAL
> |
> > > > > |
> |
> > > > > ~                        VCCV Message Body
> ~
> > > > > |
> |
> > > > > > > >> I do not support !    and I can not understand how
> anyone
> > > can support it !
> > > > > > > >>
> > > > > > > >> I would have enthusiastically support this proposal had
> it
> > > > > > > >> been brought 8 years ago.
> > > > > > > >> This email begins a two week poll to help assess if
> there
> > is

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 4 Aug 2011 12:50:42 -0700

John,

Sorry for not providing enough justification. All I wanted to point out was that this is not a done deal so vendors march to implement it.

Here is my justification for having GAL at the bottom of stack:

Having reserved labels such as GAL in the middle of stack is not elegant because the only action one has is to punt that packet to CPU. The reason is that you can never know what is below GAL since GAL is your terminating label. This is a huge restriction similar to what we had with RAL label as well. However if GAL is BoS, then you could actually process all labels before GAL and be sure there is an ACH after GAL.

Regards,
Shahram

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Thursday, August 04, 2011 12:27 PM
To: Shahram Davari; [email-masked]
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Shahram,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Thu, 4 Aug 2011 12:58:17 -0700

Shahram,

We'll take it under advisement.

Thanks,

John

Sent from my iPhone

> Sent: Thursday, August 04, 2011 12:51 PM
> Sorry for not providing enough justification. All I wanted to point out
> was that this is not a done deal so vendors march to implement it.
>
> Having reserved labels such as GAL in the middle of stack is not
> elegant because the only action one has is to punt that packet to CPU.
> The reason is that you can never know what is below GAL since GAL is
> your terminating label. This is a huge restriction similar to what we
> had with RAL label as well. However if GAL is BoS, then you could
> actually process all labels before GAL and be sure there is an ACH
> after GAL.
>
> Regards,
> Shahram
>
> > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-
> 2-
> > > 02.txt
> > >
> > > John,
> > >
> > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-
> 2-
> > > 02.txt
> > >
> > > > > I don't agree with you. This is not about broken HW. Before
> this
> > > > draft
> > > > > What if this draft had decided to put GAL after entropy? Then
> the
> > > HW
> > > > half and I have brought this up for even longer in the MPLS WG
> and
> > > more
> > > > > I strongly object to this unnecessary draft. If you look at
> RFCs
> > > > there
> > > > > not going to change them since in most cases like this one it
> is
> > > too
> > > > > > Even if we assume this format (which is not yet incorporated
> in
> > > the
> > > > > > engine that can process all OAM packet types such as BFD,
> AIS,
> > > PSC,
> > > > > This doesn't need to go in the fat-pw draft.  It needs to go
> into
> > > the
> > > > > when some other feature, fat-pw or other, puts a label under
> the
> > PW
> > > > > the entropy space or testing a spacific payload label stack
> that
> > > has
> > > > > yielded trouble.
> > > > >
> > > > > The IETF has never been sympathetic of broken hardware and
> should
> > > not
> > > > > fat-pw work is explicitly done for multipath because multipath
> is
> > > > used
> > > > > > Cc: [email-masked]; Giles Heron; Thomas Nadeau; Yaakov
> Stein;
> > > > > > [email-masked]; Robert Rennison
> > > > > > > You are absolutely correct if there is no Entropy label.
> But
> > > with
> > > > > > > This draft doesn't even talk about whether the GAL should
> be
> > > BoS
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > +-+
> > > > > > |                            PW Label
> > |
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > +-+
> > > > > > |                              GAL
> > |
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > +-+
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > +-+
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > +-+
> > > > > > |
> > |
> > > > > > ~                        VCCV Message Body
> > ~
> > > > > > |
> > |
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > +-+
> > > > > >
> > > > > > Therefore there is no ambiguity.  In draft-ietf-pwe3-fat-pw-
> 07
> > > > > > section
> > > > > >    Note that the flow label MUST NOT be an MPLS reserved
> label
> > > > (values
> > > > > > The flow label below GAL is needed so that all data paths
> which
> > > the
> > > > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein;
> [email-masked];
> > > > > > > Robert Rennison
> > > > > > > > Adding GAL to PW requires HW change, so why not just add
> CW
> > > and
> > > > > > > > use VVCV Type 1?  Also what is wrong with TTL approach
> for
> > > non-
> > > > CW?
> > > > > > > >
> > > > > > > > Thx
> > > > > > > > Shahram
> > > > > > >
> > > > > > >
> > > > > > > Shahram,
> > > > > > >
> > > > > > > Adding GAL to an MPLS label stack requires hardware
> support.
> > > The
> > > > > > > or a PW label, just that the next label is GAL and the
> label
> > > over
> > > > > > > TTL is best reserved for traceroute only (in the MS-PW
> case).
> > > In
> > > > > > > packets sent to the OAM engine should such a loop occur in
> a
> > > LDP
> > > > signaled MPLS PSN.
> > > > > > >
> > > > > > > This yield one way to do OAM with or without CW.  A GAL
> label
> > > is
> > > > > > > > > were very clear that they do not want to mandate the
> use
> > of
> > > a
> > > > CW.   Hence,
> > > > > > > > >> However, since I don't think that PWs can be limited
> in
> > > this
> > > > > > > > >> consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as
> a
> > > PWE3
> > > > working group draft.
> > > > > > > > >>
> > > > > > > > >> contains information which is CONFIDENTIAL and which
> may
> > > be
> > > > > > > > >> transmission in error, please inform us by e-mail,
> phone
> > > or
> > > > > > > > >> contains information which is CONFIDENTIAL and which
> may
> > > be
> > > > > > > > >> transmission in error, please inform us by e-mail,
> phone
> > > or

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Aug 2011 20:25:48 -0400

In message <[email-masked]>
"Shahram Davari" writes:
>  
> Curtis,
>  
> I am sorry but your RFI and emails are not equal to IETF RFCs and
> there is no reason for vendors to follow the words of an IETF
> participant.
>  
> Thanks
> Shahram

You are 100% correct.  You are free to ignore anything and everything
I say as a participant and you are free to ignore any other
participant that you choose to ignore.  Or all of them.

It is only when consensus builds that you may find that you cannot
ignore what you don't agree with.

Sometimes concensus grows gradually as IETF participants discover that
they have real world problems that need to be solved.  If you are
casting things in silicon and that silicon is going to be very
inflexible, then you need to be very good at anticipating where
concensus will grow well in advance.  Or build silicon which is more
flexible in the first place.

Curtis

> > > > > >> Alexander Vainshtein
> > > > > >> Bocci, Matthew (Matthew)

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 4 Aug 2011 17:38:06 -0700

Thanks for your advice. I suggest you take a chip design course first.

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 04, 2011 5:26 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Aug 2011 20:38:35 -0400

In message <[email-masked]>
"Shahram Davari" writes:
>  
> Also I forgot to mention that we have super-flexible fully
> programmable parsers, but IETF works should not assume that everyone
> has such capability. Specially for an unnecessary draft such as this
> one.
>  
> Thx
> Shharam

So apparently when you stated "Adding GAL to PW requires HW change"
you were standing up for some unspecified "other vendor" that may be
too shy or afraid to raise an objection.  (?)  OK.

If someone has a problem with this fairly minor change to PW and GAL
processing, they should speak for themselves.

Curtis

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 4 Aug 2011 17:47:27 -0700

Apparently you have no chip design experience. So let me give you some tutorial:

Most chips have a fixed parse and a flexible parse. Flexible parsers are expensive, since they use CAMs with limited capacity rather than memories. Therefore using flexible parsers should be limited as much possible for exceptional cases.

The question is why use such scarce resource for a feature that is not a necessity but a nice thing to have.

Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 04, 2011 5:39 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Aug 2011 23:01:39 -0400

In message <[email-masked]>
> challenge this draft as well.

Didn't someone on this list indicate that we should all be free to
ignore any single participant in IETF.

Oh - that's right - you said that.

It seems that right now you are that participant.

Rough consensus doesn't need to be unanimous.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Aug 2011 23:19:18 -0400

In message <[email-masked]>
"Shahram Davari" writes:
>  
> John,
>  
> Sorry for not providing enough justification. All I wanted to point
> out was that this is not a done deal so vendors march to implement it.
>  
> elegant because the only action one has is to punt that packet to
> CPU. The reason is that you can never know what is below GAL since GAL
> is your terminating label. This is a huge restriction similar to what
> we had with RAL label as well. However if GAL is BoS, then you could

If you are diagnosing a problem at a low level (inner label) PW or LSP
and through management action are repeatedly putting the label stack
for which trouble is occuring into on-demand OAM at the next outer
label, then you can get a few labels under GAL.

Those labels exist only for the load balance to isolate the same path.

After a LSP POP, PW termination, or TTL expire, if the next label is
GAL, it is OAM and the packet always goes up to the CPU (if there is
no microprogrammable hardware to handle OAM).  It shouldn't be too
tough to find BOS and send only that up, but it might be better to
send the label above GAL (for context), GAL, and anything below GAL.
Software (or that microprogrammable engine for OAM that maybe you have
and its extremely flexible but maybe some "other vendor" doesn't have)
should also be capable of finding BOS.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 05 Aug 2011 13:45:46 -0400

In message <[email-masked]>
> Apparently you have no chip design experience. So let me give you some

I find that amusing.

> Most chips have a fixed parse and a flexible parse. Flexible parsers
> are expensive, since they use CAMs with limited capacity rather than
> memories. Therefore using flexible parsers should be limited as much
> possible for exceptional cases.

Other chips have little or no hard coded parts of the parser.  They
don't even have hard coded notions of how Ethernet headers are
arranged though they may have logic intended to accellerate things
like MAC learning (which we don't need, but someone in a different
market would) or assist with QoS handling and TTL models (which we do
need).  These chip could just as easily parse something quite
different like PPP or GFP-F if they needed to.

> a necessity but a nice thing to have.

Don't make them so scarce since a few more gates beats a respin.

> Shahram

We are working very closely with two chip vendors.  One is using small
TCAMs and pipelining in the parser.  The other is useing very tiny
microprogrammed engines for parsing and using parallelism in their
parser.  Both are extremely flexible, have a relatively small parser
die footprint, draw reasonably low power, and are very flexible.

We are working toward a next generation of chips mostly to increase
the capacity and reduce real estate and power, however both vendors
could support this type of change in their *prior* iteration with only
a change in chip programming that is loaded at run time initialization.

There was a debate over whether GAL should be limited to BOS only well
before it became an RFC.  The wording makes it always at BOS for TP
and ambigous for non-TP.  It should not be surprising that it is now
being relaxed.  Its your problem if you missed this.

Perhaps you have hard coded parts of the parser and took some
shortcuts when doing so.  If so, that's not the WG's problem, its your
problem.  Same is true for anyone that hardcoded T-MPLS features.

We are well aware of efficiency and flexibility tradeoffs.

Curtis

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 5 Aug 2011 11:14:05 -0700

Hi Curtis,
you'vesaid:
"If you are diagnosing a problem at a low level (inner label) PW or LSP
and through management action are repeatedly putting the label stack
for which trouble is occuring into on-demand OAM at the next outer
label, then you can get a few labels under GAL."

I think I can not find case when LSP OAM will have labels below GAL.
Perhaps I'm missing some scenario. Would be great if you give a hint.

Regards,
Greg

On Thu, Aug 4, 2011 at 8:19 PM, Curtis Villamizar <[email-masked]> wrote:
>> > > > > > > > >> I also donąt support this draft since I donąt think to
>> > > solve
>> > > > > > > > >> poll I thought, ł ok  the way out of this mess is to
>> > > migrate
>> > > > > > > > >> towards using the CW˛. Then I see this proposal and
>> > > wondered
>> > > > > > > > >> what am I missing.  Iąve still not seen the light of why
>> > > > versus complicate things, Iąm against it.
>> > > > > > > > >>
>> > > > > > > > >> Rob
>> > > > > > > > >>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 5 Aug 2011 14:27:26 -0400

OK, speaking with my working group chair hat on - I don't do this very
often, but I would like to ask EVERYONE on this thread (and in the WG)
to remember that what you type is a part of the IETF process, is very
public, will be remembered forever in some archive or another, and may
even end up in a court of law. Enough said about that.

> If your point is that this is mentioned in an IETF draft then please look at the date of the draft as well (May 5 2011). Also this draft applies only to MPLS tunnels and not PW. I hope you don't ex…

The point in John's email (and others) is that while
draft-ietf-pwe3-fat-pw and draft-ietf-mpls-entropy-label are both
still drafts, they both do represent their respective working group
consensus at this point in time and take a consistent approach
regarding the placement of labels in the stack.

If anyone disagrees with this particular consensus approach, then I
would suggest starting a new email thread in both WGs to argue why
this approach is incorrect, and to propose specific changes in the
text of both drafts, and we can then determine consensus regarding the
proposed changes. I very much think that both working groups would
like to keep the two drafts consistent with each other. Or at least
the chairs certainly would. :-)

Thanks,
Andy

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 05 Aug 2011 15:32:30 -0400

> Perhaps I'm missing some scenario. Would be great if you give a hint.

Entropy label for one.

Then there is the further isolation of a problem in this email.

Curtis

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 12 Aug 2011 08:28:56 +0900

hi all,

yes, support.

--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 12 Aug 2011 08:51:45 +0900

+1

Consistent two options sound good. While we work out three plus one option in nine years, I feel that the variation to which consider legacy hardware won't advance interoperability.

Best regards,
--satoru