The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Section A.1.2 RFC 3036 concerns!
suchauhan@hss.hns.com wrote: > Hi! > I have a few concerns regarding the algo defined in this section > > 1. LMp.10 - In this case should we not consider this as a dual purpose message > for the release of the previous label and installing the new label generated by > the same downstream LSR. I strongly think it gives a better logic to the > situation here as we have confirmed already that this is from our current > next-hop for that FEC. No. See "http://cell.onecall.net/mhonarc/mpls/current/msg00004.html", second paragraph in particular. > > > 2. LMp.14 - How do we actually define a Ingress LSR? In my opinion any LSR > should be able to act as Ingress atleast till the point the network IGP comes > into stable state as till that point packets to the same destination may be > coming from different Ingress routers. I would probably use something like - For > the LMp.14 case we should have a FTN entry created and then time it out using > say LRU algorithm to keep the size of FTN in check. Am I correct? Out of scope for specification. This falls under the heading of 'figure it out or find another line of work'. :-) (Your opinion on who must be an Ingress is not technically correct. Apply the same reasoning to who must be an egress, and you may find some satisfaction) See any of about a thousand postings on Label Edge Router functionality, over the last 2 years. > > > 3. LMp.17 - Why do we need to send this also to the Peer LSR fro which the > mapping has been learnt? Someone has raised the question earlier as well but I > am still not convinced about the right approach here. See note 7 - as it already says. > > > 4. LMp.21 - In the message sent should not "PrevAdvLabel" be just "Label". We > are only sending the current mapping and not the previous one here. No. We are re-advertising the same label - in case there is a change in hop count or path vector. > > > 5. Lmp.28 - Should this not be done before LMp.20 so that we may not have to > resend to the same peer twice (once because we are in DU mode and again when we > realise we also have an outstanding request for a label from the same peer). I > know this will not cause a problem as the peer will reject the second mapping > but seems an awful waste of processing and network bandwidth (same as in point 1 > above). No. Assume we are operating in DU advertisement, ordered control, mode. If we have an outstanding request from an LSR peer that is upstream with respect to a particular FEC, then it MUST be because the upstream LSR is looking for at least two labels. The label advertisement mode is negotiated between peers and both must use the mode negotiated. Therefore, for an LSR that is operating in DU mode to send a label request, it must expect at least two label mappings. The current procedure arrives at the correct behavior. > > > regards > sumit
|
|