Re: [mpls] wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt

[<[e-mail]>]

Hi Luyuan,

Thanks for your detailed answers.
More in-line.

Bruno

> De : Luyuan Fang (lufang) [mailto:[e-mail]]
> 
> Hi Bruno,
> 
> Thank you for the comments. Please see in-line.
> 
> > -----Original Message-----
> >
> > Hi Markus, Alia, Luyuan, all,
> >
> > A few comments:
> >
> > 1) May be the document should talk about its interaction with
> > graceful restart. (I guess this document should not be used
> > when GR is used, unless GR is aborted or failed.).
> >
> 
> Very good point. Let's try to look the relationship between LDP-IGP
> synch (LDP-IGP) and Graceful Restart (GR). In fact, LDP-IGP is also used
> when GR is used.
> 
> There are LDP GR [RFC 3478] and IGP GR - OSPF GR [RFC 3623] and ISIS GR
> [RFC 3847].
> 
> A. LDP GR and LDP-IGP synch:
> 
> LDP GR provides a mechanism to minimize the impact on MPLS labeled
> traffic caused by LSR's control plane restart. LDP GR is taking the
> proactive approach.
> 
> LDP-IGP synch is reactive, it provides the exchange and synch action
> between LDP and IGP when LDP is already failed. It prevents router
> sending traffic to the path where IGP is up and LDP is down.
> 
> There are many occasions you don't have a chance to gracefully restart.
> E.g. bring up a new link; operational error - missed to configure LDP;
> implementation error causes label corruption, etc.
> 
> Both LDP GR and LDP-IGP synch provide labeled traffic protection under
> different conditions.

Agreed: both GR and LDP-IGP sync have value and can be enabled on the same router at the same time.

My point was that for a given failure, only one of mechanism should take care of the failure. So if GR handle the failure, eg LDP session failure, LDP-IGP sync should not change the IGP link cost.

> B. IGP GR and LDP-IGP synch
> 
> IGP GR or non-stop forwarding (NSF) is to keep IGP router stay on the
> forwarding path even as its IGP is restarted.
> 
> An IGP instance performing NSF should honor the LDP-IGP synch procedure
> to check the LDP-IGP synch parameter on the standby routing device.

Do you mean: what should we do if between two neighbor routers, IGP GR is working but is still underway while LDP GR failed?
I didn't think of this specific interaction but the subject of interaction between IGP and LDP GR procedures seems broad. I don't have detailed knowledge of IS-IS GR, but in general to stay in the safe area, it seems that the IGP topology should not change during the IGP GR procedure. So in this case, what should be the LDP-IGP sync behavior?

Note that these GR interactions are not specific to the IGP-LDP sync draft. Eg: what should we do if IGP GR succeed and BGP GR failed? (for a node proving connectivity between two ASBRs of the same AS where tunneling (MPLS or IP) is not used).

so we can probably keep this out of this draft

> IGP GR protects traffic during the switch over. LDP-IGP protects labeled
> traffic from being blackholed when LDP is faulty for some reason while
> IGP is still up.
> 
> >
> > 2) " While the link could still be used for IP forwarding, it
> > is not useful for traffic with packets carrying a label stack
> > of more than one label or when the IP  address carried in the
> > packet is out of the
> > RFC1918 space."
> >
> > It seems that the use of RFC 1918 IP address is just an
> > example. One could find others (eg BGP free core).
> > Proposition to change to " While the link could still be used
> > for IP forwarding, it is not useful for MPLS forwarding (e.g.
> > MPLS VPN, BGP free core.)"
> >
> 
> Agreed. We can used both examples.
> 
> How about we say "While the link could still be used for IP forwarding,
> it is not useful for MPLS forwarding, e.g., MPLS VPN; BGP route free
> core; IP address carried in the packet is out of the RFC1918 space,
> etc."?

Fine, thanks.

> >
> > 3) "The LDP protocol itself has currently no means to
> > indicate to a service depending on it whether there is an
> > uninterrupted label switched path available to the desired
> > destination or not."
> >
> > Eventually, it could be useful to say why LDP ordered mode +
> > FEC withdraw is not an existing mean.
> 
> LDP is not a routing protocol. IGP directs the traffic to the shortest
> path regardless there is an established LSP along the path or not. Under
> the LDP down and IGP up condition: When LDP Ordered Control is used, the
> labeled packets drop happens at the LSR of the ingress of network as LSP
> cannot be established on the shortest path selected by IGP; When
> Independent Control is used, the labeled packets drop happens at the LSR
> where LDP failed (could be a mid point in the LSP) as the LSP is broken.
> We have seen both blackholing cases in live networks. For more details
> on LDP blackholing problems and solution, also see "LDP Failure
> Detection and Recovery", by L. Fang, A. Atlas, F. Chiussi, K. Kompella,
> and G. Swallow, IEEE Communications Vol.42 No.10, October 2004.
> 
> > Or may be you want to say that LDP has currently no way to
> > correct the issue, for example by using a different IGP path.
> >
> 
> Yes, thanks. We can re-word this similar as you suggested: LDP has
> currently no way to correct the issue. LDP is not a routing protocol, it
> cannot re-direct traffic to an alternate IGP path.

