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

[<[e-mail]>]

Luyuan,

[snipped]

> > 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 for having checked and settled that point.

Regards,
Bruno

> De : Luyuan Fang (lufang) [mailto:[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