- dev - lists.frrouting.org

Re: [frr] Fwd: Re: [PATCH net-next 0/4] net: mpls: Allow users to configure more labels per route
by Rodny Molina 27 Mar '17

27 Mar '17

> An MPLS packet may in transit receive additional labels. I most cases (all?), this will be most properly seen as a LSP hierarchy (tunneling one LSP into another LSP), so closer to a notion of ingress rather than something related to the initial LSP. But I don't know if the distinction is of importance. > > The cases that comes to mind would be: > - tunneling into a fast-reroute bypass LSP (possibly a segment routing LSP, see segment routing TI LFA) > - seamless MPLS > - carrier's carrier type of deployment <Rodny> I would add SR-policy as the most generic example. Ideally, any router along the path, being the (real / app-facing) head-end or not, should be capable of injecting a SID-list to enforce any given forwarding policy. So i believe that David’s patch is needed as is: to cover both ip->mpls and mpls->mpls scenarios. https://datatracker.ietf.org/doc/html/draft-filsfils-spring-segment-routing… <https://datatracker.ietf.org/doc/html/draft-filsfils-spring-segment-routing…> >> How does this compare with running the packet a couple of times through >> the mpls table to get all of the desired labels applied? <Rodny> I would like to know more about this one too. /Rodny > On Mar 26, 2017, at 3:23 PM, David Ahern via frr <frr(a)lists.nox.tf> wrote: > > > From: David Ahern <dsa(a)cumulusnetworks.com <mailto:dsa@cumulusnetworks.com>> > Subject: Re: Fwd: Re: [PATCH net-next 0/4] net: mpls: Allow users to configure more labels per route > Date: March 26, 2017 at 3:22:51 PM PDT > To: Thomas Morin <thomas.morin(a)orange.com <mailto:thomas.morin@orange.com>>, DUGEON Olivier IMT/OLN <olivier.dugeon(a)orange.com <mailto:olivier.dugeon@orange.com>>, "amine.kherbouche(a)6wind.com <mailto:amine.kherbouche@6wind.com>" <amine.kherbouche(a)6wind.com <mailto:amine.kherbouche@6wind.com>>, "jefftant(a)gmail.com <mailto:jefftant@gmail.com>" <jefftant(a)gmail.com <mailto:jefftant@gmail.com>>, "frr(a)lists.nox.tf <mailto:frr@lists.nox.tf>" <frr(a)lists.nox.tf <mailto:frr@lists.nox.tf>>, Bruno Decraene <bruno.decraene(a)orange.com <mailto:bruno.decraene@orange.com>>, roopa <roopa(a)cumulusnetworks.com <mailto:roopa@cumulusnetworks.com>> > > > On 3/26/17 11:02 AM, Thomas Morin wrote: >> Hi David, >> >> [adding my colleague Bruno to the list, he may correct things I might >> have oversimplified on segment routing, or have a idea about 12] >> >> 2017-03-25, David Ahern: >>> Eric's question below is basically adding labels at tunnel ingress vs >>> while traversing the LSP. I was generically increasing both to more than >>> 2 labels. Opinions? >> >> An MPLS packet may in transit receive additional labels. I most cases >> (all?), this will be most properly seen as a LSP hierarchy (tunneling >> one LSP into another LSP), so closer to a notion of ingress rather than >> something related to the initial LSP. But I don't know if the >> distinction is of importance. >> >> The cases that comes to mind would be: >> - tunneling into a fast-reroute bypass LSP (possibly a segment routing >> LSP, see segment routing TI LFA) >> - seamless MPLS >> - carrier's carrier type of deployment >> >> In these cases a router could receive an MPLS packet, and possibly after >> popping the topmost, push a stack of labels onto the packet. > > And that's my takeaway from past discussions on this topic (number of > labels). > >> >> About the email below: >> - how did 12 end up being considered "covering all currently known >> segment routing use cases" ? it seems that SR could use an arbitrary >> number of labels (not saying 12 is a bad number, but...) > > I believe the consensus was 8 but Olivier had a use case for more. The > way I have this coded means the performance impact is to users adding > more and more labels - which is expected and appropriate. > > >> - I'm not sure what Eric's idea of "running the packet a couple of times >> through the mpls table to get all of the desired labels applied" would >> mean: after the first lookup, what data would be used as key for the >> following lookup ? > > no idea. I need him to clarify. > > >> - back to your question, which seems to imply one could possibly >> increase number of labels for ingress without increasing number of >> labels for transit: isn't the same datastructure used in both to >> represent an mpls next hop (in RFC3031, both the ILM and FTN point to >> NHLFE entries, but I haven't digged enough to identify how these maps to >> the kernel implementation) > > no. Ingress is handled by a lightweight tunnel infrastructure. In 'ip' > terms the route specifies lwt with mpls encap. LSP MPLS is handled as a > typical protocol family with its own route database. > >> - would a concept of a linked list of mpls_nh make sense, each with one >> label to impose, make sense, so that no hard limit is put on the label >> stack depth? > > each nexthop has its own label stack. The nexthops are essentially an > array at the end of the mpls route. > > > > _______________________________________________ > frr mailing list > frr(a)lists.nox.tf <mailto:frr@lists.nox.tf> > https://lists.nox.tf/listinfo/frr <https://lists.nox.tf/listinfo/frr> On Mar 26, 2017, at 1:16 PM, Jeff Tantsura <jefftant(a)gmail.com> wrote: Hi Thomas, Good points. There’s no free lunch in fast path universe, packet recalculation has price associated with it, the most obvious things are increased latency and reduced throughput, there’s more. Sorry for repeating myself - not being linux kernel expert myself - I’d appreciate pros/cons analysis of taking different approaches, the impact of adding new code and system behavior with it. Those who expect the underlying platform to be not X86 only (Cumulus?) what are your expectation from HAL/ HW SDK prospective? Cheers, Jeff > On Mar 26, 2017, at 12:02, Thomas Morin <thomas.morin(a)orange.com> wrote: > > Hi David, > > [adding my colleague Bruno to the list, he may correct things I might have oversimplified on segment routing, or have a idea about 12] > > 2017-03-25, David Ahern: >> Eric's question below is basically adding labels at tunnel ingress vs >> while traversing the LSP. I was generically increasing both to more than >> 2 labels. Opinions? > > An MPLS packet may in transit receive additional labels. I most cases (all?), this will be most properly seen as a LSP hierarchy (tunneling one LSP into another LSP), so closer to a notion of ingress rather than something related to the initial LSP. But I don't know if the distinction is of importance. > > The cases that comes to mind would be: > - tunneling into a fast-reroute bypass LSP (possibly a segment routing LSP, see segment routing TI LFA) > - seamless MPLS > - carrier's carrier type of deployment > > In these cases a router could receive an MPLS packet, and possibly after popping the topmost, push a stack of labels onto the packet. > > About the email below: > - how did 12 end up being considered "covering all currently known segment routing use cases" ? it seems that SR could use an arbitrary number of labels (not saying 12 is a bad number, but...) > - I'm not sure what Eric's idea of "running the packet a couple of times through the mpls table to get all of the desired labels applied" would mean: after the first lookup, what data would be used as key for the following lookup ? > - back to your question, which seems to imply one could possibly increase number of labels for ingress without increasing number of labels for transit: isn't the same datastructure used in both to represent an mpls next hop (in RFC3031, both the ILM and FTN point to NHLFE entries, but I haven't digged enough to identify how these maps to the kernel implementation) > - would a concept of a linked list of mpls_nh make sense, each with one label to impose, make sense, so that no hard limit is put on the label stack depth? > > -Thomas > > > >> -------- Forwarded Message -------- >> Subject: Re: [PATCH net-next 0/4] net: mpls: Allow users to configure >> more labels per route >> Date: Sat, 25 Mar 2017 14:15:54 -0500 >> From: Eric W. Biederman <ebiederm(a)xmission.com> >> To: David Ahern <dsa(a)cumulusnetworks.com> >> CC: netdev(a)vger.kernel.org, roopa(a)cumulusnetworks.com, rshearma(a)brocade.com >> >> David Ahern <dsa(a)cumulusnetworks.com> writes: >> >>> Bump the maximum number of labels for MPLS routes from 2 to 12. To keep >>> memory consumption in check the labels array is moved to the end of mpls_nh >>> and mpls_iptunnel_encap structs as a 0-sized array. Allocations use the >>> maximum number of labels across all nexthops in a route for LSR and the >>> number of labels configured for LWT. >>> >>> The mpls_route layout is changed to: >>> >>> +----------------------+ >>> | mpls_route | >>> +----------------------+ >>> | mpls_nh 0 | >>> +----------------------+ >>> | alignment padding | 4 bytes for odd number of labels; 0 for even >>> +----------------------+ >>> | via[rt_max_alen] 0 | >>> +----------------------+ >>> | alignment padding | via's aligned on sizeof(unsigned long) >>> +----------------------+ >>> | ... | >>> >>> Meaning the via follows its mpls_nh providing better locality as the >>> number of labels increases. UDP_RR tests with namespaces shows no impact >>> to a modest performance increase with this layout for 1 or 2 labels and >>> 1 or 2 nexthops. >>> >>> The new limit is set to 12 to cover all currently known segment >>> routing use cases. >> >> How does this compare with running the packet a couple of times through >> the mpls table to get all of the desired labels applied? >> >> I can certainly see the case in an mpls tunnel ingress where this might >> could be desirable. Which is something you implement in your last >> patch. However is it at all common to push lots of labels at once >> during routing? >> >> I am probably a bit naive but it seems absurd to push more >> than a handful of labels onto a packet as you are routing it. >> >> Eric >> > _______________________________________________ frr mailing list frr(a)lists.nox.tf https://lists.nox.tf/listinfo/frr