Fine, thanks.

> 
> > 4) "In the case of OSPF this cost is LSInfinity (16-bit value
> > 0xFFFF) as proposed in [RFC3137]."
> >
> > Could you also indicate the metric to use for IS-IS?
> > Especially since:
> > - further in the doc you recommend that all implementation
> > use the same metric to avoid asymmetric link cost
> > - RFC 3784 seems to indicate that the max metric link (2^24 -
> > 1) is already reserved
> >
> 
> Very good point.
> We shall add the ISIS max metric in the draft. The max metric value for
> ISIS using wide metrics is 0xFFFFFE per RFC 3784.
 
Thanks.

> 
> > 5) "It is recommended that both sides of a link implement
> > this mechanism to be effective and to avoid asymmetric link
> > costs which could cause problems with IP multicast forwarding."
> >
> > Avoiding asymetric link cost during all the procedure would
> > require that both routers sharing the LDP session have the
> > same way to detect when "LDP is considered fully
> > operational". This is currently not the case.
> 
> Understood. It is a recommendation for better performance, not a
> requirement.
> 
> > As the document propose to wait "some time", the document
> > could possibly propose a default value for this timer and
> > warn that if the operator wish to change that value, it
> > should change it on both side of the LDP session.
> >
> 
> We prefer not to set the hold-down timer with a default value. The
> reason is that the LIB tables size can vary largely, as well the
> equipment capability/speed. If the default value is too small, this
> function would not work; if it is too big, it slows down the convergence
> time. But the hold-down time guidelines through equipment testing would
> be helpful.

You're right but this discussion could apply to lot of default timers. Eg GR timers. Yet most specification defines default values for their timers.

> LDP End-of-LIB (draft-asati-mpls-ldp-end-of-lib-01.txt) is currently a
> work in progress. When End-of-LIB is implemented, it can signal the end
> of IGP hold-down time, no longer need for the configured nor default
> timers.

OK, given this, I guess it's not a big deal not to define default value for the timers. May be the document could say that such LDP sync mechanism (LDP End of LIB) should preferably be used (over timers) once they are available. (in order to avoid asymmetric routing)

> > Also, as there is a risk of transient asymetric link cost
> > (because the end of the procedure is not stricly defined)
> > could you possibly provide more precision on the problems
> > that could be faced by IP multicast?
> >
> 
> Yes, transient asymmetric cost is always a risk, it is not just for this
> problem, it is rather a common problem. e.g. it is same as in BGP. We
> would treat it as out of scope for this draft.

Ok but this document:
- Specifically states that asymmetric links cost could cause problem with multicast ("asymmetric link costs [which] could cause problems with IP multicast forwarding")
- In the short term (waiting for LDP end-of-LIB) does not fully avoid asymmetric link cost. Quite the contrary, compared to doing nothing, it creates new opportunity for this.

So could the draft just list (or reference a document describing) multicast issues with IGP asymmetric cost? Otherwise, as a service provider proving IP, MPLS VPN and multicast on the same AS, while LDP end-of-LIB is not available, I wonder if I should use this draft or not as the draft says it improves MPLS VPN availability but could create issues with multicast.

> > Thanks,
> > Regards,
> > Bruno
> >
> 
> Thanks,
> Luyuan
> 
> 
> > > From Loa Andersson
> > >
> > > Working group,
> > >
> > > this is to initiate a two week working group last call on:
> > >
> > > draft-ietf-mpls-ldp-igp-sync-01.txt
> > >
> > > Please send your comments to the working group mailing list
> > or to the
> > > working group chairs before April 11.
> > >
> > > Loa and George
> > >
> > > --
> > > Loa Andersson
> > >
> > > Principal Networking Architect
> > > Acreo AB                           phone:  [phone]
> > > Isafjordsgatan 22                  mobile: [phone]
> > > Kista, Sweden                      email:  [e-mail]
> > >                                             [e-mail]
> > > _______________________________________________
> > > mpls mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> >
_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls