Hi Yakov, Yes IMO this would be good addition.
As to the default example perhaps it would be good to make it complete in a sense of adding label-bgp. We could say: In the scenario where a router obtains label binding for a given FEC from all (targeted) LDP, Label-BGP and IS-IS/OSPF, the default behavior RECOMMENDED in this document is to prefer the one obtained from (targeted) LDP followed by ISIS-OSPF one. An implementation MUST support the ability to override the default behavior via configuration. Thx, R. On Wed, May 21, 2014 at 3:07 PM, Yakov Rekhter <[email protected]> wrote: > Robert, > >> >> Hi Hannes & Yakov, >> >> Thank you for your opinion on this. >> >> My major concern is consistency among routers especially in large >> network. >> >> While indeed one may say that this is a local policy matter the >> question is can we do better then that especially where we are coming >> with new label distribution protocols. >> >> Also implementations need to somehow define such policy and perhaps >> setting a reference to a recommended order in RFC could be a good set >> of defaults ? >> >> Otherwise likely Murphy's law will apply :) > > How about if I'll add the following to the draft: > > > When a router obtains label binding for a given FEC from more than > one label distribution protocol (e.g., one binding from targeted LDP > and another from IS-IS/OSPF), deciding which label binding to use > is a matter of policy local to the router. > > In the scenario where a router obtains label binding for a given FEC > from both (targeted) LDP and IS-IS/OSPF, the default behavior > RECOMMENDED in this document is to prefer the one obtained > from (targeted) LDP. An implementation MUST support the > ability to override the default behavior via configuration. > > Yakov. > >> >> Cheers, >> R. >> >> >> On Tue, May 20, 2014 at 5:18 PM, Hannes Gredler <[email protected]> >> wrote: >> > hi robert, >> > >> > On Fri, May 16, 2014 at 08:21:38PM +0200, Robert Raszuk wrote: >> > | Hi, >> > | >> > | Two comments on this document. >> > | >> > | >> > | Question: >> > | >> > | Assume there is label binding received for a given FEC from/by >> > | multiple protocols. Which one should be chosen by the LSR to be >> used >> > | in data plane? Choosing wrong one may jeoparadise the hope of >> > | stitching. >> > >> > i'd assume that an implementation supporting multiple >> > label-distribution protocols, has an internal tie-breaking scheme and >> > install LSPs for a fiven FEC only from the highest ranking protocol. >> > >> > | Is consistent manual configuration across multiple LSRs an answer ? >> > >> > possibly; - see below; >> > >> > | If so document should mention that. Otherwise analogy of admin >> > | distance for FECs should be proposed. >> > >> > explicitly mentioning that there is a plurality of label-binding >> > protocols seems unecessary to me. you are right insofar as rfc3031 >> > does *not* mention a tie-breaking amon protocols and yet there are >> > implemntations who support more than one concurrent label- >> distribution protocol. >> > >> > | Example: Is FEC distributed by OSPF more important then FEC >> > | distributed by targetted LDP session in the same OSPF domain ? >> > >> > that is an implementation choice; hopefully the administrative >> > preference is user configurable. >> > >> > | On the other hand if this case is considered an error a >> > | corresponding error handling section may be required. >> > | >> > | >> > | Recommendation: >> > | >> > | s/distirbution/distribution/ >> > | >> > | >> > | Best regards, >> > | R. >> > | >> > | >> > | On Fri, May 16, 2014 at 7:37 PM, Yakov Rekhter <[email protected]> >> wrote: >> > | > Alvaro and John, >> > | > >> > | > The authors of draft-gredler-spring-mpls-05.txt would like to ask >> > | > SPRING WG to accept this draft as SPRING WG document. >> > | > >> > | > Yakov. >> > | > ------- Forwarded Message >> > | > >> > | > Date: Fri, 16 May 2014 10:33:51 -0700 >> > | > From: <[email protected]> >> > | > To: <[email protected]> >> > | > Subject: I-D Action: draft-gredler-spring-mpls-05.txt >> > | > >> > | > >> > | > A New Internet-Draft is available from the on-line Internet- >> Drafts directories. >> > | > >> > | > >> > | > Title : Supporting Source/Explicitly Routed >> Tunnels via Stack >> > | > ed LSPs >> > | > Authors : Hannes Gredler >> > | > Yakov Rekhter >> > | > Luay Jalil >> > | > Sriganesh Kini >> > | > Xiaohu Xu >> > | > Filename : draft-gredler-spring-mpls-05.txt >> > | > Pages : 17 >> > | > Date : 2014-05-16 >> > | > >> > | > Abstract: >> > | > This document describes how source/explicitly routed tunnels >> could be >> > | > realized using stacked Label Switched Paths (LSPs). >> > | > >> > | > This document also describes how use of IS-IS/OSPF as a label >> > | > distribution protocol fits into the MPLS architecture. >> > | > >> > | > >> > | > The IETF datatracker status page for this draft is: >> > | > https://datatracker.ietf.org/doc/draft-gredler-spring-mpls/ >> > | > >> > | > There's also a htmlized version available at: >> > | > http://tools.ietf.org/html/draft-gredler-spring-mpls-05 >> > | > >> > | > A diff from the previous version is available at: >> > | > http://www.ietf.org/rfcdiff?url2=draft-gredler-spring-mpls-05 >> > | > >> > | > >> > | > Please note that it may take a couple of minutes from the time of >> > | > submission until the htmlized version and diff are available at >> tools.ietf.org. >> > | > >> > | > Internet-Drafts are also available by anonymous FTP at: >> > | > ftp://ftp.ietf.org/internet-drafts/ >> > | > >> > | > _______________________________________________ >> > | > I-D-Announce mailing list >> > | > [email protected] >> > | > https://www.ietf.org/mailman/listinfo/i-d-announce >> > | > Internet-Draft directories: http://www.ietf.org/shadow.html or >> > | > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > | > >> > | > ------- End of Forwarded Message >> > | > >> > | > _______________________________________________ >> > | > spring mailing list >> > | > [email protected] >> > | > https://www.ietf.org/mailman/listinfo/spring >> > | >> > | _______________________________________________ >> > | spring mailing list >> > | [email protected] >> > | https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
