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
