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

[John E Drake <[e-mail]>]

Zafar,

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

Yours Irrespectively,

John

From: Zafar Ali (zali) [mailto:[e-mail]]
Sent: Friday, February 28, 2014 6:00 AM
To: John E Drake; Vishnu Pavan Beeram; Zhangxian (Xian)
Cc: [e-mail]
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.

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: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Friday, February 28, 2014 7:03 AM
To: zali <[e-mail]<mailto:[e-mail]>>, Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>, "Zhangxian (Xian)" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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

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



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


 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.

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