Subject: [Pals] Soliciting reviews for draft-ietf-pals-vccv-for-gal-00.txt

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 22 Dec 2014 09:33:11 -0500

PALSers,

i know that you would all like a little something to distract you from the
holidays ... :-). Well, maybe not. But anyway, Stewart recently revised the
VCCV for GAL draft (see below), and while short (just four pages of real
content), we would like to have a good indication that it represents WG
consensus, so we need at least some of you out there to read it and
comment, even if that comment is "I've reviewed it and looks great to me".
As I noted, it's a short draft, so it shouldn't take all that long.

You can read the draft at
http://tools.ietf.org/html/draft-ietf-pals-vccv-for-gal-00 .

Thanks,
Stewart and Andy

---------- Forwarded message ----------
From: <[email-masked]>
Date: Wed, Dec 17, 2014 at 12:00 PM
Subject: I-D Action: draft-ietf-pals-vccv-for-gal-00.txt
To: [email-masked]
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Pseudowire And LDP-enabled Services
Working Group of the IETF.

        Title           : VCCV Default CC Types
        Authors         : Thomas D. Nadeau
                          Luca Martini
                          Stewart Bryant
        Filename        : draft-ietf-pals-vccv-for-gal-00.txt
        Pages           : 8
        Date            : 2014-12-17

Abstract:
   This document specifies the default Virtual Circuit Connectivity
   Verification (VCCV) (RFC5085) control channel type to be used when
   the pseudowire control word is present and when it is not present.  A
   new VCCV control channel type using the Generic Associated Channel
   Label (RFC5586) is specified for use when the control word not
   present.

   This document updates RFC4447 and RFC5085.

   Note to be removed at publication: this document started out as
   draft-ietf-pwe3-vccv-for-gal and got to version -02.  When PWE3 was
   absorbed into PALS the next version published was draft-ietf-pals-
   vccv-for-gal-00

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pals-vccv-for-gal/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pals-vccv-for-gal-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 22 Dec 2014 16:28:04 +0000

Andy, Stewart and all,
I have read the draft (which is indeed, quite short!), and I have a couple of issues with it which, IMO, the WG should resolve one way or another.

1.       I disagree with the statement in Section 4 “When the PW is a single segment PW, the TTL field of the PW Label Stack Entry (LSE) MUST be set to 2.  TTL=2, rather than the more obvious TTL=1, is used because of legacy hardware considerations.” From my POV

a.       For a single-segment PW, any TTL value excluding 1, can be safely used

b.      TTL=1 in the PW LSE  Is defined in RFC 5085 for VCCV Type 3 (which is not even mentioned in the draft) for single-segment PWs

c.       RFC 6073 also refers to VCCV Type 3 (a.k.a. the TTL-based method)for multi-segment PWs

2.       I see the proposal (in section 5) to place  GAL at the bottom of the label stack for “fat PWs” with the flow PW directly preceding it as highly problematic:

a.       It strictly contradicts RFC 6391 which explicitly states that the flow label is always at the bottom of the label stack

b.      It makes proper treatment of VCCV packets problematic as explained below:

                                                               i.      T-PEs (which are aware of flow labels) would have not just to remove the Flow Label but also to check whether  the next label is  GAL

                                                             ii.      S-PEs of MS-PWs would have to become aware of flow labels while today they may be unaware of flow labels and simply pass these labels transparently (as per Section 6 of RFC 6391)

c.       Some types of forwarding HW are known to be limited to hashing only on the bottom-of-stack label for ECMP:

                                                               i.      Normally (with both “Fat PWs” as per RFC 6391 and with the “ELI/EL scheme” introduced in RFC 6790) this is sufficient since entropy is carried in the bottom-of-stack label in both schemes

                                                             ii.      The proposal in the draft, if accepted, would break normal ECMP behavior for both these schemes with such HW.

d.      In addition:

                                                               i.      The comment about the EL/ELI scheme as being relevant just for “MPLS LSP that carry the PW” is, IMO, incorrect. The only limitation of this scheme is that it cannot be together with the PW Flow Label scheme, but this is hardly restrictive

                                                             ii.      While the proposal in the draft breaks RFC 6391, this RFC  is not even mentioned as being updated (?) by the draft.

Hopefully these comments will be useful for both the authors of the draft and for the WG.

Regards,
       Sasha
Email: [email-masked]
Mobile: 054-9266302

From: Pals [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Monday, December 22, 2014 4:33 PM
To: [email-masked]
Subject: [Pals] Soliciting reviews for draft-ietf-pals-vccv-for-gal-00.txt

PALSers,

i know that you would all like a little something to distract you from the holidays ... :-). Well, maybe not. But anyway, Stewart recently revised the VCCV for GAL draft (see below), and while short (just four pages of real content), we would like to have a good indication that it represents WG consensus, so we need at least some of you out there to read it and comment, even if that comment is "I've reviewed it and looks great to me". As I noted, it's a short draft, so it shouldn't take all that long.

You can read the draft at http://tools.ietf.org/html/draft-ietf-pals-vccv-for-gal-00 .

Thanks,
Stewart and Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, Dec 17, 2014 at 12:00 PM
Subject: I-D Action: draft-ietf-pals-vccv-for-gal-00.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Pseudowire And LDP-enabled Services Working Group of the IETF.

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