1 0

[frr] New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 25 Mar '17

25 Mar '17

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 3 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1420923: Null pointer dereferences (REVERSE_INULL) /pimd/pim_msg.c: 112 in pim_msg_get_jp_group_size() ________________________________________________________________________________________________________ *** CID 1420923: Null pointer dereferences (REVERSE_INULL) /pimd/pim_msg.c: 112 in pim_msg_get_jp_group_size() 106 107 size += sizeof (struct pim_encoded_group_ipv4); 108 size += 4; // Joined sources (2) + Pruned Sources (2) 109 110 size += sizeof (struct pim_encoded_source_ipv4) * sources->count; 111 >>> CID 1420923: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "sources" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 112 js = listgetdata(listhead(sources)); 113 if (js && js->up->sg.src.s_addr == INADDR_ANY) 114 { 115 struct pim_upstream *child, *up; 116 struct listnode *up_node; 117 ** CID 742780: Memory - corruptions (ARRAY_VS_SINGLETON) /ospf6d/ospf6_route.c: 948 in ospf6_route_match_head() ________________________________________________________________________________________________________ *** CID 742780: Memory - corruptions (ARRAY_VS_SINGLETON) /ospf6d/ospf6_route.c: 948 in ospf6_route_match_head() 942 struct ospf6_route *route; 943 944 /* Walk down tree. */ 945 node = table->table->top; 946 while (node && node->p.prefixlen < prefix->prefixlen && 947 prefix_match (&node->p, prefix)) >>> CID 742780: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Taking address with "&prefix->u.prefix" yields a singleton pointer. 948 node = node->link[prefix_bit(&prefix->u.prefix, node->p.prefixlen)]; 949 950 if (node) 951 route_lock_node (node); 952 while (node && node->info == NULL) 953 node = route_next (node); ** CID 742779: Memory - corruptions (ARRAY_VS_SINGLETON) /ospf6d/ospf6_lsdb.c: 252 in ospf6_lsdb_lookup_next() ________________________________________________________________________________________________________ *** CID 742779: Memory - corruptions (ARRAY_VS_SINGLETON) /ospf6d/ospf6_lsdb.c: 252 in ospf6_lsdb_lookup_next() 246 node = lsdb->table->top; 247 /* walk down tree. */ 248 while (node && node->p.prefixlen <= p->prefixlen && 249 prefix_match (&node->p, p)) 250 { 251 matched = node; >>> CID 742779: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Taking address with "&p->u.prefix" yields a singleton pointer. 252 node = node->link[prefix_bit(&p->u.prefix, node->p.prefixlen)]; 253 } 254 255 if (matched) 256 node = matched; 257 else ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

