[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Inter-domain FRR Facility backup - discussion
Can the ASBR help out here:
- Can it advertise a route with itself as the next hop for the PLR into the
MPs domain whenever it sees a bypass tunnels path msg going through it ?
First of all, how is the bypass itself signalled without any issues ? The
PLR wont know the topology of the other domain to route the path msg to the
MP in a node disjoint way.
Regards,
Vijay
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Arthi Ayyangar
> Sent: Tuesday, February 28, 2006 1:25 PM
> To: ccamp@ops.ietf.org
> Subject: Inter-domain FRR Facility backup - discussion
>
>
> Hi,
>
> Currently the merging of Backup Paths using the Sender
> Template-specific
> method relies on a different src address, but same LSP ID in the
> SENDER_TEMPLATE for the backup LSP compared to that of the
> protected LSP.
> (6.1.1 of rfc 4090). After a failure, during local repair,
> backup LSP Path
> msgs are "tunneled" over the bypass directly to the MP and
> the Resv from
> MP is IP routed back to the address set in the RSVP_HOP
> (6.4.3) of the
> backup LSP.
>
> As per the spec, the src address used for backup LSP has to be some
> address on the PLR. I am not sure what the usual practice is,
> but from
> what I understand, it would be okay currently, to put any
> local interface
> address on the PLR in the RSVP_HOP as per the spec.
>
> However, when the bypass LSP traverses different domains, and
> the PLR and
> MP are internal nodes in different domains, the MP is
> unlikely to have a
> route back to the interface address set in the RSVP_HOP for
> the backup
> LSP. So it will be unable to route back the Resv to the PLR.
> This will
> prevent the backup LSP from coming up.
>
> So the issue is finding a way to route back the Resv from MP to PLR.
>
> We could say that in case of inter-domain LSPs, the address
> that the PLR
> chooses should be the router-id of the PLR. But this has the
> following
> issues:-
> i) If we wan't specific behavior recommendation for inter-domain LSPs,
> then we need to specify conditions to define an LSP as an
> inter-domain
> LSP at an LSR.
> ii) Using router id could increase the chances of this sender template
> (src addr + lsp id) being confused with that of some
> other LSP being
> originated from this router and terminating on the MP.
> ii) For inter-AS LSPs, it may not be common for nodes inside one AS to
> have routes to router-ids (or loopbacks) of "internal nodes" in
> another AS.
>
> Do you see this as an issue worthy of discussion ?
> Any ideas / suggestions / recommendations ?
>
> thanks,
> -arthi
>
DISCLAIMER
This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies
and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the
individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to
read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error,
please notify the sender immediately by return e-mail and delete it from your computer