[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LSPID for Segment Recovery

Hi Snigdho,

No-one else seems willing to answer you, so I'll pick it up...


I have a doubt on the relationship between LSPID and association
ID for tunnels with segment recovery. Would appreciate it if
someone could clarify.

RFC4872 suggests using the working LSP's LSPID as the
association ID in the ASSOCIATION object for the recovery
LSP and the reverse for the working LSP and RFC4873
requires the use of this definition as per the following extract:

2.  Segment Recovery

  snip ...... snip

  When [RFC4090] isn't being used, the association between segment
  recovery LSPs with other LSPs is indicated using the ASSOCIATION
  object defined in [RFC4872]

I would expect this definition includes the way the association
ID value should be assigned, is my understanding correct?

I can understand how the ASSOCIATION object for the recovery
LSP can have its association ID set to the working LSP LSPID but
it may not be possible for the reverse since there could be multiple
recovery LSP segments.


I think the clue may be in section 3.2.1 of RFC 4873

  Recovery type processing procedures are the same as those defined in
  [RFC4872], but processing and identification occur with respect to
  segment recovery LSPs.  Note that this means that multiple
  ASSOCIATION objects of type recovery may be present on an LSP.


I would like to understand what should the working LSP association
ID be in case of segment recovery, should it be set to its own LSPID?

Also, my understanding is that the association ID needs to be unique
in the context of the association source, if that is the case does it
mean if LSPID is used as the association ID then the LSPID should
also be unique in the context of the association source rather than the
context of a tunnel.
Association only happens between LSPs belonging to the same session. Thus, LSP ID is sufficiently unique. See 4872 for a fuller description. 

Cheers,
Adrian