Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
Agree with Anton on the use of Node IPvX Local Address sub-TLVs as it provides the flexibility to advertise more/other addresses. If we were to use IPvX Router Address TLVs then we could only do one per node. My comment was that in most cases, advertising just that one IPvX address (generally equivalent to what would have been put in IPvX Router Address TLV) is sufficient and that this it should be a MUST (instead of SHOULD). Other addresses may be optional as indicated in the draft. Thanks, Ketan -Original Message- From: Anton Smirnov (asmirnov) Sent: 27 October 2018 07:04 To: Alexander Okonnikov Cc: Ketan Talaulikar (ketant) ; Acee Lindem (acee) ; lsr@ietf.org Subject: Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt Hi Alexander, > I tend to agree with Ketan, but with slightly different proposal. Would > > not it be simpler to advertise IPv6 Router Address TLV (TLV type 3) by > > OSPFv2 Opaque LSA (in addition to advertising of Router Address TLV) and > > to advertise Router Address TLV (TLV type 1) by OSPFv3 Intra-Area-TE-LSA > > (in addition to advertising IPv6 Router Address TLV)? In this case we > can > identify the same router represented by OSPFv2 and OSPFv3 and don't > need > the extension provided by the draft. What you are suggesting is essentially the same sort of information propagated in different TE TLV. So basically except for TLV type rest of of procedures won't change. When writing the first revision of the draft we did consider doing what you are proposing but finally Node IPvX Local Address sub-TLV looked like a better match to what we intend to advertise. Per RFC 5786 Node IPvX Local Address sub-TLV is used to advertise additional addresses local to the router. And that is exactly what we use it for, to advertise additional router's addresses. As for the other Ketan's comment - as I already wrote, we will try to address it in the next document revision. --- Anton On 10/25/18 23:19, Alexander Okonnikov wrote: > Hi Anton, > > I tend to agree with Ketan, but with slightly different proposal. > Would not it be simpler to advertise IPv6 Router Address TLV (TLV type > 3) by > OSPFv2 Opaque LSA (in addition to advertising of Router Address TLV) > and to advertise Router Address TLV (TLV type 1) by OSPFv3 > Intra-Area-TE-LSA (in addition to advertising IPv6 Router Address > TLV)? In this case we can identify the same router represented by > OSPFv2 and OSPFv3 and don't need the extension provided by the draft. > > Regarding calculation of LSPs towards non-TE addresses - head-end uses > non-TE address in order to determine TE Router ID of the tail-end > (which holds that non-TE address); then head-end uses TE RID in CSPF > calculation (though it will, probably, use that non-TE address as a > destination in RSVP-TE signaling). Hence, head-end can hold mapping of > destination IP of an LSP to corresponding TE RID of tail-end. Then, if > the same head-end attempts to calculate LSP using TEDB from OSPFv3 > (OSPFv2), it will be able to determine whether LSP already have been > signaled using OSPFv2 (OSPFv3) TEDB. > > Also, the draft several times says about using TEDB(s) for calculation > of LSPs and, on the other hand, for using LSPs for calculation of OSPF > routes. Per my understanding these are two different independent tasks > - calculation of LSPs and their usage. The second task is what defined > by RFC 3906, and you want to extend it such that SPF for one AF can > utilise LSPs as shortcuts, created for other AF. My understanding that > these two tasks need to be discussed separately. It could be two > different documents, or two different sections of the same one. > > Thank you. > >> 25 окт. 2018 г., в 19:57, Anton Smirnov > <mailto:asmir...@cisco.com>> написал(а): >> >> Hi Ketan, >> >> 1. I am not sure I understood the question. Your example says "using >> the TE topology from OSPFv2 to compute a tunnel". In that case TE >> router ID is an IPv4 address. So no, advertising IPv6 address won't >> help to identify the tunnel. >> >> 2. my opinion (not discussed with other authors): RFC 3906 is >> Informational RFC, so it is not mandatory for implementation to >> follow. I think we can insert mention to that RFC somewhere in the >> Introduction but wording should be sufficiently weak (like "one >> possible example of route computation algorithm..."). >> >> --- >> Anton >> >> On 10/24/18 12:06, Ketan Talaulikar (ketant) wrote: >>> >>> Hello All, >>> >>> I support this simple but important extension. >>&
Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
Hi Acee, WG, Yes, support publication of this important work. Thanks, Rakesh From: Lsr on behalf of Acee Lindem Date: Monday, October 22, 2018 at 6:25 PM To: "lsr@ietf.org" Subject: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt This begins an LSR WG last call for the subject draft. Please send your comments to this list prior to 12:00 AM GMT, November 13th , 2018. While its only an 8 page document, I added an extra week due to the IETF. Please let me know if anyone needs any more time. https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
y, if any IPv6 addresses (if at all) were to be used for CSPF then it would just identify the node – in this case, isn’t advertising the IPv6 address (TE router ID used in Router Address TLV) sufficient? For practical deployment, it think it would help if this was clarified that we really need only the TE Router ID Address to go X-AF in most/general cases and not the others? 2)Isn’t the mapping algorithm in Sec 3 actually going to be used for IGP short-cut use-case with its reference to the IGP cost of the tunnel? If so, would a reference to rfc3906 be helpful in this document. Thanks, Ketan *From:*Lsr *On Behalf Of *Acee Lindem (acee) *Sent:* 23 October 2018 03:55 *To:* lsr@ietf.org *Subject:* [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt This begins an LSR WG last call for the subject draft. Please send your comments to this list prior to 12:00 AM GMT, November 13^th , 2018. While its only an 8 page document, I added an extra week due to the IETF. Please let me know if anyone needs any more time. https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org <mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
Hi Anton, I tend to agree with Ketan, but with slightly different proposal. Would not it be simpler to advertise IPv6 Router Address TLV (TLV type 3) by OSPFv2 Opaque LSA (in addition to advertising of Router Address TLV) and to advertise Router Address TLV (TLV type 1) by OSPFv3 Intra-Area-TE-LSA (in addition to advertising IPv6 Router Address TLV)? In this case we can identify the same router represented by OSPFv2 and OSPFv3 and don't need the extension provided by the draft. Regarding calculation of LSPs towards non-TE addresses - head-end uses non-TE address in order to determine TE Router ID of the tail-end (which holds that non-TE address); then head-end uses TE RID in CSPF calculation (though it will, probably, use that non-TE address as a destination in RSVP-TE signaling). Hence, head-end can hold mapping of destination IP of an LSP to corresponding TE RID of tail-end. Then, if the same head-end attempts to calculate LSP using TEDB from OSPFv3 (OSPFv2), it will be able to determine whether LSP already have been signaled using OSPFv2 (OSPFv3) TEDB. Also, the draft several times says about using TEDB(s) for calculation of LSPs and, on the other hand, for using LSPs for calculation of OSPF routes. Per my understanding these are two different independent tasks - calculation of LSPs and their usage. The second task is what defined by RFC 3906, and you want to extend it such that SPF for one AF can utilise LSPs as shortcuts, created for other AF. My understanding that these two tasks need to be discussed separately. It could be two different documents, or two different sections of the same one. Thank you. > 25 окт. 2018 г., в 19:57, Anton Smirnov написал(а): > >Hi Ketan, > > 1. I am not sure I understood the question. Your example says "using the TE > topology from OSPFv2 to compute a tunnel". In that case TE router ID is an > IPv4 address. So no, advertising IPv6 address won't help to identify the > tunnel. > 2. my opinion (not discussed with other authors): RFC 3906 is Informational > RFC, so it is not mandatory for implementation to follow. I think we can > insert mention to that RFC somewhere in the Introduction but wording should > be sufficiently weak (like "one possible example of route computation > algorithm..."). > --- > Anton > > On 10/24/18 12:06, Ketan Talaulikar (ketant) wrote: >> Hello All, >> >> I support this simple but important extension. >> >> A couple of minor comments on the draft: >> >> 1) Sec 3 says >> >>A node that implements X-AF routing SHOULD advertise, in the >>corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6 >>addresses local to the router that can be used by Constrained SPF >>(CSPF) to calculate MPLS TE LSPs. In general, OSPF SHOULD advertise >>the IP address listed in the Router Address TLV [RFC3630 >> <https://tools.ietf.org/html/rfc3630>] [RFC5329 >> <https://tools.ietf.org/html/rfc5329>] >>of the X-AF instance maintaining the MPLS TE database, plus any >>additional local addresses advertised by the X-AF OSPF instance in >>its Node Local Address sub-TLVs. An implementation MAY advertise >>other local X-AF addresses. >> >> Generally speaking, should the IP address (TE router ID in common terms) >> which is candidate for inclusion in the Router Address TLV not be a MUST >> candidate for X-AF advertisement? >> >> I also have a question about the first statement with the SHOULD in it. >> Consider we are using the TE topology from OSPFv2 to compute a tunnel for >> use with OSPFv3. Any IPv6 addresses associated with the OSPFv3 instance on a >> router would be advertised as a Node attribute and would not help identify a >> specific link. So practically, if any IPv6 addresses (if at all) were to be >> used for CSPF then it would just identify the node – in this case, isn’t >> advertising the IPv6 address (TE router ID used in Router Address TLV) >> sufficient? >> >> For practical deployment, it think it would help if this was clarified that >> we really need only the TE Router ID Address to go X-AF in most/general >> cases and not the others? >> >> 2) Isn’t the mapping algorithm in Sec 3 actually going to be used for >> IGP short-cut use-case with its reference to the IGP cost of the tunnel? If >> so, would a reference to rfc3906 be helpful in this document. >> >> Thanks, >> Ketan >> >> From: Lsr <mailto:lsr-boun...@ietf.org> On Behalf Of >> Acee Lindem (acee) >> Sent: 23 October 2018 03:55 >> To: lsr@ietf.org <mailto:lsr@ietf.org> >> Subject: [Lsr] OSPF Routi
Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
Hi Ketan, 1. I am not sure I understood the question. Your example says "using the TE topology from OSPFv2 to compute a tunnel". In that case TE router ID is an IPv4 address. So no, advertising IPv6 address won't help to identify the tunnel. 2. my opinion (not discussed with other authors): RFC 3906 is Informational RFC, so it is not mandatory for implementation to follow. I think we can insert mention to that RFC somewhere in the Introduction but wording should be sufficiently weak (like "one possible example of route computation algorithm..."). --- Anton On 10/24/18 12:06, Ketan Talaulikar (ketant) wrote: Hello All, I support this simple but important extension. A couple of minor comments on the draft: 1)Sec 3 says A node that implements X-AF routing SHOULD advertise, in the corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6 addresses local to the router that can be used by Constrained SPF (CSPF) to calculate MPLS TE LSPs. In general, OSPF SHOULD advertise the IP address listed in the Router Address TLV [RFC3630 <https://tools.ietf.org/html/rfc3630>] [RFC5329 <https://tools.ietf.org/html/rfc5329>] of the X-AF instance maintaining the MPLS TE database, plus any additional local addresses advertised by the X-AF OSPF instance in its Node Local Address sub-TLVs. An implementation MAY advertise other local X-AF addresses. Generally speaking, should the IP address (TE router ID in common terms) which is candidate for inclusion in the Router Address TLV not be a MUST candidate for X-AF advertisement? I also have a question about the first statement with the SHOULD in it. Consider we are using the TE topology from OSPFv2 to compute a tunnel for use with OSPFv3. Any IPv6 addresses associated with the OSPFv3 instance on a router would be advertised as a Node attribute and would not help identify a specific link. So practically, if any IPv6 addresses (if at all) were to be used for CSPF then it would just identify the node – in this case, isn’t advertising the IPv6 address (TE router ID used in Router Address TLV) sufficient? For practical deployment, it think it would help if this was clarified that we really need only the TE Router ID Address to go X-AF in most/general cases and not the others? 2)Isn’t the mapping algorithm in Sec 3 actually going to be used for IGP short-cut use-case with its reference to the IGP cost of the tunnel? If so, would a reference to rfc3906 be helpful in this document. Thanks, Ketan *From:*Lsr *On Behalf Of *Acee Lindem (acee) *Sent:* 23 October 2018 03:55 *To:* lsr@ietf.org *Subject:* [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt This begins an LSR WG last call for the subject draft. Please send your comments to this list prior to 12:00 AM GMT, November 13^th , 2018. While its only an 8 page document, I added an extra week due to the IETF. Please let me know if anyone needs any more time. https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
Hi Gunter, we agree with the proposed change and will make it in the next revision, probably even rephrase this sentence. --- Anton On 10/24/18 12:59, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: Looks fine. One item I would like to see changed (or at least discussed) I have a problem with chapter3 – Para6 – Point 1 : EXISTING: If T's destination IP address is from the same address family as the computing OSPF instance,*then the tunnel must have been* *signaled based on MPLS TE information propagated in the same OSPF* *instance*. Process the tunnel as per [RFC3630 <https://tools.ietf.org/html/rfc3630>] or [RFC5329 <https://tools.ietf.org/html/rfc5329>]. PROPOSED: If T's destination IP address is from the same address family as the computing OSPF instance,*then *process the tunnel as per [RFC3630 <https://tools.ietf.org/html/rfc3630>] or [RFC5329 <https://tools.ietf.org/html/rfc5329>]. MOTIVATION: I do not understand why to restrict the tunnel to be signaled with only info from same OSPF instance. If there is tunnel available (different instance, or even other routing protocol), it should be able to be used. G/ *From:*Lsr *On Behalf Of *Acee Lindem (acee) *Sent:* Tuesday, October 23, 2018 00:25 *To:* lsr@ietf.org *Subject:* [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt This begins an LSR WG last call for the subject draft. Please send your comments to this list prior to 12:00 AM GMT, November 13^th , 2018. While its only an 8 page document, I added an extra week due to the IETF. Please let me know if anyone needs any more time. https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
Hello All, I support this simple but important extension. A couple of minor comments on the draft: 1) Sec 3 says A node that implements X-AF routing SHOULD advertise, in the corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6 addresses local to the router that can be used by Constrained SPF (CSPF) to calculate MPLS TE LSPs. In general, OSPF SHOULD advertise the IP address listed in the Router Address TLV [RFC3630<https://tools.ietf.org/html/rfc3630>] [RFC5329<https://tools.ietf.org/html/rfc5329>] of the X-AF instance maintaining the MPLS TE database, plus any additional local addresses advertised by the X-AF OSPF instance in its Node Local Address sub-TLVs. An implementation MAY advertise other local X-AF addresses. Generally speaking, should the IP address (TE router ID in common terms) which is candidate for inclusion in the Router Address TLV not be a MUST candidate for X-AF advertisement? I also have a question about the first statement with the SHOULD in it. Consider we are using the TE topology from OSPFv2 to compute a tunnel for use with OSPFv3. Any IPv6 addresses associated with the OSPFv3 instance on a router would be advertised as a Node attribute and would not help identify a specific link. So practically, if any IPv6 addresses (if at all) were to be used for CSPF then it would just identify the node – in this case, isn’t advertising the IPv6 address (TE router ID used in Router Address TLV) sufficient? For practical deployment, it think it would help if this was clarified that we really need only the TE Router ID Address to go X-AF in most/general cases and not the others? 2) Isn’t the mapping algorithm in Sec 3 actually going to be used for IGP short-cut use-case with its reference to the IGP cost of the tunnel? If so, would a reference to rfc3906 be helpful in this document. Thanks, Ketan From: Lsr On Behalf Of Acee Lindem (acee) Sent: 23 October 2018 03:55 To: lsr@ietf.org Subject: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt This begins an LSR WG last call for the subject draft. Please send your comments to this list prior to 12:00 AM GMT, November 13th , 2018. While its only an 8 page document, I added an extra week due to the IETF. Please let me know if anyone needs any more time. https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
Support. It is a straighforward solution to the problem. Les From: Lsr On Behalf Of Acee Lindem (acee) Sent: Monday, October 22, 2018 3:25 PM To: lsr@ietf.org Subject: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt This begins an LSR WG last call for the subject draft. Please send your comments to this list prior to 12:00 AM GMT, November 13th , 2018. While its only an 8 page document, I added an extra week due to the IETF. Please let me know if anyone needs any more time. https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
Support. thanks, Peter On 23/10/18 00:25 , Acee Lindem (acee) wrote: This begins an LSR WG last call for the subject draft. Please send your comments to this list prior to 12:00 AM GMT, November 13^th , 2018. While its only an 8 page document, I added an extra week due to the IETF. Please let me know if anyone needs any more time. https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
I support publication of this draft, simple and straightforward. Cheers, Jeff On Oct 23, 2018, 12:49 PM -0700, Acee Lindem (acee) , wrote: > Speaking as a WG member: > > I support publication of this draft. All of my comments are already in this > revision. > > Thanks, > Acee > > From: Lsr on behalf of Acee Lindem > Date: Monday, October 22, 2018 at 6:25 PM > To: "lsr@ietf.org" > Subject: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering > Tunnels - draft-ietf-ospf-xaf-te-04.txt > > This begins an LSR WG last call for the subject draft. Please send your > comments to this list prior to 12:00 AM GMT, November 13th , 2018. While its > only an 8 page document, I added an extra week due to the IETF. Please let me > know if anyone needs any more time. > > https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ > > Thanks, > Acee > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
Support . Thanks Mankamana From: Lsr on behalf of "Acee Lindem (acee)" Date: Monday, October 22, 2018 at 3:25 PM To: "lsr@ietf.org" Subject: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt This begins an LSR WG last call for the subject draft. Please send your comments to this list prior to 12:00 AM GMT, November 13th , 2018. While its only an 8 page document, I added an extra week due to the IETF. Please let me know if anyone needs any more time. https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
Speaking as a WG member: I support publication of this draft. All of my comments are already in this revision. Thanks, Acee From: Lsr on behalf of Acee Lindem Date: Monday, October 22, 2018 at 6:25 PM To: "lsr@ietf.org" Subject: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt This begins an LSR WG last call for the subject draft. Please send your comments to this list prior to 12:00 AM GMT, November 13th , 2018. While its only an 8 page document, I added an extra week due to the IETF. Please let me know if anyone needs any more time. https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
This begins an LSR WG last call for the subject draft. Please send your comments to this list prior to 12:00 AM GMT, November 13th , 2018. While its only an 8 page document, I added an extra week due to the IETF. Please let me know if anyone needs any more time. https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
