The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] Requesting your feedback - issues/errors/clarifications
Vach Kompella wrote: >I agree we should get rid of the host FEC type. > >Issue: it would be nice to be able to shut down an adjacency without >having to time it out. E.g., two interfaces between the same pair of >nodes running LDP. If one is shut down, there is no way to notify the >peer endpoint, e.g., notification message to the multicast address over >UDP. > >Issue: do we really have to send all FECs in our database whenever we >have an LDP session between two peers? E.g., A is a PE which does LDP >for address FECs as well as PW FECs. If it sets up a targeted adjacency >clear across the network to another PE, does it really have to send all >its address FECs there? In our implementation, we do not send address >FECs across a session that was set up with a targeted adjacency, since >we only use targeted adjacencies for PW FECs. > >Issue: with all the combinations of Downstream Unsolicited, Downstream >on Demand, Ordered Control, Independent Control, etc., it makes sense to >define a mandatory combination. DU/OC seems to be the favored one. >E.g., IC was useful back when MPLS LSPs replaced IP forwarding. Now >that that isn't the case anymore, if there is a P router doing >independent control in the middle of the network, it propagates a FEC >for a tunnel that may be used by 2547, BGP-free core routing, or PWs, >falsely giving the impression that the PSN tunnel is end to end. It >would be far better to identify, at ingress, that the tunnel is not up. >In either case, we blackhole packets, but in one case, we clearly know >the service is not up, the route is not resolvable, etc., while in the >other, you have to figure that there is a problem somewhere in the >middle of the network. > > > Actually I disagree. If anyting we should have DU/IC , the ordered control caused lot's of operational problems , and it took almost a year to get it working properly. There are a number of situations that cause problems in ordered control mode , but not in independent control. Most of these issues are due to timing. >Issue: Minor optimization: why do you send a FEC back to the owner of >the FEC? E.g., A sends its loopback to B. Why should B send it right >back to A (as described in LMp.21)? > >Issue: Minor optimization: if A is a stub node, i.e., only one LDP >session, does it really have to send a label mapping for every FEC that >it has, or can it do it lazily, e.g., when it has a second LDP session? > > > No sure I understand what you mean here. LDP cannot know what path is selected, so it must send all the FECs. Luca >-Vach > > > >>-----Original Message----- >>From: mpls-bounces@lists.ietf.org >>[mailto:mpls-bounces@lists.ietf.org] On Behalf Of Markus Jork >>Sent: Tuesday, August 24, 2004 1:17 PM >>To: Ina Minei >>Cc: mpls@ietf.org >>Subject: Re: [mpls] Requesting your feedback - >>issues/errors/clarifications >> >> >> >> >>> RFC3036 (LDP specification) is advancing to draft standard. >>> >>> As part of this process, it is necessary to compile a list of >>>changes/clarifications to the rfc, based on the experience >>> >>> >>gained with >> >> >>>the protocol. >>> >>> Please send me errors/changes/clarifications that you >>> >>> >>know about, so >> >> >>>that they can be taken into account in the revised document. Please >>>send your comments by September 6, either directly to me or to the >>>list. >>> >>> >>Here is one issue: >>The spec defines two types of FECs: "address prefix" and >>"host address". The address prefix FEC is what's in >>widespread use. We have also implemented support for the host >>address FEC but I have never seen it used. It would be >>interesting to know whether there is any known actual use of >>it. If not, I suggest to remove it from the spec. >> >>Markus >> >> >> >> >>> I will post the complete list of the issues a couple of >>> >>> >>weeks later. >> >> >>> Thank you, >>> >>> Ina >>> >>> >> >>_______________________________________________ >>mpls mailing list >>mpls@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/mpls >> >> >> > > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|