The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] draft-leroux-mpls-p2mp-te-bypass-00.txt
Hi Yuji Thanks for these comments Please see inline, > -----Message d'origine----- > De : Yuji KAMITE [mailto:y.kamite@ntt.com] > Envoyé : vendredi 6 octobre 2006 11:12 > À : LE ROUX Jean-Louis RD-CORE-LAN; mpls@ietf.org > Objet : RE: [mpls] draft-leroux-mpls-p2mp-te-bypass-00.txt > > Hi JL, > > > The below draft defines procedures for P2MP RSVP-TE > Fast Reroute with P2MP Bypass LSPs. > > > >http://www.ietf.org/internet-drafts/draft-leroux-mpls-p2mp-te > -bypass-00 > >.txt > <http://www.ietf.org/internet-drafts/draft-leroux-mpls-p2mp-te > -bypass-00.txt> > > May I ask a few questions? > > - The two words bypass and backup, in some part, might be confusing. > Are they completely different in the document? Yes they are. "bypass" refers to the bypass tunnel and "backup" refers to the LSP used to backup on of the many protected LSPs. This is actually inline with terminology in RFC4090: " Bypass Tunnel: An LSP that is used to protect a set of LSPs passing over a common facility. Backup Tunnel: The LSP that is used to backup up one of the many LSPs in many-to-one backup. " > I found a term "underlying bypass tunnnel, this appears to > be P2MP backup. Actually no, bypass tunnel =/= backup LSP > However, "backup" P2MP LSP seems to be used for upstrem assignment, > and I think it is not for forwarding layer (from LP to MP). The term is actually used both for control and data plane (backup label...) > (For example, Section 4.1 says that to signal the backup > P2MP LSP Path > messages are sent using directed signaling. I ask for > clarification.) During failure traffic of a protected P2MP LSP is rerouted onto a backup P2MP LSP itself nested within a P2MP Bypass tunnel. In the data plane there are two labels: the inner label is the label of the backup P2MP LSP (aka backup label) and the outer label is the label of the P2MP Bypass LSP. On MP the backup P2MP LSP is merged with the protected P2MP LSP, that is the traffic on the backup P2MP LSP is rerouted onto the protected P2MP LSP. This will be clarified in next revision. > > > - The draft says backup P2MP LSP has to signal the same > upstream inner label, > but I am not sure the actual timing when upstream > assignment happens. As indicated in the draft this is done before the failure, basically at the time the protected LSP is setup. > If it requires more procedures than before, it's hard for opertors. This is a new feature, that requires additional processing (there is always a minimum price to pay), but this does not require any additional provisionning (no extra configuration required). Think about the bandwidth savings wrt to the P2P bypass approach, particularly for protection of P routers attaching a large number of PEs... > > Suppose there is one protected P2MP tunnel LSP (a) and > one corresponding backup P2MP LSP (b), and they are already set up. > Now you configure a news P2MP tunnel LSP (c), and wish > it to be protected by (b) by the facility FRR as well. > Here we assume that (c) is traversing the same MP, > branches, etc. as (a). > In this case, is an inner label of (c) automatically signalled > with an upstream assignment scheme? Yes it is > IMHO more details should be specified to > distinguish two or more different protected tunnels. > I think this kind of topic does not exist in the today's > unicast facility FRR, so > it needs consideration. Actually backup LSP signaling before failure, with facility backup, is not a new scheme. This is required with P2P FRR, when using per-interface label space. See section 6.4.1 of RFC4090: "When MPs use per-interface label spaces, the PLR must send Path messages (for each protected LSP using a bypass tunnel) via that bypass tunnel prior to the failure in order to discover the appropriate MP label. The signaling procedures for this are in Section 6.4.3 below." What we do here is really similar, the only difference is the upstream label assignment. Best Regards, JL > > > Regards, > > -Yuji > > ________________________________ > > From: LE ROUX Jean-Louis RD-CORE-LAN > [mailto:jeanlouis.leroux@orange-ft.com] > Sent: Wednesday, September 27, 2006 3:17 PM > To: mpls@ietf.org > Subject: [mpls] draft-leroux-mpls-p2mp-te-bypass-00.txt > > > > Hi all, > > The below draft defines procedures for P2MP RSVP-TE > Fast Reroute with P2MP Bypass LSPs. > > http://www.ietf.org/internet-drafts/draft-leroux-mpls-p2mp-te- > bypass-00.txt > <http://www.ietf.org/internet-drafts/draft-leroux-mpls-p2mp-te > -bypass-00.txt> > > Your comments are welcomed. > > Regards, > > JL > > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls |
|