[frr] New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 22 Mar '17

22 Mar '17

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 4 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** CID 1420265: Resource leaks (RESOURCE_LEAK) /zebra/label_manager.c: 229 in assign_label_chunk() ________________________________________________________________________________________________________ *** CID 1420265: Resource leaks (RESOURCE_LEAK) /zebra/label_manager.c: 229 in assign_label_chunk() 223 else 224 lmc->start = ((struct label_manager_chunk *) 225 listgetdata(listtail(lbl_mgr.lc_list)))->end + 1; 226 if (lmc->start > MPLS_MAX_UNRESERVED_LABEL - size + 1) { 227 zlog_err("Reached max labels. Start: %u, size: %u", lmc->start, 228 size); >>> CID 1420265: Resource leaks (RESOURCE_LEAK) >>> Variable "lmc" going out of scope leaks the storage it points to. 229 return NULL; 230 } 231 lmc->end = lmc->start + size - 1; 232 lmc->proto = proto; 233 lmc->instance = instance; 234 lmc->keep = keep; ** CID 1420264: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1420264: Null pointer dereferences (NULL_RETURNS) /pimd/pim_nht.c: 563 in pim_parse_nexthop_update() 557 case NEXTHOP_TYPE_IPV6: 558 stream_get (&nexthop->gate.ipv6, s, 16); 559 break; 560 case NEXTHOP_TYPE_IPV6_IFINDEX: 561 stream_get (&nexthop->gate.ipv6, s, 16); 562 nexthop->ifindex = stream_getl (s); >>> CID 1420264: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "if_lookup_by_index(nexthop->ifindex, 0)" when calling "pim_neighbor_find_if". 563 nbr = 564 pim_neighbor_find_if (if_lookup_by_index 565 (nexthop->ifindex, VRF_DEFAULT)); 566 /* Overwrite with Nbr address as NH addr */ 567 if (nbr) 568 nexthop->gate.ipv4 = nbr->source_addr; ** CID 1420263: Null pointer dereferences (NULL_RETURNS) /ldpd/lde.c: 1624 in on_get_label_chunk_response() ________________________________________________________________________________________________________ *** CID 1420263: Null pointer dereferences (NULL_RETURNS) /ldpd/lde.c: 1624 in on_get_label_chunk_response() 1618 struct label_chunk *new_label_chunk; 1619 1620 log_debug("Label Chunk assign: %u - %u", start, end); 1621 1622 new_label_chunk = calloc(1, sizeof(struct label_chunk)); 1623 >>> CID 1420263: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "new_label_chunk". 1624 new_label_chunk->start = start; 1625 new_label_chunk->end = end; 1626 new_label_chunk->used_mask = 0; 1627 1628 listnode_add(label_chunk_list, (void *)new_label_chunk); 1629 ** CID 1420262: Null pointer dereferences (FORWARD_NULL) /pimd/pim_nht.c: 519 in pim_parse_nexthop_update() ________________________________________________________________________________________________________ *** CID 1420262: Null pointer dereferences (FORWARD_NULL) /pimd/pim_nht.c: 519 in pim_parse_nexthop_update() 513 __PRETTY_FUNCTION__, buf); 514 } 515 return; 516 } 517 } 518 >>> CID 1420262: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "pnc". 519 pnc->last_update = pim_time_monotonic_sec (); 520 distance = stream_getc (s); 521 metric = stream_getl (s); 522 nexthop_num = stream_getc (s); 523 524 if (PIM_DEBUG_TRACE) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

