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

[Vishnu Pavan Beeram <[e-mail]>]

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) <[e-mail]>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:[e-mail]] *On Behalf Of *Vishnu Pavan
> Beeram
> *Sent:* 2014年2月25日 11:38
> *To:* [e-mail]
> *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,
>
> -Pavan (on behalf of the authors)
>
> ps: Attached slideset (pdf) gives a quick overview of the draft
>