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

[Ben Wright <[e-mail]>]

Hi Fatai,

Thanks for your responses.

In terms of how to make this more extensible, there are a few options.   I¡¯d probably opt for something along the following lines.

- I can envisage that there could be a lot of FA-LSP-specific parameters that would need to be signalled, and so I¡¯d propose we don¡¯t add all these parameters into the ERO itself.   Instead, we could define the SERVER_LAYER_INFO ERO subobject so it just indicates that an FA-LSP with a particular ID must be created to the next ERO hop but does not include any TE parameters or adaptation information.
- I¡¯d then add a separate FA-LSP-ID object, which carries all the parameters for the FA-LSP.   This object could include a variable number of other RSVP objects (e.g. SESSION, SENDER_TSPEC, ERO etc).
- I¡¯d like to include a statement on the lifetime of the FA-LSP ¨C for example, if an RSVP SESSION and SENDER_TSPEC object were mandatory then that would provide identifiers for the FA-LSP, and then we could state that the FA-LSP should exist until it is destroyed by network administrators.

What do you think?  If this is not clear, I can propose some protocol formats to help illustrate the point.

Ben


From: Zhangfatai [mailto:[e-mail]]
Sent: 21 February 2012 18:21
To: Ben Wright; [e-mail]
Cc: [e-mail]; Steve Balls
Subject: ´ð¸´: Comments on draft-zhang-ccamp-gmpls-h-lsp-mln-04

Hi Ben,

Thanks for your suggestions and look forward to discussing more on this topic.

See more in-line below.

Thanks

Fatai


________________________________
·¢¼þÈË: Ben Wright [[e-mail]]
·¢ËÍʱ¼ä: 2012Äê2ÔÂ17ÈÕ 20:43
µ½: Zhangfatai; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Steve Balls
Ö÷Ìâ: Comments on draft-zhang-ccamp-gmpls-h-lsp-mln-04
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?

[Fatai] This draft does not touch how to advertise the link formed by H-LSP. Given that H-LSP is broader than FA-LSP, so I will answer "yes" to your question.

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?).

[Fatai]  Yes, agree with you. FA-LSP creation triggered by the client layer should be governed by the network administrators, so it is a good idea to have more information in the signaling for the purpose of administration.

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)?

[Fatai]  Agree to making the format more extensible. I would like to hear from you on how to make it.

What do you think?

Cheers,

Ben (and Steve)


From: Zhangfatai [mailto:[e-mail]]
Sent: 07 February 2012 01:30
To: Ben Wright; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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  ¨C 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