[frr] New Label manager has been committed
by Donald Sharp 22 Mar '17

22 Mar '17

Bingen has implemented a label manager. This allows the sharing of Label space across the whole of FRR. Thanks Bingen and everyone who's spent time working on this! donald

2 1

[frr] Todays Technical Meeting 11 am EDT
by Donald Sharp 21 Mar '17

21 Mar '17

https://bluejeans.com/9192742159 1) Stable/2.0 Release 2) Issues 3) PR's 4) I am at IETF next week no meeting 5) Anything else? donald

4 5

[frr] New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 21 Mar '17

21 Mar '17

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1420253: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1420253: Null pointer dereferences (NULL_RETURNS) /pimd/pim_zlookup.c: 256 in zclient_read_nexthop() 250 ++num_ifindex; 251 break; 252 case NEXTHOP_TYPE_IPV6_IFINDEX: 253 nexthop_tab[num_ifindex].nexthop_addr.family = AF_INET6; 254 stream_get (&nexthop_tab[num_ifindex].nexthop_addr.u.prefix6, s, 16); 255 nexthop_tab[num_ifindex].ifindex = stream_getl (s); >>> CID 1420253: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "if_lookup_by_index((nexthop_tab + num_ifindex).ifindex, 0)" when calling "pim_neighbor_find_if". 256 nbr = pim_neighbor_find_if (if_lookup_by_index (nexthop_tab[num_ifindex].ifindex, VRF_DEFAULT)); 257 if (nbr) 258 { 259 nexthop_tab[num_ifindex].nexthop_addr.family = AF_INET; 260 nexthop_tab[num_ifindex].nexthop_addr.u.prefix4 = nbr->source_addr; 261 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [frr] Quagga Segment Routing implementation progress
by Jeff Tantsura 16 Mar '17

16 Mar '17

Hi, Besides what you could do in the fast path, take a look at control plane and efficient path computation. I’m preparing a talk for MPLS/SDN/whatever in Paris that talks about that, please find attached, it is not final and animations are a bit off because of pptx-<pdf. Enjoy Cheers, Jeff > -wip.patch>

1 0

[frr] Technical Meeting 3/14 11 am EDT
by Donald Sharp 15 Mar '17

15 Mar '17

https://bluejeans.com/9192742159 1) Issues 2) 2.0 Release Status 3) PR 4) MPLS Status 5) EIGRP Status Anything Else? donald

2 2

[frr] IETF 98 in late March
by Donald Sharp 09 Mar '17

09 Mar '17

All - I will be attending IETF in Chicago in a few weeks. Is anyone else attending and does anyone want to meet up face-to-face? donald

4 3

[frr] New Features in LDP
by Donald Sharp 09 Mar '17

09 Mar '17

I'd like to thanks Renato Westphal for adding these RFC's to LDP: 5918 - Typed Wildcard FEC 6667 - Typed Wildcard FEC for PWid 5919 - LDP End-of-LIB Now available in master. thanks! donald

3 2