[CCAMP] Comments on draft-zhang-ccamp-gmpls-h-lsp-mln-04

[Ben Wright <[e-mail]>]

Hi Fatai,

Thanks for pointing me at this draft.   I have a few questions on this.

The highest level clarification is that I wasn’t sure whether this is designed to address just FA-LSPs (which are advertised back into the same control plane instance) or any H-LSP (which may be advertised into a different control plane / routing protocol instance, if at all)?   I think that the draft addresses H-LSPs, is that true?

The rest of my comments break down into two broad areas:  Management of the automatically created FA/H-LSPs and extensibility to future enhancements.

FA-LSP Management

How does a network administrator manage these automatically created FA-LSPs?   I’m assuming that the server resource may not always (typically?) be in 1:1 correspondence with the client resource.   Is that correct?  If so, I think that this means that the FA-LSP cannot just be managed via signalling the client layer LSP, it must be able to be managed explicitly by network administrators.   So, for example, I suspect we’ll need to provide a mechanism to allow the client LSP signalling to carry a set of identifiers to be associated with the server LSP, so network administrators can manage it separately.   I’d also like to define the conditions under which the FA-LSP can be deleted (e.g. should it be deleted when the client layer LSP is deleted?).

Extensibility

I’d like us to use a more extensible format for encoding server layer information.  I can see that the mechanism described in the draft could be applicable to a wide variety of use cases in future and the ERO subobject format isn’t easy to extend to meet them.   Some examples where there might be a requirement to signal more information are below.

1.  It could be useful for the client-layer signalling to be able to specify parameters that the server layer should use to create the FA-LSP.   For example, it would be useful for the client layer to be able to specify that the server layer should create an FA-LSP to share resources with an existing FA-LSP.
2.  The client-layer signalling may need to be able to request the server layer creates multiple server layer LSPs to support the client layer connection (e.g. in a VCAT case)?

What do you think?

Cheers,

Ben (and Steve)


From: Zhangfatai [mailto:[e-mail]]
Sent: 07 February 2012 01:30
To: Ben Wright; [e-mail]
Cc: [e-mail]
Subject: RE: Signaling extensions for FA-LSPs (comment on draft-ietf-ccamp-gmpls-signaling-g709v3-01)

Hi Ben,

I agreed with the scenario and requirement you mentioned.

However, I think it is a kind of generic MLN scenario, not just specific to OTN signaling, so I was trying to capture this in a generic way and documented this in http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-h-lsp-mln-04.txt.

Please review this draft (draft-zhang-ccamp-gmpls-h-lsp-mln-04.txt) to see if this draft can address your concern.

Let’s discuss more on this issue.



Thanks

Fatai

From: Ben Wright [mailto:[e-mail]]
Sent: 2012年2月7日 1:05
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Signaling extensions for FA-LSPs (comment on draft-ietf-ccamp-gmpls-signaling-g709v3-01)

Hi Fatai et al,

We have been thinking about function we will need to add to draft-ietf-ccamp-gmpls-signaling-g709v3-01 to fully support automatically provisioned FA-LSPs.   I wanted to see whether you agree with our analysis.

We think that the RSVP-TE signalling should be extended to carry more information in order to allow other nodes on the signalling path to set up the correct FA-LSP.    For example, in the network in http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-01#section-7, we believe that N1 should be able to prescribe to N2 the set of hops that it should use to set up the ODU2 FA-LSP, and the signal type of the FA-LSP it should set up, and (probably) the multiplexing hierarchy to be used at either end.   Typically, we’d expect N1 would want to explicitly prevent N2 from querying routing to set up the FA-LSP  - otherwise, a routing calculation triggered by N2 could compute a path for the FA-LSP inconsistent with N1’s intentions (e.g. which could break some SRLG diversity requirement).

What do you think?   Is this an issue that you anticipate addressing in the text for section 7.1 (alluded to as being for future study)?

Thanks,

Ben Wright and Steve Balls