[email-masked]<mailto:[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 24 Dec 2014 10:56:59 +0000

Sasha

Many thanks for the review.

On 22/12/2014 16:28, Alexander Vainshtein wrote:
>
> Andy, Stewart and all,
>
> I have read the draft (which is indeed, quite short!), and I have a 
> couple of issues with it which, IMO, the WG should resolve one way or 
> another.
>
I have always been a fan of Ocam's Razor.
> a.        For a single-segment PW, any TTL value excluding 1, can be safely used
I agree, but two was what was explicitly stated at the WG mtg. I am 
happy with either text.
> b.       TTL=1 in the PW LSE  Is defined in RFC 5085 for VCCV Type 3 (which is not even mentioned in the draft) for single-segment PWs
I can put a ref in.
> c.        RFC 6073 also refers to VCCV Type 3 (a.k.a. the TTL-based method)for multi-segment PWs
I do not understand your concern here.
> 2.        I see the proposal (in section 5) to place  GAL at the bottom of the label stack for “fat PWs” with the flow PW directly preceding it as/highly problematic/:
Yes, but I would like a solution, since any position is problematic, and 
since both FAT and GAL both intended for Ethernet PWs we have to find a 
solution. Before I get to the detailed comments below I should state my 
mental model which is that I see the FAT label as a type of modifier for 
the PW label and assume that the h/w when it sees a FAT label it just 
discards the  following lable unchecked except to note the BoS state. 
Thus it makes sense to me to keep the two together.
> a.        It strictly contradicts RFC 6391 which explicitly states that the flow label is always at the bottom of the label stack
Good point, we will need no note an update to RFC6391.
>                                                                 i.       T-PEs (which are aware of flow labels) would have not just to remove the Flow Label but also to check whether  the next labe…
Yes, well strictly they check BoS on the FAT which they have to do anyway.
>                                                               ii.       S-PEs of MS-PWs/would have to become aware of flow labels/  while today they may be unaware of flow labels and simply pass these labels transparently (as per Section 6 of RFC 6391)
I don't understand why this would be the case other than for OAM 
processing due to TTL expiry. Is that the case that concerns you?
>                                                               ii.       The proposal in the draft, if accepted, would break normal ECMP behavior for both these schemes with such HW.
Hang on, normally the FAT is still BOS, so normally this works, but as 
stated in the draft when the GAL is present (for OAM) there is a 
problem. I don't see any way round it in non-RFC6790 networks.
>                                                                 i.       The comment about the EL/ELI scheme as being relevant just for “MPLS LSP that carry the PW” is, IMO, incorrect. The only lim…
That was what we discussed at the WG meeting, well strictly we agreed to 
be silent on the matter, but the point was that the ELI applies strictly 
to the LSP and how the LSR inspects the payload and sets teh EL value is 
a matter for the vendor.
>                                                               ii.       While the proposal in the draft breaks RFC 6391, this RFC  is not even mentioned as being updated (?) by the draft.
It will update it in the next revision.

I am however uncertain what you propose in terms of a way forward. You 
bring up some important points, but I get no sense of what you propose 
as alternatives in terms of the design and why they are better (position 
of the GAL relative to FAT, or exclusivity of the features have problems 
whichever way we call it), or indeed whether you think this draft should 
simply be abandoned?
- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 24 Dec 2014 11:48:53 +0000

Stewart,
Please see some answers inline below.

Regards,
       Sasha

From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, December 24, 2014 12:57 PM
To: Alexander Vainshtein; Andrew G. Malis
Cc: [email-masked]
Subject: Re: [Pals] Soliciting reviews for draft-ietf-pals-vccv-for-gal-00.txt

Sasha

On 22/12/2014 16:28, Alexander Vainshtein wrote:
Andy, Stewart and all,
I have read the draft (which is indeed, quite short!), and I have a couple of issues with it which, IMO, the WG should resolve one way or another.
I have always been a fan of Occam’s Razor.[[Sasha]] The same goes for me…

I agree, but two was what was explicitly stated at the WG mtg. I am happy with either text.[[Sasha]]I have looked up RFC 3985, and it states that “When a MPLS label is used as a PW Demultiplexer, setting of the TTL value [RFC3032] in the PW label is application specific”. It is not for me to decide whether the comments at the WG session are a sufficient reason to change that; but if you decide to go for that, you should mention that 3985 is updated.

b. TTL=1 in the PW LSE  Is defined in RFC 5085 for VCCV Type 3 (which is not even mentioned in the draft) for single-segment PWs
I can put a ref in.[[Sasha]] This would be nice IMO

c. RFC 6073 also refers to VCCV Type 3 (a.k.a. the TTL-based method)for multi-segment PWs
I do not understand your concern here.[[Sasha]] If you put in a reference to VCCV Type 3, this would cover this comment as well. And once should be enough.

2. I see the proposal (in section 5) to place  GAL at the bottom of the label stack for “fat PWs” with the flow PW directly preceding it as highly problematic:
Yes, but I would like a solution, since any position is problematic, and since both FAT and GAL both intended for Ethernet PWs we have to find a solution. Before I get to the detailed comments below I should state my mental model which is that I see the FAT label as a type of modifier for the PW label and assume that the h/w when it sees a FAT label it just discards the  following lable unchecked except to note the BoS state. Thus it makes sense to me to keep the two together.[[Sasha]] Well, my mental model is probably a bit different:

-          P-routers never use the FAT label for forwarding, only as one of the (potentially, multiple) labels that are hashed for selection for a specific Next Hop in an ECMP group

-          S-PEs do exactly the same. The only difference is that they use PW labels for the forwarding decision. This means that S-PEs are unaware of usage (or non-usage) of  FAT labels.

-          Egress T-PE does not treat the FAT label as a label in spite of its being part of the label stack. It simply treats it as additional 32 bits preceding the PW CW (if used) or the PW payload (if CW is not used) and removes these bits as part of the processing.
It strictly contradicts RFC 6391 which explicitly states that the flow label is always at the bottom of the label stack
Good point, we will need no note an update to RFC6391.[[Sasha]]

a. It makes proper treatment of VCCV packets problematic as explained below:

                        i.   T-PEs (which are aware of flow labels) would have not just to remove the Flow Label but also to check whether  the next label is  GAL
Yes, well strictly they check BoS on the FAT which they have to do anyway. [[Sasha]] Not sure they really need even that (see above)

                      ii.   S-PEs of MS-PWs would have to become aware of flow labels while today they may be unaware of flow labels and simply pass these labels transparently (as per Section 6 of RFC 6391)
I don't understand why this would be the case other than for OAM processing due to TTL expiry. Is that the case that concerns you?
[[Sasha]] Yes this is the case, and I think that what is missing  is specification of the procedure that:

(a)   reliably identifies the trapped packet as a VCCV one and not an erroneously trapped PW data packet

(b)   infers the OAM protocol carried in VCCV from whatever information is available

(c)    does not require information about usage or non-usage of the FAT label in the specific PW to perform (a) and (b) above.
Whatever procedure has been used by S-PEs before introduction of VCCV Type 4, it would require adaptation to cover also VCCV Type 4.
Explicitly including such a procedure in the draft could make it longer, but I would consider that as a way to guarantee interoperability.

b. Some types of forwarding HW are known to be limited to hashing only on the bottom-of-stack label for ECMP:

                      ii.   The proposal in the draft, if accepted, would break normal ECMP behavior for both these schemes with such HW.
Hang on, normally the FAT is still BOS, so normally this works, but as stated in the draft when the GAL is present (for OAM) there is a problem. I don't see any way round it in non-RFC6790 networks. [[Sasha]] This could sound weird, but one possible way out of this (and out of the S-PE problems) could be non-use of the FAT label (or the ELI/EL construct) in VCCV Type 4 packets even if the PW uses one of these constructs:

-          The PW itself does not use the CW, so it is prone to misbehavior when ECMP is employed

-          We do not lose too much since in any case VCCV Type 4 is not ECMP-safe

[[Sasha]] What do you think?

c. In addition:

                      ii.   While the proposal in the draft breaks RFC 6391, this RFC  is not even mentioned as being updated (?) by the draft.
It will update it in the next revision.[[Sasha]]Yes I think this is necessary regardless of what you decide regarding the relative positions of GAL and the FAT label.

I am however uncertain what you propose in terms of a way forward. You bring up some important points, but I get no sense of what you propose as alternatives in terms of the design and why they are better (position of the GAL relative to FAT, or exclusivity of the features have problems whichever way we call it), or indeed whether you think this draft should simply be abandoned?

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 24 Dec 2014 13:10:09 +0000

Sasha

Thanks for your update. I will trim this to just the bits we need
to talk about.

On 24/12/2014 11:48, Alexander Vainshtein wrote:
> Yes, but I would like a solution, since any position is problematic, 
> and since both FAT and GAL both intended for Ethernet PWs we have to 
> find a solution. Before I get to the detailed comments below I should 
> state my mental model which is that I see the FAT label as a type of 
> modifier for the PW label and assume that the h/w when it sees a FAT 
> label it just discards the  following lable unchecked except to note 
> the BoS state. Thus it makes sense to me to keep the two 
> together.*/[[Sasha]] Well, my mental model is probably a bit different: /*
>
> -*/P-routers never use the FAT label for forwarding, only as one of 
> the (potentially, multiple) labels that are hashed for selection for a 
> specific Next Hop in an ECMP group/*
>
> -*/S-PEs do exactly the same. The only difference is that they use PW 
> labels for the forwarding decision. This means that S-PEs are unaware 
> of usage (or non-usage) of  FAT labels. /*
>
> -*/Egress T-PE does not treat the FAT label as a label in spite of its 
> being part of the label stack. It simply treats it as additional 32 
> bits preceding the PW CW (if used) or the PW payload (if CW is not 
> used) and removes these bits as part of the processing./*
>
SB> We agree on the above except on whether the BoS is inspected, which 
I think it has to be for safety.
> Yes, well strictly they check BoS on the FAT which they have to do 
> anyway. */[[Sasha]] Not sure they really need even that (see above)/*
>
SB> See above. BoS will be set in the FAT if it is BoS and clear if it 
is not - it has to follow the MPLS arch.
> */[[Sasha]] Yes this is the case, and I think that what is missing  is 
> specification of the procedure that:/*
>
> */(a)/**/reliably identifies the trapped packet as a VCCV one and not 
> an erroneously trapped PW data packet/*
>
> */(b)/**/infers the OAM protocol carried in VCCV from whatever 
> information is available /*
>
> */(c)/**/does not require information about usage or non-usage of the 
> FAT label in the specific PW to perform (a) and (b) above./*
>
> */Whatever procedure has been used by S-PEs before introduction of 
> VCCV Type 4, it would require adaptation to cover also VCCV Type 4. /*
>
> */Explicitly including such a procedure in the draft could make it 
> longer, but I would consider that as a way to guarantee 
> interoperability./*
>
SB> OK I agree text is needed. Any I agree that the T-PE must not change 
its behavior in the MS-PW case (other than set TTL > 2. I will put some 
text in and then we can see if we agree.
> *//*
> */[[Sasha]] This could sound weird, but one possible way out of this 
> (and out of the S-PE problems) could be non-use of the FAT label (or 
> the ELI/EL construct) in VCCV Type 4 packets even if the PW uses one 
> of these constructs:/*
>
> -*/The PW itself does not use the CW, so it is prone to misbehavior 
> when ECMP is employed/*
>
> -*/We do not lose too much since in any case VCCV Type 4 is not 
> ECMP-safe/*
>
SB> It would simplify things if we prohibited FAT and GAL in the same 
packet. I don't think that we need to apply the constraint to ELI/EL.

SB> Maybe we don't need to go as far as prohibition of course we could 
say allowed but not recommended.

SB> What do others think?

-Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 24 Dec 2014 13:19:51 +0000

Stewart,
Lots of thanks for an extra-prompt response.

Let us see what the others think about combining (or not combining) GAL and FAT labels – this would indeed make life simpler.

Regards,
       Sasha

From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, December 24, 2014 3:10 PM
To: Alexander Vainshtein
Cc: [email-masked]; Andrew G. Malis
Subject: Re: [Pals] Soliciting reviews for draft-ietf-pals-vccv-for-gal-00.txt

Sasha

1. I see the proposal (in section 5) to place  GAL at the bottom of the label stack for “fat PWs” with the flow PW directly preceding it as highly problematic:
Yes, but I would like a solution, since any position is problematic, and since both FAT and GAL both intended for Ethernet PWs we have to find a solution. Before I get to the detailed comments below I should state my mental model which is that I see the FAT label as a type of modifier for the PW label and assume that the h/w when it sees a FAT label it just discards the  following lable unchecked except to note the BoS state. Thus it makes sense to me to keep the two together.[[Sasha]] Well, my mental model is probably a bit different:

-          Egress T-PE does not treat the FAT label as a label in spite of its being part of the label stack. It simply treats it as additional 32 bits preceding the PW CW (if used) or the PW payload (if CW is not used) and removes these bits as part of the processing.
SB> We agree on the above except on whether the BoS is inspected, which I think it has to be for safety.

                          i.   T-PEs (which are aware of flow labels) would have not just to remove the Flow Label but also to check whether  the next label is  GAL
Yes, well strictly they check BoS on the FAT which they have to do anyway. [[Sasha]] Not sure they really need even that (see above)
SB> See above. BoS will be set in the FAT if it is BoS and clear if it is not - it has to follow the MPLS arch.

(c)    does not require information about usage or non-usage of the FAT label in the specific PW to perform (a) and (b) above.
Whatever procedure has been used by S-PEs before introduction of VCCV Type 4, it would require adaptation to cover also VCCV Type 4.
Explicitly including such a procedure in the draft could make it longer, but I would consider that as a way to guarantee interoperability.
SB> OK I agree text is needed. Any I agree that the T-PE must not change its behavior in the MS-PW case (other than set TTL > 2. I will put some text in and then we can see if we agree.

-          We do not lose too much since in any case VCCV Type 4 is not ECMP-safe
SB> It would simplify things if we prohibited FAT and GAL in the same packet. I don't think that we need to apply the constraint to ELI/EL.

SB> Maybe we don't need to go as far as prohibition of course we could say allowed but not recommended.

-Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 24 Dec 2014 13:25:04 -0500

Sasha and Stewart,

I agree that life is simpler if we prohibit FAT and GAL in the same packet,
and I'm not personally aware of any implementations that already do so.

Cheers,
Andy

On Wed, Dec 24, 2014 at 8:19 AM, Alexander Vainshtein <
[email-masked]> wrote:

> Let us see what the others think about combining (or not combining) GAL
> and FAT labels – this would indeed make life simpler.
>
>
>
> Regards,
>
>        Sasha
>
> *From:* Stewart Bryant [mailto:[email-masked]]
> *Sent:* Wednesday, December 24, 2014 3:10 PM
> *To:* Alexander Vainshtein
> *Cc:* [email-masked]; Andrew G. Malis
> *Subject:* Re: [Pals] Soliciting reviews for
> draft-ietf-pals-vccv-for-gal-00.txt
>
>
>
> Sasha
>
>
> 1. I see the proposal (in section 5) to place  GAL at the bottom of the label stack for “fat PWs” with the flow PW directly preceding it as *highly problematic*:
>
> discards the  following lable unchecked except to note the BoS state. Thus
> it makes sense to me to keep the two together.*[[Sasha]] Well, my mental
> model is probably a bit different: *
>
> -          *P-routers never use the FAT label for forwarding, only as one
> of the (potentially, multiple) labels that are hashed for selection for a
> specific Next Hop in an ECMP group*
>
> -          *S-PEs do exactly the same. The only difference is that they
> use PW labels for the forwarding decision. This means that S-PEs are
> unaware of usage (or non-usage) of  FAT labels. *
>
> -          *Egress T-PE does not treat the FAT label as a label in spite
> of its being part of the label stack. It simply treats it as additional 32
> bits preceding the PW CW (if used) or the PW payload (if CW is not used)
> and removes these bits as part of the processing.*
>
> Yes, well strictly they check BoS on the FAT which they have to do anyway. *[[Sasha]]
> Not sure they really need even that (see above)*
>
>                          ii.   S-PEs of MS-PWs *would have to become aware of flow labels* while today they may be unaware of flow labels and simply pass these labels transparently (as per Section 6 of RFC 6391)
>
> *[[Sasha]] Yes this is the case, and I think that what is missing  is
> specification of the procedure that:*
>
> *(a)   **reliably identifies the trapped packet as a VCCV one and not an
> erroneously trapped PW data packet*
>
> *(b)   **infers the OAM protocol carried in VCCV from whatever
> information is available *
>
> *(c)    **does not require information about usage or non-usage of the
> FAT label in the specific PW to perform (a) and (b) above.*
>
> *Whatever procedure has been used by S-PEs before introduction of VCCV
> Type 4, it would require adaptation to cover also VCCV Type 4. *
>
> *Explicitly including such a procedure in the draft could make it longer,
> but I would consider that as a way to guarantee interoperability.*
>
> stated in the draft when the GAL is present (for OAM) there is a problem. I
> don't see any way round it in non-RFC6790 networks. *[[Sasha]] This could
> sound weird, but one possible way out of this (and out of the S-PE
> problems) could be non-use of the FAT label (or the ELI/EL construct) in
> VCCV Type 4 packets even if the PW uses one of these constructs:*
>
> -          *The PW itself does not use the CW, so it is prone to
> misbehavior when ECMP is employed*
>
> -          *We do not lose too much since in any case VCCV Type 4 is not
> ECMP-safe*
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 24 Dec 2014 18:35:39 +0000

Andy,

I took a very quick scan through this document, and have a number of concerns.

At the heart of the concerns, this document seems to be doing a number of different things that are not reflected in the Title and Abstract. While the title is “VCCV Default CC Types”, this document seems to be doing much more than defining default CC Types, including:
1. Defining a new CC Type 4
2. Setting a Default for when with and without CW (as per the Title), but also
3. Implicitly Obsoleting Type 2 and Type 3 (non-default)
4. Requiring new hw capabilities for the Type 4.

I believe those things should be explicitly done.

Some more comments (including editorials) follow, prefaced with “CMP”:

PWE3                                                           T. Nadeau
Internet-Draft                                               lucidvision
Updates: 4447, 5085 (if approved)                             L. Martini

CMP: s/PWE3/PALS? >

CMP: More importantly, what exactly is this document updating on those two? Adding a new CC Type does not mean update RFC 4447 or RFC 5085. I Section listing the exact updates to those specs is necessary. My view is that this doc can update 5085 (Section 7), but not sure how it updates 4447.

CMP: I thought that initially, draft-ietf-pwe3-vccv-for-gal-02 was only defining the new CC Type 4, while draft-nadeau-pwe3-vccv2-00 would do other updates including Defaults, obsoleting CC Types, etc.

   state.  Operators have indicated in [RFC4377], and [RFC3916] that
   such a tool is required for PW operation and maintenance.  To this
   end, the IETF's PWE3 Working Group defined the Virtual Circuit
   Connectivity Verification Protocol (VCCV) in [RFC5085] . Since then a
   number of interoperability issues have arisen with the protocol as it
   is defined.

CMP: I see the fact that PWE3 WG defined that RFC as a distractor, and irrelevant in the larger scheme of things. Also, you should point to [RFC7079] to describe and quantify the interop issues instead of just saying they exist. Lastly, how creating a new CC Type not also create intro issues? That should be answered.

7.  Manageability Considerations

   By introducing default VCCV CC types, and improving the compatibility
   with MPLS-TP, the compatibility of implementations is improved and
   management and configuration of the network becomes simpler.

CMP: This is a bold statement, that does not appear to be immediate. I expect initially to see the manageability worst before it improves. This is adding a new mode before letting time to remove all the other ones.

Thanks,

Carlos.

On Dec 22, 2014, at 9:33 AM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

PALSers,

Thanks,
Stewart and Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, Dec 17, 2014 at 12:00 PM
Subject: I-D Action: draft-ietf-pals-vccv-for-gal-00.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft> directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
Pals mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pals

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 25 Dec 2014 05:52:39 +0000

​Carlos,

After reading your review I have looked up RFC 7079.

This document shows that for Ethernet PWs VCCV Type 2 and VCCV Type 3 taken together are used by the operators almost as frequently as VCCV Type 1:

o Ethernet Tagged Mode - RFC 4448 [Sasha]  7 vs. 6
 * Control Word (Type 1) = 7
 * Router Alert Label (Type 2) = 3
 * TTL Expiry (Type 3) = 3

 o Ethernet Raw Mode - RFC 4448 [Sasha]  A draw: 8 vs. 8
 * Control Word (Type 1) = 8
 * Router Alert Label (Type 2) = 4
 * TTL Expiry (Type 3) = 4

If anything, this looks to me as a blocker for deprecation of these types (even if  VCCV Type 2 is not suitable for MS-PWs as indicated in RFC 6073)

 Lots of thanks for pointing to this document!

Regards,
Sasha
________________________________
From: Pals <[email-masked]> on behalf of Carlos Pignataro (cpignata) <[email-masked]>
Sent: Wednesday, December 24, 2014 8:35 PM
To: Andrew G. Malis
Cc: [email-masked]
Subject: Re: [Pals] Soliciting reviews for draft-ietf-pals-vccv-for-gal-00.txt

Andy,

PWE3                                                           T. Nadeau

CMP: s/PWE3/PALS? >

Thanks,

Carlos.

PALSers,

Thanks,
Stewart and Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, Dec 17, 2014 at 12:00 PM
Subject: I-D Action: draft-ietf-pals-vccv-for-gal-00.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 26 Dec 2014 01:09:56 +0000

Hi, Sasha,

Exactly — so some of the questions that this creates are:

  1.  What’s not working on Types 2 and 3 that a Type 4 would solve?
  2.  If the answer to Q1 and the problem to be solved is interop — would creating a new Type to deprecate (effectively in practice or explicitly) two CC Types be the fastest way to interop?
  3.  If new HW is needed for a Type 4, what’s the backwards compatibility and deployment plan?
  4.  If CC Types 1 and 4 are proposed to be forward-looking used, should this doc come clean at deprecating Types 2 and 3?
  5.  Instead of a new CC Type 4, would mandating CW for all PWs (and use of CC Type 1) solve this more effectively?

I think Q5 is a key one that ought to be discussed.

Hope this quick review and these questions help.

Thanks,

Carlos.

On Dec 25, 2014, at 12:52 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:

​Carlos,

Regards,
Sasha
From: Pals <[email-masked]<mailto:[email-masked]>> on behalf of Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>

Andy,

PWE3                                                           T. Nadeau

CMP: s/PWE3/PALS? >

Thanks,

Carlos.

PALSers,

Thanks,
Stewart and Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, Dec 17, 2014 at 12:00 PM
Subject: I-D Action: draft-ietf-pals-vccv-for-gal-00.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 26 Dec 2014 06:00:31 +0000

​Carlos,

Lots of thanks for a prompt response and especially for a set of well-defined questions.

So far I can offer my versions of answers to Q1:

  *   A common problem with both Type 2 and Type 3 is that they effectively mandate IP- (and sometimes even UDP/IP-) based encapsulation for OAM packets they carry. IP Protocol number and, possibly, UDP Destination port are required for  demuxing different OAM protocols running in VCCV. This has never been an issue when RFC 5085 has been discussed, but advance of MPLS-TP changed the attitude IMO.
  *   VCCV Type 2 has an additional  problem of its own - it simply does not work for MS-PWs. RFC 6073 explicitly states
  *   VCCV Type 3 also has an additional problem of its own  -  it could result in leaking OAM packets into the attachment circuit if the originator has mistakenly set a wrong TTL value in the PW label LSE. At the same time PW segment OAM for MS-PWs mandates usage of VCCV Type 3.

From my POV VCCV Type 4  solves all these problems for PWs that do not use the CW.

Hopefully these notes will be useful.

Regards,

Sasha

________________________________
From: Carlos Pignataro (cpignata) <[email-masked]>
Sent: Friday, December 26, 2014 3:09 AM
To: Alexander Vainshtein
Cc: [email-masked]; Andrew G. Malis
Subject: Re: [Pals] Soliciting reviews for draft-ietf-pals-vccv-for-gal-00.txt

Hi, Sasha,

Thanks,

Carlos.

​Carlos,

Regards,
Sasha

Andy,

PWE3                                                           T. Nadeau

CMP: s/PWE3/PALS? >

Thanks,

Carlos.

PALSers,

Thanks,
Stewart and Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, Dec 17, 2014 at 12:00 PM
Subject: I-D Action: draft-ietf-pals-vccv-for-gal-00.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 26 Dec 2014 08:47:26 -0500

Carlos and Sasha,

In addition to Sasha's reply, I would like to add in response to Carlos' Q5
that the WG has repeatedly agreed (and documented in RFC 7079, section 2.1
in particular) that there are too many existing deployed implementations of
PWs without the CW that we cannot mandate the CW for all PWs. It would be
great if we could, but unfortunately that ship has sailed.

Cheers,
Andy

On Fri, Dec 26, 2014 at 1:00 AM, Alexander Vainshtein <
[email-masked]> wrote:

>    - A common problem with both Type 2 and Type 3 is that they *effectively
>    mandate IP- (and sometimes even UDP/IP-) based encapsulation for OAM
>    packets they carry. *IP Protocol number and, possibly, UDP Destination
>    port are required for  demuxing different OAM protocols running in VCCV.
>    This has never been an issue when RFC 5085 has been discussed, but advance
>    of MPLS-TP changed the attitude IMO.
>    - VCCV Type 2 has an additional  problem of its own - it simply *does
>    not work for MS-PWs. *RFC 6073 explicitly states
>    - VCCV Type 3 also has an additional problem of its own  -  *it could
>    result in leaking OAM packets into the attachment circuit *if the
>    originator has mistakenly set a wrong TTL value in the PW label LSE. At the
>    same time PW segment OAM for MS-PWs mandates usage of VCCV Type 3.
>
>   ------------------------------
>  *From:* Carlos Pignataro (cpignata) <[email-masked]>
> *Sent:* Friday, December 26, 2014 3:09 AM
>    2. If the answer to Q1 and the problem to be solved is interop — would
>    creating a new Type to deprecate (effectively in practice or explicitly)
>    two CC Types be the fastest way to interop?
>    4. If CC Types 1 and 4 are proposed to be forward-looking used, should
>    this doc come clean at deprecating Types 2 and 3?
>    5. Instead of a new CC Type 4, would mandating CW for all PWs (and use
>    of CC Type 1) solve this more effectively?
>
>
>  On Dec 25, 2014, at 12:52 AM, Alexander Vainshtein <
> This document shows that for Ethernet PWs VCCV Type 2 and VCCV Type 3
> taken together are used by the operators *almost as frequently as VCCV
> Type 1*:
>
>  o Ethernet Tagged Mode - RFC 4448 *[Sasha]  7 vs. 6*
>  o Ethernet Raw Mode - RFC 4448 *[Sasha]  A draw: 8 vs. 8*
>  If anything, this looks to me as a blocker for deprecation of these
> types (even if  VCCV Type 2 is not suitable for MS-PWs as indicated in RFC
> 6073)
>
>  ------------------------------
>  *From:* Pals <[email-masked]> on behalf of Carlos Pignataro
> (cpignata) <[email-masked]>
> *Sent:* Wednesday, December 24, 2014 8:35 PM
> *To:* Andrew G. Malis
> *Cc:* [email-masked]
>  At the heart of the concerns, this document seems to be doing a number
> of different things that are not reflected in the Title and Abstract. While
> the title is “VCCV Default CC Types”, this document seems to be doing much
> more than defining default CC Types, including:
>  CMP: More importantly, what exactly is this document updating on those
> two? Adding a new CC Type does not mean update RFC 4447 or RFC 5085. I
> Section listing the exact updates to those specs is necessary. My view is
> that this doc can update 5085 (Section 7), but not sure how it updates 4447.
>
>  CMP: I thought that initially, draft-ietf-pwe3-vccv-for-gal-02 was only
> defining the new CC Type 4, while draft-nadeau-pwe3-vccv2-00 would do other
> updates including Defaults, obsoleting CC Types, etc.
>
>  CMP: I see the fact that PWE3 WG defined that RFC as a distractor, and
> irrelevant in the larger scheme of things. Also, you should point to
> [RFC7079] to describe and quantify the interop issues instead of just
> saying they exist. Lastly, how creating a new CC Type not also create intro
> issues? That should be answered.
>
>  CMP: This is a bold statement, that does not appear to be immediate. I
> expect initially to see the manageability worst before it improves. This is
> adding a new mode before letting time to remove all the other ones.
>
>  Thanks,
>
>  Carlos.
>
>
>  On Dec 22, 2014, at 9:33 AM, Andrew G. Malis <[email-masked]> wrote:
>
>  PALSers,
>
>  i know that you would all like a little something to distract you from
> the holidays ... :-). Well, maybe not. But anyway, Stewart recently revised
> the VCCV for GAL draft (see below), and while short (just four pages of
> real content), we would like to have a good indication that it represents
> WG consensus, so we need at least some of you out there to read it and
> Internet-Draft
> <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>
> directories: http://www.ietf.org/shadow.html
> [email-masked]

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 26 Dec 2014 14:46:36 +0000

Hi Sasha,

Thanks for these very useful perspectives! This is a very useful reply.

I think none of these reasons are listed in the draft Andy was asking about. One of the issues is that conflating the creation of a new CC Type with the prioritization of type usage (defaulting, obsoleting, etc) obscures the reasons for change, making them more vague. Is it for interoperability, mpls-TP, non-IP OAM, ms-pw? Should the creation of a cc type be separate from the rationalization of the existing ones?

I agree with your points below. But also, as you pointed out, types 2 and 3 seem widely used despite all their bugs.

Thanks!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Dec 26, 2014, at 1:00 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:

​Carlos,

Regards,

Sasha

________________________________
From: Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, December 26, 2014 3:09 AM
To: Alexander Vainshtein
Cc: [email-masked]<mailto:[email-masked]>; Andrew G. Malis
Subject: Re: [Pals] Soliciting reviews for draft-ietf-pals-vccv-for-gal-00.txt

Hi, Sasha,

Thanks,

Carlos.

​Carlos,

Regards,
Sasha

Andy,

PWE3                                                           T. Nadeau

CMP: s/PWE3/PALS? >

Thanks,

Carlos.

PALSers,

Thanks,
Stewart and Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, Dec 17, 2014 at 12:00 PM
Subject: I-D Action: draft-ietf-pals-vccv-for-gal-00.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 26 Dec 2014 14:52:25 +0000

Andy,

Thanks!

If that's the case, are there too many existing deployments of CC Types 2 and 3 that we cannot mandate a new CC Type 4 (and associated hw changes) as a new default (effectively obsoleting CC Types 2 and 3)? Has that ship sailed?

Or asking a different way, which is what I intended with q5: if the WG is considering these non-trivial cc type changes, would that reconsider the CW question if that solved oam plus a lot other issues?

Thanks for considering these questions!

Best,

On Dec 26, 2014, at 8:48 AM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Carlos and Sasha,

In addition to Sasha's reply, I would like to add in response to Carlos' Q5 that the WG has repeatedly agreed (and documented in RFC 7079, section 2.1 in particular) that there are too many existing deployed implementations of PWs without the CW that we cannot mandate the CW for all PWs. It would be great if we could, but unfortunately that ship has sailed.

Cheers,
Andy

On Fri, Dec 26, 2014 at 1:00 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:

​Carlos,

Regards,

Sasha

Hi, Sasha,

Thanks,

Carlos.

​Carlos,

Regards,
Sasha

Andy,

PWE3                                                           T. Nadeau

CMP: s/PWE3/PALS? >

Thanks,

Carlos.

PALSers,

Thanks,
Stewart and Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, Dec 17, 2014 at 12:00 PM
Subject: I-D Action: draft-ietf-pals-vccv-for-gal-00.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 26 Dec 2014 10:46:56 -0500

It might be worth checking this state again. RFC7079 is FOUR years old now.

	—Tom

> On Dec 26, 2014:8:47 AM, at 8:47 AM, Andrew G. Malis <[email-masked]> wrote:
> 
> Carlos and Sasha,
> 
> On Fri, Dec 26, 2014 at 1:00 AM, Alexander Vainshtein <[email-masked] <mailto:[email-masked]>> wrote:
> ​Carlos,
> 
> A common problem with both Type 2 and Type 3 is that they effectively mandate IP- (and sometimes even UDP/IP-) based encapsulation for OAM packets they carry. IP Protocol number and, possibly, UDP Destination port are required for  demuxing different OAM protocols running in VCCV. This has never been an issue when RFC 5085 has been discussed, but advance of MPLS-TP changed the attitude IMO. 
> VCCV Type 2 has an additional  problem of its own - it simply does not work for MS-PWs. RFC 6073 explicitly states  
> VCCV Type 3 also has an additional problem of its own  -  it could result in leaking OAM packets into the attachment circuit if the originator has mistakenly set a wrong TTL value in the PW label LSE. At the same time PW segment OAM for MS-PWs mandates usage of VCCV Type 3.  
> From: Carlos Pignataro (cpignata) <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; Andrew G. Malis
> What’s not working on Types 2 and 3 that a Type 4 would solve?
> If the answer to Q1 and the problem to be solved is interop — would creating a new Type to deprecate (effectively in practice or explicitly) two CC Types be the fastest way to interop?
> If new HW is needed for a Type 4, what’s the backwards compatibility and deployment plan?
> If CC Types 1 and 4 are proposed to be forward-looking used, should this doc come clean at deprecating Types 2 and 3?
> Instead of a new CC Type 4, would mandating CW for all PWs (and use of CC Type 1) solve this more effectively?
> 
>> On Dec 25, 2014, at 12:52 AM, Alexander Vainshtein <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> ​Carlos,
>> From: Pals <[email-masked] <mailto:[email-masked]>> on behalf of Carlos Pignataro (cpignata) <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>
>>> On Dec 22, 2014, at 9:33 AM, Andrew G. Malis <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> PALSers,
>>> 
>>> You can read the draft at http://tools.ietf.org/html/draft-ietf-pals-vccv-for-gal-00 <http://tools.ietf.org/html/draft-ietf-pals-vccv-for-gal-00> .
>>> 
>>> Thanks,
>>> Stewart and Andy
>>> 
>>> From: <[email-masked] <mailto:[email-masked]>>
>>> To: [email-masked] <mailto:[email-masked]>
>>> Cc: [email-masked] <mailto:[email-masked]>
>>> 
>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-pals-vccv-for-gal/ <https://datatracker.ietf.org/doc/draft-ietf-pals-vccv-for-gal/>
>>> 
>>> http://tools.ietf.org/html/draft-ietf-pals-vccv-for-gal-00 <http://tools.ietf.org/html/draft-ietf-pals-vccv-for-gal-00>
>>> 
>>> 
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>>> 
>>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> Internet-Draft <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft> directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/pals <https://www.ietf.org/mailman/listinfo/pals>
>

---

From: "DelRegno, Christopher N (Nick)" <[email-masked]>
Date: Fri, 26 Dec 2014 12:25:08 -0500

Tom raises a valid point, but I’m not sure how often we should poll the industry, looking for the answer we may desire.

Some anecdotal info from my vantage point, for what it’s worth:
Our use of VLAN-mode and Raw-Mode Ethernet PWs with CC Type 1 has grown dramatically over the last four years.  However, the use of Type 2 or Type 3 has not decreased as there is little motivation to migrate a customer’s EVC (read outage) from Types 2 & 3 to Type 1.  So while the ratio of Type 1 to Types 2/3 for Ethernet PWs has grown, the number of Types 2/3 Ethernet PWs has remained steady, if not increasing slightly.

Likewise, the FR/ATM encaps, while decreasing, have not disappeared.

My major discomfort comes from phrases like: "When the PWE3 Control Word is not used, the new VCCV CC Type 4 defined in this section MUST be used.”  My need is that it must be SUPPORTED.  However, mandating its use seems problematic.

For example, consider a  network (or parts/regions thereof) where older equipment is in use and Type 1 is A) not enabled or worse B) not supported.  This equipment may be running old code and not upgradeable to newer code/hardware which supports Type 1.  This network is running along fine with Type 2 or Type 3.  Now, add in Vendor X’s new draft-ietf-pals-vccv-for-gall-xx-compliant system.  1) It will NEVER be able to setup PWs with the legacy equipment in Scenario B, and only with per-VC config changes could it in Scenario A.  2) I would NEVER be able to migrate from the old to the new without some sort of flag day, network wide migration, which wouldn’t happen.

Since we have so many networks in flight with large numbers of non-CC-Type-1 PWs in service, we need a more considerate approach than mandating Type 1 OR Type 4 only.

Nick

From: Thomas Nadeau <[email-masked]<mailto:[email-masked]>>
Date: Friday, December 26, 2014 at 9:46 AM
To: "Andrew G. Malis" <[email-masked]<mailto:[email-masked]>>
Cc: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Pals] Soliciting reviews for draft-ietf-pals-vccv-for-gal-00.txt

—Tom

On Dec 26, 2014:8:47 AM, at 8:47 AM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Carlos and Sasha,

Cheers,
Andy

​Carlos,

Regards,

Sasha

Hi, Sasha,

Thanks,

Carlos.

​Carlos,

Regards,
Sasha

Andy,

PWE3                                                           T. Nadeau

CMP: s/PWE3/PALS? >

Thanks,

Carlos.

PALSers,

Thanks,
Stewart and Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, Dec 17, 2014 at 12:00 PM
Subject: I-D Action: draft-ietf-pals-vccv-for-gal-00.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Abstract: