Subject: [CCAMP] Network Assigned Upstream Label - Draft Update

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 24 Feb 2014 22:38:19 -0500

Folks, Hi!

We recently published a new version of the "Network Assigned Upstream
Label" draft (
http://tools.ietf.org/html/draft-beeram-ccamp-network-assigned-upstream-label-02).
This new-version addresses all the comments that were raised against the
version presented in Vancouver. Please read it through and let us know if
there are any fresh comments.

Regards,
-Pavan (on behalf of the authors)
ps: Attached slideset (pdf) gives a quick overview of the draft

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Tue, 25 Feb 2014 10:59:19 +0000

Hi, Pavan,

     I understand this draft intends to allow bidirectional LSP setup with the capability of downstream nodes specifying the upstream label (assume label symmetry). I have a couple of questions/comments, could you please clarify?

1)      This draft is only applicable to networks with continuity constraint, for now I can only think of WSON, probably Flexi-grid/SSON is applicable as well. Because for other cases, such as OTN, it is perfectly fine for the nodes to specify upstream label starting from the source node. Is the scope correct?

2)      In this draft, it is assumed that the label assigned will always be symmetric (i.e., upstream and downstream label is equal). Thus, IMHO, using the mechanism specified by RFC3473 for unidirectional LSP setup (i.e., downstream label assigned by the destination node will also enable upstream label selected) can solve the problem. It does not require protocol extensions, although probably some operational policy should be in force to ask the nodes in the data plane to configure the resource in both directions. How do you see your solution better/different than this one?

3)      The use case specified is the only use case (not general enough) or you also have other use cases in mind?

Regards,
Xian

From: CCAMP [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: 2014年2月25日 11:38
To: [email-masked]
Subject: [CCAMP] Network Assigned Upstream Label - Draft Update

Folks, Hi!

We recently published a new version of the "Network Assigned Upstream Label" draft (http://tools.ietf.org/html/draft-beeram-ccamp-network-assigned-upstream-label-02). This new-version addresses all the comments that were raised against the version presented in Vancouver. Please read it through and let us know if there are any fresh comments.

Regards,

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 25 Feb 2014 07:54:56 -0500

Xian, Hi!

Thanks for reviewing the draft.

Responses inline (prefixed with [VPB])

Regards,
-Pavan

On Tue, Feb 25, 2014 at 5:59 AM, Zhangxian (Xian) <[email-masked]>wrote:

>  Hi, Pavan,
>
>
>
>      I understand this draft intends to allow bidirectional LSP setup with
> the capability of downstream nodes specifying the upstream label (assume
> label symmetry). I have a couple of questions/comments, could you please
> clarify?
>
> 1)      This draft is only applicable to networks with continuity
> constraint, for now I can only think of WSON, probably Flexi-grid/SSON is
> applicable as well. Because for other cases, such as OTN, it is perfectly
> fine for the nodes to specify upstream label starting from the source node.
> Is the scope correct?
>
[VPB] The extensions discussed in the initial version attempted to cover
all switching-types and included extensions for both symmetric/asymmetric
label scenarios. But since the only use-case discussed in the draft uses
LSC (Lambda Switch Capable) LSPs, it was rightly suggested by several folks
(on and off the mailing-list) that the scope of the draft should be limited
to LSC LSPs. The simple extension proposed in the draft is hop-specific
(make no assumptions regarding continuity constraints) and is pertinent to
switching-types that inherently mandate label-symmetry at each hop.

>   2)      In this draft, it is assumed that the label assigned will
> always be symmetric (i.e., upstream and downstream label is equal). Thus,
> IMHO, using the mechanism specified by RFC3473 for unidirectional LSP setup
> (i.e., downstream label assigned by the destination node will also enable
> upstream label selected) can solve the problem. It does not require
> protocol extensions, although probably some operational policy should be in
> force to ask the nodes in the data plane to configure the resource in both
> directions. How do you see your solution better/different than this one?
>
[VPB] If I understood what you are saying - your suggestion is to signal
the Lambda LSP as a uni-directional LSP (no UPSTREAM-LABEL) and have some
policy at each hop requesting the implementation to ignore the signaled
"uni-directionality" and assign the labels in both directions for the LSP.
(Did I understand that right?)
Yes, you could do that. And you could also use this policy based approach
(overriding signaled objects) for a number of other signaled attributes of
an LSP. The obvious advantage of having a signaling based solution is that
you wouldn't need explicit policy to be configured/implemented at each hop
along the path of the LSP.

>  3)      The use case specified is the only use case (not general enough)
> or you also have other use cases in mind?
>
[VPB] Yes - this is the only use-case that we are trying address. But isn't
that an important enough use-case to warrant a simple extension?

>
>
> Regards,
>
> Xian
>
>
>
> *From:* CCAMP [mailto:[email-masked]] *On Behalf Of *Vishnu Pavan
> Beeram
> *Sent:* 2014年2月25日 11:38
> *To:* [email-masked]
> *Subject:* [CCAMP] Network Assigned Upstream Label - Draft Update
>
>
>
> Folks, Hi!
>
>
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 28 Feb 2014 04:41:17 +0000

From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 25, 2014 7:54 AM
To: "Zhangxian (Xian)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

[VPB] If I understood what you are saying - your suggestion is to signal the Lambda LSP as a uni-directional LSP (no UPSTREAM-LABEL) and have some policy at each hop requesting the implementation to ignore the signaled "uni-directionality" and assign the labels in both directions for the LSP. (Did I understand that right?)
Yes, you could do that. And you could also use this policy based approach (overriding signaled objects) for a number of other signaled attributes of an LSP. The obvious advantage of having a signaling based solution is that you wouldn't need explicit policy to be configured/implemented at each hop along the path of the LSP.

Pavan:

When (alien) wavelength is same in forward and reverse direction, we can use label set along with acceptable label set – as defined in RFC3473.

Thanks

Regards … Zafar

---

From: John E Drake <[email-masked]>
Date: Fri, 28 Feb 2014 12:03:01 +0000

Zafar,

The use of acceptable label set is *not* acceptable because it doubles the signaling overhead and opens up the window for contention.  We've discussed this before.

Yours Irrespectively,

John

From: CCAMP [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Thursday, February 27, 2014 8:41 PM
To: Vishnu Pavan Beeram; Zhangxian (Xian)
Cc: [email-masked]
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Pavan:

When (alien) wavelength is same in forward and reverse direction, we can use label set along with acceptable label set - as defined in RFC3473.

Thanks

Regards ... Zafar

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 28 Feb 2014 07:26:48 -0500

Zafar, Hi!

We have been through this before (you'll find this point well debated in
the thread archives - thread-pointer:
http://www.ietf.org/mail-archive/web/ccamp/current/msg15444.html) and I
thought you agreed to the need for an Unassigned Upstream Label. Anyway,
let me try this again -

Here are a couple of points that have been made earlier:
(1) As per the existing procedures for UPSTREAM_LABEL (RFC 3473), the
presence of an assigned label in the object indicates that the
upstream-node has already installed/programmed this label on its outgoing
interface. That isn't the case in your proposal.
(2) The use of Label-Set/Acceptable Label-Set was meant to be used for
exceptions. Using it always for every setup request is a compromised
solution.

Regards,
-Pavan

On Thu, Feb 27, 2014 at 11:41 PM, Zafar Ali (zali) <[email-masked]> wrote:

>
>
>   From: Vishnu Pavan Beeram <[email-masked]>
> To: "Zhangxian (Xian)" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>  When (alien) wavelength is same in forward and reverse direction, we can
> use label set along with acceptable label set - as defined in RFC3473.
>
>  Thanks
>
>  Regards ... Zafar
>

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Fri, 28 Feb 2014 12:54:26 +0000

Hi Vishnu,

On 28 Feb 2014, at 13:26, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>> wrote:

(2) The use of Label-Set/Acceptable Label-Set was meant to be used for exceptions. Using it always for every setup request is a compromised solution.

At the time we discussed the wson signaling (http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06), the acceptable label set was considered good enough. Not sure it comes into play at every request since your label_set should have reasonably good labels.

Cheers
G

---

From: John E Drake <[email-masked]>
Date: Fri, 28 Feb 2014 13:10:35 +0000

Giovanni,

Use of acceptable doubles the signaling overhead and opens up a contention window:

1)      Path

2)      Path_err w/ acceptable label

3)      Contention window

4)      Path w/ acceptable label

5)      Resv

Versus:

1)      Path w/ downstream assigned label request

2)      Resv w/ downstream assigned label

Also, it's generally considered a bad idea(tm) to include error messages in the normal operation of a protocol

Yours Irrespectively,

John

From: CCAMP [mailto:[email-masked]] On Behalf Of Giovanni Martinelli (giomarti)
Sent: Friday, February 28, 2014 4:54 AM
To: Vishnu Pavan Beeram
Cc: [email-masked]
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Hi Vishnu,

Cheers
G

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 28 Feb 2014 13:59:32 +0000

Hi John-

Yes, we discussed but all we heard … Path error may be lost, its a bad idea, Path error is not part of core RSVP protocol, etc.

Like, Giovanni mentioned, label set + acceptable label is what is documented for ASON signaling (WG doc), this is what is documented in RFC3473, it is what is highly deployed, and it works, etc. IETF/CCAMP is not a research organization. I am happy if you would like to write a paper on this somewhere.

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 28, 2014 7:03 AM
To: zali <[email-masked]<mailto:[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>, "Zhangxian (Xian)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] Network Assigned Upstream Label - Draft Update

Zafar,

The use of acceptable label set is *not* acceptable because it doubles the signaling overhead and opens up the window for contention.  We’ve discussed this before.

Yours Irrespectively,

John

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

Pavan:

Thanks

Regards … Zafar

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 28 Feb 2014 09:16:09 -0500

Giovanni, Hi!

Can you please elaborate on why you think the LABEL_SET having good labels
help in this context/argument? If the upstream-node doesn't guess right
(when picking the upstream-label), you'll get a PATH-ERR back with the
ACCEPTABLE_LABEL_SET. And this would happen for every setup request.
Wouldn't you call this a compromised solution?

Regards,
-Pavan

On Fri, Feb 28, 2014 at 7:54 AM, Giovanni Martinelli (giomarti) <
[email-masked]> wrote:

>  Hi Vishnu,
>
>  On 28 Feb 2014, at 13:26, Vishnu Pavan Beeram <[email-masked]>
> wrote:
>
>  At the time we discussed the wson signaling (
> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06), the
> acceptable label set was considered good enough. Not sure it comes into
> play at every request since your label_set should have reasonably good
> labels.
>
>  Cheers
> G
>

---

From: John E Drake <[email-masked]>
Date: Fri, 28 Feb 2014 14:35:16 +0000

Zafar,

http://www.pinterest.com/pin/262123640781852835/

Yours Irrespectively,

John

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Friday, February 28, 2014 6:00 AM
To: John E Drake; Vishnu Pavan Beeram; Zhangxian (Xian)
Cc: [email-masked]
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Hi John-

Yes, we discussed but all we heard ... Path error may be lost, its a bad idea, Path error is not part of core RSVP protocol, etc.

Thanks

Regards ... Zafar

Zafar,

Yours Irrespectively,

John

Pavan:

Thanks

Regards ... Zafar

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Fri, 28 Feb 2014 14:36:15 +0000

Hi John,

yes clear,  I was just bringing back on the table discussion we got on the same problem. The second option in better (although contention window is reduced but not avoided) however we had no numbers to justify  that such optimization or … at least not so strong  reasons to update a mechanism that was proven to work.

Cheers
G

On 28 Feb 2014, at 14:10, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:

Giovanni,

1)      Path

Versus:

Also, it’s generally considered a bad idea™ to include error messages in the normal operation of a protocol

Yours Irrespectively,

John

Hi Vishnu,

Cheers
G

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Fri, 28 Feb 2014 14:43:54 +0000

Hi Pavan,

On 28 Feb 2014, at 15:16, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>> wrote:

Giovanni, Hi!

Can you please elaborate on why you think the LABEL_SET having good labels help in this context/argument? If the upstream-node doesn't guess right (when picking the upstream-label), you'll get a PATH-ERR back with the ACCEPTABLE_LABEL_SET. And this would happen for every setup request.

GM> for the wson case the LABEL_SET might be an output from the RWA process, so the signalling likely pick up a good label first time.  Hence my question, how often you fall back in the ACCEPTABLE_LABEL_SET case?

GM> yes… and btw don’t want to preclude anything, simply refreshing some past wg discussions.

Cheers
G

Regards,
-Pavan

On Fri, Feb 28, 2014 at 7:54 AM, Giovanni Martinelli (giomarti) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Vishnu,

Cheers
G

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 28 Feb 2014 14:44:33 +0000

Hi,
It is funny that we have to go through the same arguments again and again every 4 months :=)
One point that I made when I was 4 months younger is that Acceptable Label Set is an exceptionally bad idea in the context of overlay networks (UNI, ENNI, etc.). Consider the following scenario:

1.      Ingress UNI-C guesses upstream label for its LSP L to be X;

2.      Network made its own decision that the upstream label cannot be X - has to be Y. This decision is a function of many things: selected path, capabilities of network nodes along the path, capabilities of egress UNI-C. etc. *Only when the entire tail of client LSP is established the ingress UNI-N can definitively report the acceptable upstream label;* The point is that the signaled acceptable label set cannot contain more than one value.

3.      If label Y is not acceptable for ingress UNI-C, it will have no other choice other than to guess another upstream label Z, and start the process again;

4.      This can go on for quite a while until ingress UNI-C runs out of guesses and gives up.

Cheers,
Igor

From: CCAMP [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Friday, February 28, 2014 9:16 AM
To: Giovanni Martinelli (giomarti)
Cc: [email-masked]
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Giovanni, Hi!

Can you please elaborate on why you think the LABEL_SET having good labels help in this context/argument? If the upstream-node doesn't guess right (when picking the upstream-label), you'll get a PATH-ERR back with the ACCEPTABLE_LABEL_SET. And this would happen for every setup request. Wouldn't you call this a compromised solution?

Regards,
-Pavan

Cheers
G

---

From: John E Drake <[email-masked]>
Date: Fri, 28 Feb 2014 14:48:46 +0000

Giovanni,

The contention window is closed w/ the second option.  When the ingress receives the Resv, the wavelength has been allocated within the network.  With the first option, when the ingress receives the Path_err, the wavelength has *not* been allocated within the network and the ingress is effectively starting over w/ a new Path.

Furthermore, acceptable label set is generated hop by hop.  This means that its use within an optical network to determine a valid e2e wavelength would require a potentially unbounded number of crankbacks, both single and multi-hop, with no guarantee that such a wavelength could be found.

Yours Irrespectively,

John

From: Giovanni Martinelli (giomarti) [mailto:[email-masked]]
Sent: Friday, February 28, 2014 6:36 AM
To: John E Drake
Cc: Vishnu Pavan Beeram; [email-masked]
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Hi John,

yes clear,  I was just bringing back on the table discussion we got on the same problem. The second option in better (although contention window is reduced but not avoided) however we had no numbers to justify  that such optimization or ... at least not so strong  reasons to update a mechanism that was proven to work.

Cheers
G

Giovanni,

1)      Path

Versus:

Yours Irrespectively,

John

Hi Vishnu,

Cheers
G

---

From: Gert Grammel <[email-masked]>
Date: Fri, 28 Feb 2014 14:53:54 +0000

Giovanni,

In other words, ACCEPTABLE_LABEL_SET is a mechanism that can work in a peer-to-peer model where label information is shared beforehand. It is not adequate for an overlay case where no label information is shared between client and network.

Gert

________________________________
From: CCAMP <[email-masked]> on behalf of Igor Bryskin <[email-masked]>
Sent: Friday, February 28, 2014 3:44:33 PM
To: Vishnu Pavan Beeram; Giovanni Martinelli (giomarti)
Cc: [email-masked]
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Hi,

Cheers,
Igor

Giovanni, Hi!

Regards,
-Pavan

Cheers
G

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 28 Feb 2014 15:00:06 +0000

Hi Pavan:

The acceptable label set is picked from the label set (e.g., one of the labels from the label set). So it's not a compromised solution. It works and is deployed.

Thanks

Regards … Zafar

From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 28, 2014 9:16 AM
To: "Giovanni Martinelli (giomarti)" <[email-masked]<mailto:[email-masked]>>
Cc: zali <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Giovanni, Hi!

Regards,
-Pavan

Cheers
G

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 28 Feb 2014 15:04:18 +0000

Zafar,
As of today the label set object cannot govern label selection for the upstream label. You need either:

a)      Notion of label-symmetrical bidirectional LSPs or

b)      Notion of upstream label set
None of this defined in the documents you refer to.

Igor

From: CCAMP [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Friday, February 28, 2014 10:00 AM
To: Vishnu Pavan Beeram; Giovanni Martinelli (giomarti)
Cc: [email-masked]
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Hi Pavan:

Thanks

Regards ... Zafar

Giovanni, Hi!

Regards,
-Pavan

Cheers
G

---

From: John E Drake <[email-masked]>
Date: Fri, 28 Feb 2014 15:05:54 +0000

Right, in your proprietary non-GMPLS product.

Yours Irrespectively,

John

From: CCAMP [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Friday, February 28, 2014 7:00 AM
To: Vishnu Pavan Beeram; Giovanni Martinelli (giomarti)
Cc: [email-masked]
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Hi Pavan:

Thanks

Regards ... Zafar

Giovanni, Hi!

Regards,
-Pavan

Cheers
G

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 28 Feb 2014 15:54:05 +0000

Igor-

And we also had this discussion but you did not find a use case for asymmetrical label.

----------- begin forwarded message -----

-----Original Message-----
From: Fatai Zhang <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 5, 2013 3:20 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] 答复:  答复: Comments about
draft-beeram-ccamp-network-assigned-upstream-label-00

For the transport/GMPLS networks, I would repeat the bidirectional LSPs
are always symmetric in practice, so there are no cases for some nodes to
assign asymmetric labels.

I agree. Just want to add as CCAMP should NOT be assuming some research work.

Thanks

Regards...Zafar

----------- end of forwarded message -----

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 28, 2014 10:04 AM
To: zali <[email-masked]<mailto:[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>, "Giovanni Martinelli (giomarti)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] Network Assigned Upstream Label - Draft Update

Zafar,

Igor

Hi Pavan:

Thanks

Regards … Zafar

Giovanni, Hi!

Regards,
-Pavan

Cheers
G

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 28 Feb 2014 16:04:34 +0000

Gert-

What label has to do with overlay vs. peer? If so, there is a terminology document in this area that WG is working on – please contribute to it first.

Thanks

Regards … Zafar

From: Gert Grammel <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 28, 2014 9:53 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>, "Giovanni Martinelli (giomarti)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Giovanni,

Gert

From: CCAMP <[email-masked]<mailto:[email-masked]>> on behalf of Igor Bryskin <[email-masked]<mailto:[email-masked]>>

Hi,

Cheers,
Igor

Giovanni, Hi!

Regards,
-Pavan

Cheers
G

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 28 Feb 2014 16:05:52 +0000

Zafar,
Documents you refer to (e.g. RFC 3473):

a)      is not just about WDM layer

b)      does not assume label symmetricity

c)      does not consider complications introduced by overlay network
And the point of the document we are working on exactly is to complement RFC3473 with simple notion and simple mechanism.

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Friday, February 28, 2014 10:54 AM
To: Igor Bryskin; Vishnu Pavan Beeram; Giovanni Martinelli (giomarti)
Cc: [email-masked]
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Igor-

----------- begin forwarded message -----

-----Original Message-----
From: Fatai Zhang <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 5, 2013 3:20 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"

Thanks

Regards...Zafar

----------- end of forwarded message -----

Thanks

Regards … Zafar

Zafar,

Igor

Hi Pavan:

Thanks

Regards … Zafar

Giovanni, Hi!

Regards,
-Pavan

Cheers
G

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 28 Feb 2014 16:09:14 +0000

Hi-

Yes, if you call explicit text in RFC3473 and draft-ietf-ccamp-wson-signaling-06 as proprietary, please go ahead.

Thanks

Regards … Zafar

Date: Friday, February 28, 2014 10:05 AM

Yours Irrespectively,

John

Hi Pavan:

Thanks

Regards … Zafar

Giovanni, Hi!

Regards,
-Pavan

Cheers
G

---

From: Gert Grammel <[email-masked]>
Date: Fri, 28 Feb 2014 16:29:01 +0000

Hi Zafar,

I was responding to Giovanni's comment: GM> for the wson case the LABEL_SET might be an output from the RWA process, so the signalling likely pick up a good label first time.

So the ingress has to take an educated decision to get to a 'good label'. However in a world where the ingress has no idea of which label is available, it is not 'educated' and simply has to guess.
This is related to visibility a client may have of the network. Full, partial or none. (You can translate this into your preferred model)

Network assigned upstream labels can work well in either case as there is no pre-knowledge about labels assumed.

Gert

________________________________
From: Zafar Ali (zali) <[email-masked]>
Sent: Friday, February 28, 2014 5:04:34 PM
To: Gert Grammel; Igor Bryskin; Vishnu Pavan Beeram; Giovanni Martinelli (giomarti)
Cc: [email-masked]
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Gert-

Thanks

Regards … Zafar

Giovanni,

Gert

Hi,

Cheers,
Igor

Giovanni, Hi!

Regards,
-Pavan

Cheers
G

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 28 Feb 2014 16:41:51 +0000

Hi Gert-

Yes, it may require Perr for label correction but it works, deployed and is based on what is already documented in RFC3473 and wson-signaling WG document. What you are asking for is a "redundant/ duplicate" method just for the sake of an academic optimization!

Thanks

Regards … Zafar

