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

["Luyuan Fang (lufang)" <[e-mail]>]

Bruno,

Thanks for the discussion again. Please see in-line.  
Luyuan

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 
> Sent: 14 April 2008 06:18
> To: Luyuan Fang (lufang)
> Cc: [e-mail]; [e-mail]
> Subject: RE: [mpls] wg last call on 
> draft-ietf-mpls-ldp-igp-sync-01.txt
> 
> 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)
> 
Agreed, we planned to mention LDP End of LIB work.

> > > 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.
> 
I have checked with several Multicast experts. The conclusion is that IGP asymmetric link cost does not cause 
problems for multicast. So we will remove that line.

> > > 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