Hi Uma, Inline comments,
-----Message d'origine----- De : Uma Chunduri [mailto:[email protected]] Envoyé : mardi 29 octobre 2013 07:00 À : LITKOWSKI Stephane DTF/DERX; [email protected]; Hannes Gredler Cc : [email protected]; rogeriomariano; [email protected] Objet : RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt IMHO, there is no need for tie-breakers here (or it really *can't* help much). This is a non-issue for OSPF. [SLI] OSPF is an old time for me :) so plz correct me if I'm wrong. An OSPF router may advertise as an ISIS router many type of prefixes : - internal - external - Stub (Loopback, or non adj network) - transit (interface) What is good in OSPF compared to ISIS, is that we know what are the prefixes belonging to the node compared to what is "external" (type 3 or type 5 ...). But whatever, you would need to tiebreak and say, I'm only looking at type 1 LSA. And in type 1 LSA, I would have multiple infos : - OSPF router ID but it may not match the LDP listening IP. Or we have to say that LDP listening IP must match the IGP Router ID. - Links : Stub, Transit, Virtual ... and in Stub you may have /x and /32 ... so you may need to tiebreak ? Do I miss something ? For the other IGP, if this is the perceived problem: (plz confirm) - PQ node may not accept TLDP session from PLR, if PLR chooses an incorrect IP represented by PQ node (IGP/ISIS database). [SLI] Right Because, today there is no document mandates an IP address which effectively represents the ISIS node. We can't *fully* rely on TLV 134 because this is not mandated for non TE environments. [SLI] Right, TLV134 is not available everywhere .... Instead of inventing a new thing here, the closest and one possible approach is to have a document which mandates a reachable prefix (loopback) in TLV 134, **regardless of TE present/supported or not**. This is the key and it fully solves the issue (it's important to note here - though today it's optional to have TLV 134 per 5305, some vendors including Ericsson do emit this regardless of TE in the local ISIS LSP). Does it make sense? (Les ?) [SLI] I'm ok on the principle, but my concern is that this implies that LDP listening IP would mandatory need to be configured to match the TLV 134. This may cause issue in some networks using multiple loopbacks (one loopback per protocol or service ...). Is this critical or not ? Note that Juniper also always advertise TLV134 based on what I know. The simpler we can do, the better it would be :) Advantage of this approach is, lot of vendors need not do any thing for this and for the remaining folk who are *not* doing this; should upgrade to have this TLV (probably upgrade may be necessary with any other always "workable" approach too) to represent reachable loopback IP address of the node always. Quick replies in-line [Uma]: -- Uma C. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, October 28, 2013 6:42 PM To: [email protected]; Hannes Gredler Cc: [email protected]; rogeriomariano; [email protected] Subject: RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Hi Stewart, It sounds good to me, except for the proposed tie breaker mechanism. As you know, today there is no existing mechanism for LDP to advertise the TLDP listening IP address in the IGP. So in short/mid term rLFA deployment, no IGP solution would be available. [Uma]: True, only if a non-TE ISIS node doesn't advertise TLV 134 today. [SLI] : yes and no ... TLV134 may not represent the LDP listening IP address ... IGP and LDP are independent and each may have his own configuration. So the draft must propose a last resort "working" tie breaker. [Uma]: If the above is TRUE, I don't think you can do much by defining a "working" tie breaker here. Also, I don't think there is one possible really in that situation. IMHO, using the lowest numerical value would be a very bad idea ... because this has no sense (just tie break, but without any insurance that the chosen prefix would be good). In order to bring more insurance, at least, I think the the tie breaker must check that the prefix used is an internal one (when possible ...) and is a /32. [Uma]: /32 is fine but you don't know from the TLV if it is a internal prefix or external prefix always (IMO, this could be the blocker for proposing any "working" tie breaker). [SLI] Right , with TE TLVs in ISIS we are loosing the "external" identification that's why I added "when possible ...". But /32 is mandatory. I don't think we could make something more precise because otherwise we would need to address IGP protocol specifities (TLVs, LSAs ... fields to check...). [Uma]: I don't think there is any issue for OSPF in this regard (LSA.. as you mentioned) For ISIS (TLV as you said), yes at times one may quickly lost in TLV 135s, if one wants to really figure out this /32 (TLV 135) is indeed represents the PQ node. Thoughts ? _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