From: Gert Grammel <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 28, 2014 11:29 AM
To: zali <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>, "Giovanni Martinelli (giomarti)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Hi Zafar,

Gert

From: Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>

Gert-

Thanks

Regards … Zafar

Giovanni,

Gert

Hi,

Cheers,
Igor

Giovanni, Hi!

Regards,
-Pavan

Cheers
G

---

From: Lou Berger <[email-masked]>
Date: Fri, 28 Feb 2014 12:19:52 -0500

The use of / debate on acceptable label set goes all the way back to its
introduction.  It always came down to a trade off of what mechanism
would be sufficient for the normal ("G") cases and to what level we'd
optimize for special cases.  I think the draft implicitly revisits one
particular trade off decision and argues that what was once a special
case is now a common case -- that should be optimized.

I really think this is the first point to reach any agreement on.

I personally think that the use of a special or reserved upstream label
is a fine way, with established precedent, to indicate such special
processing. (That is, if we were to decided that such is warranted in
this case.)

Lou

On 02/28/2014 09:36 AM, Giovanni Martinelli (giomarti) wrote:
> Hi John,
> 
> yes clear,  I was just bringing back on the table discussion we got on
> the same problem. The second option in better (although contention
> window is reduced but not avoided) however we had no numbers to justify
>  that such optimization or … at least not so strong  reasons to update a
> mechanism that was proven to work.
> 
> Cheers
> G
> 
> 
>> *From:* CCAMP [mailto:[email-masked]] *On Behalf Of *Giovanni
>> Martinelli (giomarti)
>> *Sent:* Friday, February 28, 2014 4:54 AM
>> *To:* Vishnu Pavan Beeram
>> *Cc:* [email-masked] <mailto:[email-masked]>
>> *Subject:* Re: [CCAMP] Network Assigned Upstream Label - Draft Update
>>  
>> Hi Vishnu,
>>  
>>     (2) The use of Label-Set/Acceptable Label-Set was meant to be used
>>     for exceptions. Using it always for every setup request is a
>>     compromised solution.
>>      
>>
>>  
>> At the time we discussed the wson signaling
>> (http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06), the
>> acceptable label set was considered good enough. Not sure it comes
>> into play at every request since your label_set should have reasonably
>> good labels.
>>  
>> Cheers
>> G
> 
> 
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: John E Drake <[email-masked]>
Date: Fri, 28 Feb 2014 18:02:58 +0000

Zafar,

Actually, it was *you* that used the P-word:

"For the other cases, please note that just because optical network is running GMPLS UNI for client interface does not mean that it is running RSVP-TE for the optical trail management. E.g., optical trail management can still using an already deployed proprietary mechanisms or an NMS based scheme."

Thanks

Regards ... Zafar"

Yours Irrespectively,

John

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Friday, February 28, 2014 8:09 AM
To: John E Drake; Vishnu Pavan Beeram; Giovanni Martinelli (giomarti)
Cc: [email-masked]
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Hi-

Thanks

Regards ... Zafar

Yours Irrespectively,

John

Hi Pavan:

Thanks

Regards ... Zafar

Giovanni, Hi!

Regards,
-Pavan

Cheers
G

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 28 Feb 2014 14:20:00 -0500

@Lou - Thanks for lending some direction to this thread (it was going in
cycles).

Zafar/Giovanni,

Do you agree that wrt alien wavelengths, "signaling a setup request without
knowing what upstream-label to use" is not some remote special case?
Yes or No?

Regards,
-Pavan

On Fri, Feb 28, 2014 at 12:19 PM, Lou Berger <[email-masked]> wrote:

> >  that such optimization or ... at least not so strong  reasons to update a

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 28 Feb 2014 20:36:11 +0000

Hi Pavan-

This is an academic optimization. What we can do is to write a BCP or info draft based on method already documented in RFC3473 and wson signaling.

Thanks

Regards … Zafar

From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 28, 2014 2:20 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

@Lou - Thanks for lending some direction to this thread (it was going in cycles).

Zafar/Giovanni,

Do you agree that wrt alien wavelengths, "signaling a setup request without knowing what upstream-label to use" is not some remote special case?
Yes or No?

Regards,
-Pavan

On Fri, Feb 28, 2014 at 12:19 PM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:

Lou

On 02/28/2014 09:36 AM, Giovanni Martinelli (giomarti) wrote:
> On 28 Feb 2014, at 14:10, John E Drake <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>> Giovanni,
>>
>> *From:* CCAMP [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *Giovanni
>> Martinelli (giomarti)
>> *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>> On 28 Feb 2014, at 13:26, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Fri, 28 Feb 2014 15:51:03 -0500

Pavan,
	I have personally seen some instances, albeit rare,  when acceptable
label set worked, but resulting in a fair amount of added latency in LSP
establishment.  So I can understand the instinct to optimize this.  --
And I know your use case is different.

One thing I grappled with when thinking about it at the time was to
figure out when the downstream node can send data.  Now it's when the
path message is received.  Your draft is silent on this point. Are you
assuming use of ResvConf as some have in the past? I think this is a
pretty important/fundamental point to address.

Lou

On 02/28/2014 03:36 PM, Zafar Ali (zali) wrote:
> Hi Pavan- 
> 
> This is an academic optimization. What we can do is to write a BCP or
> info draft based on method already documented in RFC3473 and wson
> signaling. 
> 
> Thanks
> 
> Regards … Zafar
> 
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>     Do you agree that wrt alien wavelengths, "signaling a setup request
>     without knowing what upstream-label to use" is not some remote
>     special case? 
>     Yes or No?
> 
>     Regards,
>     -Pavan
> 
>         > On 28 Feb 2014, at 14:10, John E Drake <[email-masked] <mailto:[email-masked]>
>         > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>         >
>         >> Giovanni,
>         >>
>         >> *From:* CCAMP [mailto:[email-masked] <mailto:[email-masked]>] *On
>         Behalf Of *Giovanni
>         >> Martinelli (giomarti)
>         >> *Cc:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         >> On 28 Feb 2014, at 13:26, Vishnu Pavan Beeram <[email-masked] <mailto:[email-masked]>
>         >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>         >>
>         >>
>         > [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 28 Feb 2014 16:12:22 -0500

Lou, Hi!

The initial version (00) had some details illustrating when the downstream
node can send data. But we stripped that out in the current version because
it seemed more of an implementation detail.

Implementations may choose to use "Resv Conf" (as you mentioned) or a
2-step graceful setup procedure using ADMIN_STATUS (start with the A bit
set; clear it when the LSP is ready for use). Either approach doesn't need
any new protocol extensions.

Regards,
-Pavan

On Fri, Feb 28, 2014 at 3:51 PM, Lou Berger <[email-masked]> wrote:

> >         >> Use of acceptable doubles the signaling overhead and opens up
> a
> >         >> contention window:
> >         >>
> >         >> 1)      Path
> >         >> Also, it's generally considered a bad idea(tm) to include error
> messages
> >         >> in the normal operation of a protocol
> >         >>
> >         >> Yours Irrespectively,
> >         >>
> >         >> John
> >         >>
> >         >> On 28 Feb 2014, at 13:26, Vishnu Pavan Beeram <
> [email-masked] <mailto:[email-masked]>
> >         >> (

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 28 Feb 2014 16:14:44 -0500

Zafar, Hi!

You still haven't answered my question. It needs a simple yes/no answer.

Regards,
-Pavan

On Fri, Feb 28, 2014 at 3:36 PM, Zafar Ali (zali) <[email-masked]> wrote:

> To: "[email-masked]" <[email-masked]>
> without knowing what upstream-label to use" is not some remote special
> case?
>  Yes or No?
>
>  Regards,
>  -Pavan
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 28 Feb 2014 21:21:02 +0000

Hi-

It's a technology specific use case, which is handled by "G"MPLS. I sincerely think what we need is an info or BCP draft.

Thanks

Regards … Zafar

From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 28, 2014 4:14 PM
To: zali <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Zafar, Hi!

Regards,
-Pavan

On Fri, Feb 28, 2014 at 3:36 PM, Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pavan-

Thanks

Regards … Zafar

Zafar/Giovanni,

Regards,
-Pavan

Lou

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 28 Feb 2014 21:21:10 +0000

Lou- 

Can you please be specific why you think acceptable label set only works
"rarely"? 

Thanks

Regards Š Zafar

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Friday, February 28, 2014 3:51 PM
To: zali <[email-masked]>, Vishnu Pavan Beeram <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

>> Regards Š Zafar
>>         >  that such optimization or Š at least not so strong  reasons
>>to update a
>>         >> Use of acceptable doubles the signaling overhead and opens
>>up a
>>         >> contention window:
>>         >>
>>         >> 1)      Path
>>         >> Also, it¹s generally considered a bad idea� to include error
>>messages
>><mailto:[email-masked]
>>         >> On 28 Feb 2014, at 13:26, Vishnu Pavan Beeram
>><[email-masked] <mailto:[email-masked]>

---

From: Lou Berger <[email-masked]>
Date: Fri, 28 Feb 2014 16:33:42 -0500

Pavan,
	I agree that there are existing mechanisms *could* be used, but your
document is changing the data place service model so it is the one that
needs to specify the new model...

Lou

On 02/28/2014 04:12 PM, Vishnu Pavan Beeram wrote:
> Lou, Hi!
> 
> The initial version (00) had some details illustrating when the
> downstream node can send data. But we stripped that out in the current
> version because it seemed more of an implementation detail. 
> 
> set; clear it when the LSP is ready for use). Either approach doesn't
> need any new protocol extensions.
> 
> Regards,
> -Pavan
> 
> 
> On Fri, Feb 28, 2014 at 3:51 PM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Pavan,
>     > From: Vishnu Pavan Beeram <[email-masked]
>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>
>     > To: "[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>"
>     <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>
>     > Cc: "[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>
>     >     On Fri, Feb 28, 2014 at 12:19 PM, Lou Berger <[email-masked]
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >
>     >         would be sufficient for the normal ("G") cases and to what
>     level
>     >         we'd
>     >         > On 28 Feb 2014, at 14:10, John E Drake
>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >         > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>     >         >
>     >         >> Giovanni,
>     >         >>
>     >         >> Use of acceptable doubles the signaling overhead and
>     opens up a
>     >         >> contention window:
>     >         >>
>     >         >> 1)      Path
>     >         >> Also, it’s generally considered a bad idea™ to include
>     error messages
>     >         >> *From:* CCAMP [mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>] *On
>     >         Behalf Of *Giovanni
>     >         >> Martinelli (giomarti)
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>     >         <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >         >> <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>> wrote:
>     >         >>
>     >         >>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Lou Berger <[email-masked]>
Date: Fri, 28 Feb 2014 16:36:27 -0500

Zafar,
	I think you miss-parsed my words.  the instances I witnessed were rare.
The protocol behaved as designed.

Lou

On 02/28/2014 04:21 PM, Zafar Ali (zali) wrote:
>>> <mailto:[email-masked]>>
>>> <mailto:[email-masked]>] *On
>>>         Behalf Of *Giovanni
>>>         >> Martinelli (giomarti)
>>> <mailto:[email-masked]>>> wrote:
>>>         >>
>>>         >>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 28 Feb 2014 16:56:25 -0500

Lou,

OK. We'll add some text ("informational" section) in the next version
detailing how existing mechanisms can be used to let the downstream node
know when the LSP is operational.

Regards,
-Pavan

On Fri, Feb 28, 2014 at 4:33 PM, Lou Berger <[email-masked]> wrote:

> >     >         The use of / debate on acceptable label set goes all the
> way
> >     >         back to its
> >     >         particular trade off decision and argues that what was
> once a
> >     >         special
> >     >         >> Also, it's generally considered a bad idea(tm) to include
> >     error messages

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 28 Feb 2014 22:22:53 +0000

As you know Lou is talking about different and broader problem , which we plan to addfess ib a separate draft 
________________________________________
From: CCAMP [[email-masked]] on behalf of Vishnu Pavan Beeram [[email-masked]]
Sent: Friday, February 28, 2014 4:56 PM
To: Lou Berger
Cc: [email-masked]
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Lou,

OK. We'll add some text ("informational" section) in the next version detailing how existing mechanisms can be used to let the downstream node know when the LSP is operational.

Regards,
-Pavan

On Fri, Feb 28, 2014 at 4:33 PM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
Pavan,
        I agree that there are existing mechanisms *could* be used, but your
document is changing the data place service model so it is the one that
needs to specify the new model...

Lou

On 02/28/2014 04:12 PM, Vishnu Pavan Beeram wrote:
> On Fri, Feb 28, 2014 at 3:51 PM, Lou Berger <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Pavan,
>     > From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>     > <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>     > To: "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>"
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     > <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>     > Cc: "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     > <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>     >     On Fri, Feb 28, 2014 at 12:19 PM, Lou Berger <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>     >     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>     >
>     >
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >         > <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>> wrote:
>     >         >
>     >         >> Giovanni,
>     >         >>
>     >         >> *From:* CCAMP [mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>] *On
>     >         Behalf Of *Giovanni
>     >         >> Martinelli (giomarti)
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     >         <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >         >> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>>> wrote:
>     >         >>
>     >         >>
>     >         > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>